Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
NEW PERSPECTIVE
Asher Barak
PART ONE
ne principle to rule them all
1920 - 2012
one of the founders of the cognitive
psychology field
GEORGE A.
MILLER
THE MAGICAL
NUMBER
2
1930 - 2002
Dutch computer scientist
Edsger W.
Dijkstra
Go To Statement Considered Harmful
SOFTWARE
Is Too Complex
For Our
BRAIN
MANAGING
COMPLEXITY
Your #1 goal should be
ARISTOTLE
Geek philosopher
384 – 322 BCE
Essential Accidentalvs
SOFTWARE COMPLEXITY
• Computers speak a binary language
• Computers are batch machines
• There is a wide gap between codin...
ONE THING AT A TIME
CARE ABOUT LESS
• Do as little as possible
• Divide (& conquer)
• Hide the details - Work
with layered
abstractions
• Redu...
LANGUAGE
FUNDAMENTALS
Class
Method
Procedural
Code
Layer
Module
Class
USE INTERFACES
• Do as little as possible
• Divide (And Conquer)
• Hide the details - Work
with layered
abstractions
• Red...
CODING
PRACTICES
THINK OF YOUR
AUDIENCE
(It’s not the compiler)
NAME STUFF
• With the right name
• In a standard way
• Methods – For what they do
• Functions – For what they return
• Cla...
USE CONVENTIONS
Any convention is better than no convention
Every convention is one less thing to think about
USE CONVENTIONS
• Naming Conventions
• Method parameters conventions
• Resources placing conventions
• Documenting convent...
USE CONVENTIONS
CONSISTENT ABSTRACTIONS
Problem Domain
Language/Platform
CONSISTENT ABSTRACTIONS
Problem Domain
Problem Domain Lower Level
USE DESIGN PATTERNS
• They represent a higher abstraction
over coding details
• They simplify communications in the
team
•...
TDD
• Promotes better divisions
• Promotes better abstractions
• Promotes better documentation
• Promotes better personal
...
DESIGN BEST
PRACTICES
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
• Do as little as
possible
• Divide (And
Conquer)
• Hide the details -
Work with layered
abstractions
• Reduce the noise
PART TWO
Make it your own
PROGRAMMING IS
DONE SOLO
Creating a culture requires communication
FACE THE TRUTH
Some people program
for the wrong reasons
ACTIVELY ENCOURAGE
SOCIALIZING
Preferably of people who like their job
TALK
ABOUT
THE
PROCESS
BE OPENLY EXCITED
ABOUT GOOD
CRAFTSMANSHIP
(With tears if possible)
TALK ABOUT
READABILITY
Is it good for readability or is it bad?
TALK ABOUT
ABSTRACTIONS
Try splitting discussion the way code is split
ACTIVELY ENCOURAGE
MORE DESIGN
This is hardly ever a problem
ACTIVELY ENCOURAGE
DESIGN CONSULTING
Everyone ends up smarter
PUT PERFORMANCE &
EFFICIENCY SECOND
Maintainability first
PUT PERFORMANCE &
EFFICIENCY SECOND
• We are not good at anticipating
resources issues
• We are not good at anticipating
p...
HAVE EXPECTATIONS
• Read (and understand) error messages
• Read (and understand) compiler warning
• Document and read docu...
TALK ABOUT
CONVENTIONS
• Keep a document
• Make newbie's read the document
• Discuss conventions with your team
• Make any...
TALK ABOUT CODE
• Code reviews
• Code analysis sessions
• Talk about code when you give advice
• Talk about code when you ...
TALK ABOUT CODE
• Talk about your experience with the
code
• This made me expect that…
• From this I understood right away...
DON’T
TALK ABOUT CODE
When you cannot understand it
USE TOOLING
• To measure (size, relations complexity
etc.) – do not count lines
• To enforce quality standards and
convent...
MAKE SURE
EVERYONE
READS
CODE COMPLETE
PART THREE
Trade secrets
CULTURE CLASH
SW Business and SW craftsmanship
are not the same
THINGS ARE IMPROVING
• Human factor weighs in
• AGILE – development as a partnership
• Costs and benefits of quality are b...
STILL, THIS
Is sometimes applicable to the quality
of your code
USE YOUR BRAIN
• Say what you think
• Stick to your estimates
• Accept lower quality
as a legitimate
business decision
• P...
KEEP CALM !!!
THANK YOU,
972-54-8003775
Asher . Barak @ gmail . com
CONNECT WITH ME
GET THE SLIDES
http://goo.gl/AWWUKf
If you want to reuse
the slides for your
talk, Please contact
me first.
Software Craftsmanship Code Complete
Upcoming SlideShare
Loading in …5
×

Software Craftsmanship Code Complete

2,899 views

Published on

Writing better code and managing complexity following the principals of the all times programming classic Code Complete by Steve McConnell

Check out the video: http://goo.gl/hbXLPZ

Published in: Technology
  • Be the first to comment

