Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Developer Job in Practice

Developer Job in Practice

Clean code rules • Code review • Refactoring

Kamil Kowalski

May 08, 2020
Tweet

Other Decks in Programming

Transcript

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

    View full-size slide

  2. 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

    View full-size slide

  3. 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

    View full-size slide

  4. 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

    View full-size slide

  5. 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.

    View full-size slide

  6. 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!

    View full-size slide

  7. 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.

    View full-size slide

  8. 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!

    View full-size slide

  9. 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.

    View full-size slide

  10. 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 !

    View full-size slide

  11. 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!

    View full-size slide

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

    View full-size slide