Architecting for Multiple Cores

RoCk SOLiD KnOwledge http://www.rocksolidknowledge.com

Code Quality

Metronomic build/fix/deploy cycle Bug count always low per release End users love the app as it never crashes  Stakeholder  QA  Support team  Project Manager  Devs 

Code spends most of its life being maintained How hard is it to learn any new code base? What is your legacy? My $hit code will be your problem tomorrow Your $hit code will be my problem today

Code is rarely done unless it’s demo code Business requirements change all the time Code must therefore be engineered to handle continual refactor Code must be thought of as highly malleable Every line is always up for possible refactor How will you survive dominate in this world?

Why write tests? Validate class behaviour now and future proof it Domain classes with behaviour must have tests Data classes don’t need tests Write meaningful tests Be highly suspicious of 100% unit test coverage  Be judicious; spend money where needed Write tons of tests for critical algorithm Don’t write tons of tests for 3 line method Learn TDD then Practice TDD

“A ‘God Class’ is an object that controls way too many other objects in the system and has grown beyond all logic to become The Class That Does Everything.” [http://c2.com/cgi/wiki?GodClass] The signs 1200 SLOC? 50 private methods? 35 fields? No one in the team understands how it works?

Class is hard to test? Lots of complicated test setup code? Lots of Asserts per test? A unit test should only have a single Assert

Class should have one responsibility Refactor God class into multiple SRP classes Write unit tests for each SRP class

Signals: Many lines of code, tons of methods but few classes Avoid function decomposition Private method syndrome Private methods cannot be unit tested Embrace class decomposition Lots of little classes Write battery of unit tests for each little class Refactor big private methods out into their own class (see ‘method-object’ Kent Beck)

Don’t miss out on GOF patterns Factory, Null Object, Decorator, Adapter etc Patterns signal intent to other developers Use only when needed Don’t force them in when not needed Be suspicious of large code base that doesn’t use patterns  Beware Dunning-Kruger Effect

“Cyclomatic complexity is a software metric (measurement), used to indicate the complexity of a program. It is a quantitative measure of the number of linearly independent paths through a program's source code.” [https://en.wikipedia.org/wiki/Cyclomatic_co mplexity]

Complicated code is hard to understand Nested if/else with lots of || and && Cyclomatic complexity is the work of the devil Reduce use of imperative programming style e.g. if/else/switch Flock of seagulls lead to the gates to Hades {{{}}} Challenge each other to reduce heavy use of them Good use of OO, LINQ & patterns will help achieve this goal Favour a functional programming style e.g. LINQ But avoid nested lambda hell

Dashboards like Sonar publish cyclomatic complexity during the build for all to see Visual Studio “Code Metrics” gives cyclomatic complexity drill down ReSharper add-on can graphically show cyclomatic complexity in Visual Studio

Static references & classes defeat unit testing E.g. How do you mock DateTime.Now for daylight savings unit tests when they run on January 14th? Wrap use of static classes in an injected singleton that delegates to static implementation E.g. Define and implement IDateTime interface Avoid ‘XyzHelper’ or ‘Util’ classes like the plague!

Take time to name every artefact Class, method, field, property, parameter, automatic variable (prod code + test code) Class name is a noun Method name is a verb E.g. dog.Sleep(), table.Clear(), documentAggregator.Aggregate() Stuck for class name? http://classnamer.com  E.g. for(int p = 0; p < 10; p++) {} for(int personIndex = 0; personIndex < 10; personIndex++) {}

Broken Window Theory “maintaining and monitoring urban environmen ts to prevent small crimes such as vandalism, pu blic drinking and toll- jumping helps to create an atmosphere of order and lawfulness, thereby preventing more seriou s crimes from happening” Corollary: Keep code+tests uber clean [https://en.wikipedia.org/wiki/Broken_windows _theory]

Default to avoid inheritance: ‘is-a’ Why? Derived often needs to know base intimately Default to favour composition: ‘has-a’ Only cave-in when ‘is-a’ rule satisfied Dog is-a bone: fail Dog has-a bone: pass Cat is-a mammal: pass Cat has-a mammal: fail

Ideally every check-in gets peer reviewed prior to check-in Each check-in should have: Description + name of reviewer Over the shoulder review preferential Rotate reviewers and share knowledge and tips within the team == free peer training; level up Also back up with post commit code review tool e.g. Crucible

1. Park egos at the door 2. Team first attitude 3. Test coverage good? 4. Lots of private methods? God class? 5. Inheritance satisfies ‘is-a’ rule? 6. Interface based programming? Use of ‘new’ operator? 7. Good class/method/field/prop/auto names?

Domain class constructor takes interface parameters only (C#) Don’t new domain class from within domain class (fine to new framework classes e.g. List, Hashset etc) Why? Testing class A would be implicit test of B as well Constructor stores interface parameter in field Constructor does nothing else Why? Interface can easily be mocked therefore easy to test Use 2-phase construction via Initialize() method if needed

Comments are very useful for big and complicated things Warning: Comments quickly get out of date with respect to code during refactor Comments not necessary for small and easy to understand things Corollary: Only create small, easy to understand well named things and therefore ditch comments

Excessive null checking is a Code smell if (dog != null) {} OR if (dog == null) Consider Null Object Pattern

Author a 1 page annotated coding standard Why? If it all looks like it was written by one person then it’s going to be easier maintain/learn Get dev buy-in by building team consensus on content Print it off for everyone to put on the wall by their desk Police it with code review Use tooling: e.g. Write a Resharper standard and share with the team

Every domain class should should be accompanied by an interface What is a domain class? One that has behaviour Pass IDogController around, not DogController Why? Decrease coupling between classes

In the old days single method return was  Why? Because of long complicated methods in God classes Requires carefully nested method if/else hierarchy If you don’t have God classes with long complicated methods then you have no fear of multiple method returns any more  Why? Simpler to read due to dramatic reduction in nested if/else hierarchy

Regions (#region) are a great place to hide code  Often commented out code can be found hiding in them God classes often lurk within regions pretending to not be God classes Grrrrr

App developers are often wannabe framework developers Allow base classes to emerge from ongoing requirements Don’t try and predict the future now Avoid marking a method as virtual unless there is a class to override it right now

All C# devs should use ReSharper Essential for quick and accurate refactoring Set up shared team coding style Reformat class(es) automatically before check-in Find type Find implementation of interface/method Refactor name of class/method/field/auto etc

Polymorphism: check Interface based programming: check Generics: check Iterators: check LINQ: check async/await: check

Do they care about code quality? Ask them! When was the last time they checked-in a unit test? Prove it! Get them to write an algorithm on the white board and a unit test for it Get them to come up with the list of tests they would write for the algorithm Ensure good CS background: data structures & algorithms Make sure they really know all the latest stuff (passion) Never hire a ‘maybe’ Ensure good team fit – everyone meets the candidate

Code quality directly impacts $takeholder through to end user experience Up the ante: Make code quality your mission Write good quality unit tests Maintain a hygienic code base (inc tests) Build a legacy your team is proud of that your users will love

Clean Code: A Handbook of Agile Software Craftsmanship, Robert C Martin aka Uncle Bob Awesome google talk (Misko Hevery) http://www.youtube.com/watch?v=acjvKJiOvXw