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.

Software Craftsmanship Code Complete

2,921 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.

×