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,792 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
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,792
On SlideShare
0
From Embeds
0
Number of Embeds
868
Actions
Shares
0
Downloads
33
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • דבר בשפת הבעיהצור רמת הפשטה אחרישה בשכבה – כאן מדברים על DB, כאן על חבילות בלוניםכמה שפחות קשרי גומלין
  • With the right name– if you are not sure of the name you do not know what you are doing
  • שלח את מי שכתב אותו למקצה שיפורים
  • בפיתוח כמו RESHARPERבדיקות COVERAGEב QUALITY GATES ב CHECKINבתהליך ה BUILD
  • שלח את מי שכתב אותו למקצה שיפורים
  • אני חושב שיש לנו מזל שאנחנו עושים משהו שאנחנו PASSIONATE לגביו. אני מתפעל מזה שמישהו אחר עומד מול הלקוחות.
  • אני חושב שיש לנו מזל שאנחנו עושים משהו שאנחנו PASSIONATE לגביו. אני מתפעל מזה שמישהו אחר עומד מול הלקוחות.
  • 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.

    ×