Automating Google Workspace (GWS) & more with Apps Script
The Taming Of The Code
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
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?
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
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
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
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
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
50. Thanks For Listening! Email/IM: alanstevens@gmail.com Blog: http://netcave.org Twitter: @alanstevens
Notas del editor
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.