Developer Job in Practice Clean code rules • Code review • Refactoring Kamil Kowalski [email protected]

2 Being a developer Disclaimer: THESE ARE PRINCIPLES, NOT LAWS! § You need to follow the rules, whether they are § You should ask the questions – especially in case of doubts Developer’s job is not only about developing the code § You should learn new things: all the time, always and from others § ... till end (of time) § It would be great to have a leader: § to learn from § to follow § You are the team player § You work with legacy systems

3 Typical project setup § Waterfall, Agile, ... § How project is run: § Scrum § Kanban § Programin Mother*ker § Developing the code § Code first § TDD § Who needs unit tests / We don’t test our code J There is no one! Each single project has its own setup! § Tools: § IDE – Xcode, Visual Studio, IntelliJ, ... § Repository: Git, SVN, ... § CI environment: Azure DevOps, Jenkins, Bamboo, CircleCI, … § Scripts: JavaScript, Python, MsBuild, PowerShell, Bash/Zsh, Make, … § Supporting tools: Lint, R#, StyleCop, … § Review Tool § Project board, back trucking: JIRA § Code guide § Definition of Done / Definition of Ready § Build in one step & daily builds

4 Definition of Done / Definition of Ready § DoD / DoR says about the rules you need to follow during daily work § Each developer in team need to follow DoD – no exceptions! § Each team member need to follow DoR – no exceptions! § Each single project has its own DoD / DoR DoD / DoR is our contract! § Sample DoD: § All unit tests passed § All integration tests passed § No warnings in code (also warnings from Lint / StyleCop) § Code coverage over 91% § Max cyclomatic complexity below 12 § Build passed on CI server § Sample DoR: § Functionality working (all AC’s met) § Unit test written § Code approved by 2 other developers § QA accepted § Functionality available on CI staging environment § Documentation updated

5 Code smells § Duplicated Code § Long Method § Large Class § Long Parameter List / too many of them § Switch Statement § Temporary Field § Magic numbers § Naming § Complex Conditionals § Dead code If it stinks, change it! § High quality code is: § Easy to read and understand § Impossible to hide bugs § Easy to extend § Easy to change § Has unit tests § Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

public class Record_Base { public DateTime RecordDateTime { get { return _recordDateTime; } set { if (this.GetType().Name == "Record_PartRegister") _recordDateTime = value; else throw new Exception("Cannot call set on RecordDateTime for table " + this.GetType().Name); } } } http://thedailywtf.com/Articles/Making-Off-With-Your-Inheritance.aspx This is not OOP!

STUPID code 7 What Makes Code STUPID § Singleton § Tight Coupling § Untestability § Premature Optimization § Indescriptive Naming § Duplication § Singleton Programs using global state are very difficult to test. Programs that rely on global state hide their dependencies. Why Singletons Are Controversial? Why is Singleton considered an anti pattern? So Singletons are bad, then what? § Tight Coupling If changing one module in a program requires changing another module, then coupling exists. Reducing Coupling (Martin Fowler) § Untestability Testing should not be hard! Whenever you don't write unit tests because you don't have time, the real issue is that your code is bad.

STUPID code 8 What Makes Code STUPID § Singleton § Tight Coupling § Untestability § Premature Optimization § Indescriptive Naming § Duplication § Premature Optimization Optimizing before we know that we need to. There is only cost and no benefit. PrematureOptimization Anti-Pattern § Indescriptive Naming Name your classes, methods, attributes, and variables properly. Don't abbreviate, never! § Duplication Don't Repeat Yourself! Keep It Simple, Stupid!

KISS my DRY and SOLID code 9 Simple rules for developers – how to write the code § Keep It Simple - Stupid § Don’t Repeat Yorself § You Aren’t Gonna Need It? § Uncle Bob Clean Code(r) § SOLID principles: § Single Responsibility Every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. § Open / Closed principle Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. § Liskov Substitution Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. § Interface Segragation Clients should not be forced to depend on methods they do not use. § Dependency Inversion Abstractions should not depend on details. Details should depend on abstractions.

10 Code reviews § Can catch up to 60% of defects § Effective code reviews are: § Short – don’t waste time § Constructive § Avoid emotionally draining arguments § Code review rules depend on project you’re working on - samples: § Banking system - SOLID, security § NASA § Games - optimization , code efficiency, don’t care about exceptions § Mobile application – SOLID, but efficiency Everybody reviews and everybody is reviewed. § Rules: § Syntax ! § Code Style – be project StyleCop (naming) § Simplicity § DRY violations § SOLID violations § Security – buffers, stack overflow, input dfata sanity (trust no one), cross boarders (SQL injection, XSS) § Memory leaks § Optimization - code efficiency § Strings !

11 Why should I refactor? § Technical what?! - is a metaphor: § doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt § incurs interest payments, which come in the form of the extra effort that we have to do in future development. § Refactoring is changing the structure, but not the functionality of your application. Refactoring is our way of paying off our “Technical Debt” § How Should I Refactor: § Ask yourself the following questions: § Is my code readable? § Is my code abstract? § Anything more is rearranging the deck chairs on the Titanic: § It gives you a sense of doing something § But ultimately it’s pointless L § Follow the rules: § KISS / DRY / SOLID § Clean code § Code review rules!

• Refactoring catalogs: http://www.refactoring.com/catalog/index.html Resources