Software Craftsmanship Code Complete

  1. 1. NEW PERSPECTIVE Asher Barak
  2. 2. PART ONE ne principle to rule them all
  3. 3. 1920 - 2012 one of the founders of the cognitive psychology field GEORGE A. MILLER
  4. 4. THE MAGICAL NUMBER 2
  5. 5. 1930 - 2002 Dutch computer scientist Edsger W. Dijkstra Go To Statement Considered Harmful
  6. 6. SOFTWARE Is Too Complex For Our BRAIN
  7. 7. MANAGING COMPLEXITY Your #1 goal should be
  8. 8. ARISTOTLE Geek philosopher 384 – 322 BCE
  9. 9. Essential Accidentalvs
  10. 10. SOFTWARE COMPLEXITY • Computers speak a binary language • Computers are batch machines • There is a wide gap between coding and running software • Computers are terrible with concurrency • Computers have physical limitations • Computer software model a complex world Essential
  11. 11. ONE THING AT A TIME
  12. 12. CARE ABOUT LESS • Do as little as possible • Divide (& conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  13. 13. LANGUAGE FUNDAMENTALS
  14. 14. Class Method Procedural Code
  15. 15. Layer Module Class
  16. 16. USE INTERFACES • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  17. 17. CODING PRACTICES
  18. 18. THINK OF YOUR AUDIENCE (It’s not the compiler)
  19. 19. NAME STUFF • With the right name • In a standard way • Methods – For what they do • Functions – For what they return • Classes – For what they represent • Modules – For what they pack
  20. 20. USE CONVENTIONS Any convention is better than no convention Every convention is one less thing to think about
  21. 21. USE CONVENTIONS • Naming Conventions • Method parameters conventions • Resources placing conventions • Documenting conventions • Code layout conventions • Meeting conventions • Everything conventions
  22. 22. USE CONVENTIONS
  23. 23. CONSISTENT ABSTRACTIONS Problem Domain Language/Platform
  24. 24. CONSISTENT ABSTRACTIONS Problem Domain Problem Domain Lower Level
  25. 25. USE DESIGN PATTERNS • They represent a higher abstraction over coding details • They simplify communications in the team • They are conceptual standard reusable units
  26. 26. TDD • Promotes better divisions • Promotes better abstractions • Promotes better documentation • Promotes better personal character • Restrains complexity
  27. 27. DESIGN BEST PRACTICES
  28. 28. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  29. 29. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  30. 30. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  31. 31. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  32. 32. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  33. 33. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  34. 34. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  35. 35. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  36. 36. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  37. 37. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  38. 38. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  39. 39. • Do as little as possible • Divide (And Conquer) • Hide the details - Work with layered abstractions • Reduce the noise
  40. 40. PART TWO Make it your own
  41. 41. PROGRAMMING IS DONE SOLO Creating a culture requires communication
  42. 42. FACE THE TRUTH Some people program for the wrong reasons
  43. 43. ACTIVELY ENCOURAGE SOCIALIZING Preferably of people who like their job
  44. 44. TALK ABOUT THE PROCESS
  45. 45. BE OPENLY EXCITED ABOUT GOOD CRAFTSMANSHIP (With tears if possible)
  46. 46. TALK ABOUT READABILITY Is it good for readability or is it bad?
  47. 47. TALK ABOUT ABSTRACTIONS Try splitting discussion the way code is split
  48. 48. ACTIVELY ENCOURAGE MORE DESIGN This is hardly ever a problem
  49. 49. ACTIVELY ENCOURAGE DESIGN CONSULTING Everyone ends up smarter
  50. 50. PUT PERFORMANCE & EFFICIENCY SECOND Maintainability first
  51. 51. PUT PERFORMANCE & EFFICIENCY SECOND • We are not good at anticipating resources issues • We are not good at anticipating performance issues • KISS until otherwise proven
  52. 52. HAVE EXPECTATIONS • Read (and understand) error messages • Read (and understand) compiler warning • Document and read documentation • Know (and avoid) code smells (Keep a document)
  53. 53. TALK ABOUT CONVENTIONS • Keep a document • Make newbie's read the document • Discuss conventions with your team • Make any code feel at home to everyone in the company
  54. 54. TALK ABOUT CODE • Code reviews • Code analysis sessions • Talk about code when you give advice • Talk about code when you take a break – be creative
  55. 55. TALK ABOUT CODE • Talk about your experience with the code • This made me expect that… • From this I understood right away that… • This was misleading/ did not follow the standard/ was too long / short
  56. 56. DON’T TALK ABOUT CODE When you cannot understand it
  57. 57. USE TOOLING • To measure (size, relations complexity etc.) – do not count lines • To enforce quality standards and conventions • To boost productivity • To avoid human errors
  58. 58. MAKE SURE EVERYONE READS CODE COMPLETE
  59. 59. PART THREE Trade secrets
  60. 60. CULTURE CLASH SW Business and SW craftsmanship are not the same
  61. 61. THINGS ARE IMPROVING • Human factor weighs in • AGILE – development as a partnership • Costs and benefits of quality are better understood • SW management is more experienced
  62. 62. STILL, THIS Is sometimes applicable to the quality of your code
  63. 63. USE YOUR BRAIN • Say what you think • Stick to your estimates • Accept lower quality as a legitimate business decision • Pick your battles • Keep doing what you love in acceptable conditions
  64. 64. KEEP CALM !!!
  65. 65. THANK YOU,
  66. 66. 972-54-8003775 Asher . Barak @ gmail . com CONNECT WITH ME
  67. 67. GET THE SLIDES http://goo.gl/AWWUKf If you want to reuse the slides for your talk, Please contact me first.

×