1. The Taming of the Code Alan Stevens A tale of the first principles of software development presented in three acts

2. Who is Alan Stevens? Microsoft Most Valuable Professional ASP Insider Occasional Blogger http://netcave.org Senior Software Developer Interactive Intelligence Incorporated An Enthusiast NOT an expert!

3. PLAYBILL Act I: The Goal Act II: The Guidelines Act III: The Practice

4. Let’s Talk About Code

5. Act I: The Goal

6. The rest of a developer's career is spent pursuing better and better answers to the question "where should this code go?" Jeremy Miller “On Writing Maintainable Code” http://codebetter.com/blogs/jeremy.miller/archive/2006/12/06/On-Writing-Maintainable-Code.aspx

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. “Uncle” Bob Martin “The Rush” http://blog.objectmentor.com/articles/2009/06/26/the-rush

8. How do we balance building the right thingwith building it well?

9. Building the right thing is always a higher priority!

10. I'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. Ward Cunningham “Ward Explains Debt Metaphor” http://c2.com/cgi/wiki?WardExplainsDebtMetaphor

11. Building it right has a minimum acceptable thresholdwhich must be met

12. Do the simplest thing that could possibly work

13. Enable Change

14. Build Architectural Seams

15. At least build fault lines

16. Manage Debt

17. Manage Technical Debt

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. Ward Cunningham “Ward Explains Debt Metaphor” http://c2.com/cgi/wiki?WardExplainsDebtMetaphor

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'll make zero progress.

20. You know, if you want to be able to go into debt that way by developing software that you don'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's clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now.

21. Enable The *ILITIES Coined by KevlinHenney Agility Testability Readability Reversibility Changeability Flexibility Maintainability

22. Act II: The Guidelines

23. Don’t Repeat Yourself&Separation of Concerns

24. DRY Don’t Repeat Yourself

25. The Rule of Three See it once: do it See it twice: notice it See it a third time: abstract it!

26. Separation of Concerns

29. Separation Of Concerns Break the system into distinct, cohesive modules that don’t overlap in responsibilities Examples: MVC, MVP, MVVM etc. UI, Service, DAL HTML, CSS, JavaScript

30. Cohesion The degree to which the responsibilities within a given class are strongly related Highly cohesive code is: More readable and easier to understand Easier to manage, maintain, and test More likely to be reused Less complex

31. protected void btnSubmit_click(object sender, EventArgs e) { if ( this.IsValid(this.txtUserName.Text, this.txtPassword.Text) ) { // do stuff here } } private boolIsValid(string userName, string password) { boolisValid = false; using ( SqlConnectionconn = new SqlConnection(_connString) ) { using ( SqlCommandcmd = conn.CreateCommand() ) { // query on User Name and Password isValid = cmd.ExecuteScalar(); } } return isValid; }

32. SOLID Principles Single Responsibility Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle

33. The Single Responsibility Principle A class should have one, and only one, reason to change. Granularity Have many small classes that are easy to understand

34. The Open Closed Principle You should be able to extend a classes behavior, without modifying it. Sealed classes are evil! Make classes virtual by default.

35. The Liskov Substitution Principle Derived classes must be substitutable for their base classes. Preserve polymorphism.

36. The Interface Segregation Principle Clients should not be forced to depend on interfaces that they do not use. No God objects!

37. The Dependency Inversion Principle Depend on abstractions, not on concretions. User interfaces and/or abstract base classes

38. Act III: The Practice

39. How do we guarantee baseline design without impeding productivity?

40. Can we verify that we are building the right thing?

41. The tests specify requirements in a way that does not require human interpretation to indicate success or failure. Jim Newkirk Test Driven Development in Microsoft .NET

42. Let’s write some code!

43. Closing Thoughts

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. Ward Cunningham “Mastering the Craft of Programming” http://railslab.newrelic.com/2009/09/15/ward-cunningham-aboutus-org

45. Prevention is the best cure

46. Continuous Improvement

47. As applications mature, they should become more maintainable, not less.

48. “With every mistake, I must surely be learning” George Harrison

49. Avoid Complacency

50. Thanks For Listening! Email/IM: alanstevens@gmail.com Blog: http://netcave.org Twitter: @alanstevens