0
The Taming of the Code<br />Alan Stevens<br />A tale of the first principles of software development presented in three ac...
Who is Alan Stevens?<br />Microsoft Most Valuable Professional<br />ASP Insider<br />Occasional Blogger http://netcave.org...
PLAYBILL<br />Act I: The Goal<br />Act II: The Guidelines<br />Act III: The Practice<br />
Let’s Talk About Code<br />
Act I: The Goal<br />
The rest of a developer&apos;s career is spent pursuing better and better answers to the question &quot;where should this ...
Once you get your systems to work, you still have to go back and clean up the wreckage left behind by the victorious battl...
How do we balance building the right thingwith building it well?<br />
Building the right thing is always a higher priority!<br />
I&apos;m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of...
Building it right has a minimum acceptable thresholdwhich must be met<br />
Do the simplest thing that could possibly work<br />
Enable Change<br />
Build Architectural Seams<br />
At least build fault lines<br />
Manage Debt<br />
Manage Technical Debt<br />
I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would...
By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to...
You know, if you want to be able to go into debt that way by developing software that you don&apos;t completely understand...
Enable The *ILITIES<br />Coined by KevlinHenney<br />Agility<br />Testability<br />Readability<br />Reversibility<br />Cha...
Act II: The Guidelines<br />
Don’t Repeat Yourself&Separation of Concerns<br />
DRY<br />Don’t Repeat Yourself<br />
The Rule of Three<br />See it once: do it<br />See it twice: notice it<br />See it a third time: abstract it!<br />
Separation of Concerns<br />
Separation Of Concerns<br />Break the system into distinct, cohesive modules that don’t overlap in responsibilities<br />E...
Cohesion<br />The degree to which the responsibilities within a given class are strongly related<br />Highly cohesive code...
protected void btnSubmit_click(object sender, EventArgs e)<br />{<br />    if ( this.IsValid(this.txtUserName.Text, this.t...
SOLID Principles<br />Single Responsibility Principle<br />Open Closed Principle<br />Liskov Substitution Principle<br />I...
The Single Responsibility Principle <br />A class should have one, and only one, reason to change.<br />Granularity<br />H...
The Open Closed Principle<br />You should be able to extend a classes behavior, without modifying it.<br />Sealed classes ...
The Liskov Substitution Principle <br />Derived classes must be substitutable for their base classes.<br />Preserve polymo...
The Interface Segregation Principle <br />Clients should not be forced to depend on interfaces that they do not use.<br />...
The Dependency Inversion Principle <br />Depend on abstractions, not on concretions.<br />User interfaces and/or abstract ...
Act III: The Practice<br />
How do we guarantee baseline design without impeding productivity?<br />
Upcoming SlideShare
Loading in...5
×

The Taming Of The Code

729

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
729
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
10
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • The Taming of the Code:A tale of the first principles of software development presented in three actsHow do we balance building the right thingwith building it well? In this presentation we will examine this question at three levels of focus looking at I The Goal, II The Guidlines and III The Practice. This will be an interactive discussion of the values, compromises and practices of successful software development.
  • Drafts when writing
  • Enable isolationFault lines
  • SRP The Single Responsibility Principle A class should have one, and only one, reason to change.OCP The Open Closed Principle You should be able to extend a classes behavior, without modifying it.LSP The Liskov Substitution Principle Derived classes must be substitutable for their base classes.ISP The Interface Segregation Principle Clients should not be forced to depend on interfaces that they do not use.DIP The Dependency Inversion Principle Depend on abstractions, not on concretions.
  • Transcript of "The Taming Of The Code"

    1. 1. The Taming of the Code<br />Alan Stevens<br />A tale of the first principles of software development presented in three acts<br />
    2. 2. Who is Alan Stevens?<br />Microsoft Most Valuable Professional<br />ASP Insider<br />Occasional Blogger http://netcave.org<br />Senior Software Developer<br /> Interactive Intelligence Incorporated<br />An Enthusiast NOT an expert!<br />
    3. 3. PLAYBILL<br />Act I: The Goal<br />Act II: The Guidelines<br />Act III: The Practice<br />
    4. 4. Let’s Talk About Code<br />
    5. 5. Act I: The Goal<br />
    6. 6. The rest of a developer&apos;s career is spent pursuing better and better answers to the question &quot;where should this code go?&quot;<br />Jeremy Miller<br />“On Writing Maintainable Code”<br />http://codebetter.com/blogs/jeremy.miller/archive/2006/12/06/On-Writing-Maintainable-Code.aspx<br />
    7. 7. Once you get your systems to work, you still have to go back and clean up the wreckage left behind by the victorious battle. You are not done until the victorious code has been cleaned, polished, and oiled.<br />“Uncle” Bob Martin<br />“The Rush”<br />http://blog.objectmentor.com/articles/2009/06/26/the-rush<br />
    8. 8. How do we balance building the right thingwith building it well?<br />
    9. 9. Building the right thing is always a higher priority!<br />
    10. 10. I&apos;m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.<br />Ward Cunningham<br />“Ward Explains Debt Metaphor”<br />http://c2.com/cgi/wiki?WardExplainsDebtMetaphor<br />
    11. 11. Building it right has a minimum acceptable thresholdwhich must be met<br />
    12. 12. Do the simplest thing that could possibly work<br />
    13. 13. Enable Change<br />
    14. 14. Build Architectural Seams<br />
    15. 15. At least build fault lines<br />
    16. 16. Manage Debt<br />
    17. 17. Manage Technical Debt<br />
    18. 18. I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.<br />Ward Cunningham<br />“Ward Explains Debt Metaphor”<br />http://c2.com/cgi/wiki?WardExplainsDebtMetaphor<br />
    19. 19. By the same token, if you develop a program for a long period of time by only adding features and never reorganizing it to reflect your understanding of those features, then eventually that program simply does not contain any understanding and all efforts to work on it take longer and longer. In other words, the interest is total -- you&apos;ll make zero progress.<br />
    20. 20. You know, if you want to be able to go into debt that way by developing software that you don&apos;t completely understand, you are wise to make that software reflect your understanding as best as you can, so that when it does come time to refactor, it&apos;s clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now.<br />
    21. 21. Enable The *ILITIES<br />Coined by KevlinHenney<br />Agility<br />Testability<br />Readability<br />Reversibility<br />Changeability<br />Flexibility<br />Maintainability<br />
    22. 22. Act II: The Guidelines<br />
    23. 23. Don’t Repeat Yourself&Separation of Concerns<br />
    24. 24. DRY<br />Don’t Repeat Yourself<br />
    25. 25. The Rule of Three<br />See it once: do it<br />See it twice: notice it<br />See it a third time: abstract it!<br />
    26. 26. Separation of Concerns<br />
    27. 27.
    28. 28.
    29. 29. Separation Of Concerns<br />Break the system into distinct, cohesive modules that don’t overlap in responsibilities<br />Examples:<br />MVC, MVP, MVVM etc.<br />UI, Service, DAL<br />HTML, CSS, JavaScript<br />
    30. 30. Cohesion<br />The degree to which the responsibilities within a given class are strongly related<br />Highly cohesive code is:<br />More readable and easier to understand<br />Easier to manage, maintain, and test<br />More likely to be reused<br />Less complex<br />
    31. 31. protected void btnSubmit_click(object sender, EventArgs e)<br />{<br /> if ( this.IsValid(this.txtUserName.Text, this.txtPassword.Text) ) <br /> { // do stuff here }<br />}<br />private boolIsValid(string userName, string password)<br />{<br />boolisValid = false;<br /> using ( SqlConnectionconn = new SqlConnection(_connString) )<br /> {<br /> using ( SqlCommandcmd = conn.CreateCommand() )<br /> {<br /> // query on User Name and Password<br />isValid = cmd.ExecuteScalar();<br /> }<br /> }<br /> return isValid;<br />}<br />
    32. 32. SOLID Principles<br />Single Responsibility Principle<br />Open Closed Principle<br />Liskov Substitution Principle<br />Interface Segregation Principle<br />Dependency Inversion Principle<br />
    33. 33. The Single Responsibility Principle <br />A class should have one, and only one, reason to change.<br />Granularity<br />Have many small classes that are easy to understand<br />
    34. 34. The Open Closed Principle<br />You should be able to extend a classes behavior, without modifying it.<br />Sealed classes are evil!<br />Make classes virtual by default.<br />
    35. 35. The Liskov Substitution Principle <br />Derived classes must be substitutable for their base classes.<br />Preserve polymorphism.<br />
    36. 36. The Interface Segregation Principle <br />Clients should not be forced to depend on interfaces that they do not use.<br />No God objects!<br />
    37. 37. The Dependency Inversion Principle <br />Depend on abstractions, not on concretions.<br />User interfaces and/or abstract base classes<br />
    38. 38. Act III: The Practice<br />
    39. 39. How do we guarantee baseline design without impeding productivity?<br />
    40. 40. Can we verify that we are building the right thing?<br />
    41. 41. The tests specify requirements in a way that does not require human interpretation to indicate success or failure.<br />Jim Newkirk<br />Test Driven Development in Microsoft .NET<br />
    42. 42. Let’s write some code!<br />
    43. 43. Closing Thoughts<br />
    44. 44. When you finally realize what your program is doing, you have to go back and make it look like you knew that all along. Make it look like it was easy to write this program, even if it wasn’t.<br />Ward Cunningham<br />“Mastering the Craft of Programming”<br />http://railslab.newrelic.com/2009/09/15/ward-cunningham-aboutus-org<br />
    45. 45. Prevention is the best cure<br />
    46. 46. Continuous Improvement<br />
    47. 47. As applications mature, they should become more maintainable, not less.<br />
    48. 48. “With every mistake, I must surely be learning”<br />George Harrison<br />
    49. 49. Avoid Complacency<br />
    50. 50. Thanks For Listening!<br />Email/IM: alanstevens@gmail.com<br />Blog: http://netcave.org<br />Twitter: @alanstevens<br />
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×