Software Craftsmanship Code Complete

2,724 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,724
On SlideShare
0
From Embeds
0
Number of Embeds
864
Actions
Shares
0
Downloads
30
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.

    ×