tung_nt@septeni-technology.jp

Pay off Technical Debt by Good Code...and more

TechTalk 10 - 2016

Agenda

Technical Debt

Whats technical debt & why its important

Bad smells

Consequences

Where does it come from?

How to deal with it?

Supple & Clean Design

Clean Code Principles

Agile method

Measuring & Tools

Metrics

Code analyzer tool

Resources

Good books

I. Technical Debt

Technical Debt ?

Technical Debt is a metaphor developed by Ward Cunningham in 1992 to communicate problems due to "developing not in the right way" with non-technical stakeholder

2 ways to do things

Quick and Dirty

Slow and Clean

You may be thinking

Debt isnt always a bad thing...

But don't underestimate your risks.

Cancer & Diabetes

The top two causes of death.

Cannot be cured.

Difficult to diagnose: we are failing to spot them until its too late ~> The Silent Killer

Because...

Technical Debt like Cancer or Diabetes, Its a Silent Killer too. And nobody cares until its to late.

Whats your choice?

Tradeoff: Pay it now or later (...with interest)?

Dont let the debt kill your project

Bad smells

Only he know how to change it.

If I touch, everything will break.

Too many Todos

Legacy Codebase

The code is simply unreadable, and borders on indecipherable.

Data structures are haphazardly constructed, or non-existent

Hard to change or scale

Code duplication

Lack of documentation

- Did we mention documentation?- What documentation?

Consequences

Big ball of Mud

alias Shantytown or Spaghetti Code. A big ball of mud is a software system that lacks a perceivable architecture

Loss of Productivity

Reduce your software quality

Being scared of changing anything

Can be stress

Cost increases

Uhm, So...

Where does debt & mud come from?

Common causes

Business pressures

Lack of process or understanding

Lack of building loosely coupled components

Lack of a test suite

Lack of documentation

Lack of collaboration

Parallel development

Common Causes (cont.)

Delayed refactoring

Lack of alignment to standards

Lack of knowledge

Lack of ownership

Poor technological leadership

Last minute specification changes

Scope Doping

II. How to deal with them

Supple and Clean Design

Making Behavior Obvious

Intention-revealing interfaces

Name classes and operations to describe their effect and purpose

These names should conform to the Ubiquitous Language so that team members can quickly infer their meaning.

Side-effect-free functions

Place as much of the logic of the program as possible into functions

Strictly segregate commands into very simple operations that do not return domain information.

Assertions

State post-conditions of operations and invariants of classes and Aggregates.

If Assertions cannot be coded directly in your programming language, write automated unit tests for them.

Write them into documentation or diagrams where it fits the style of the projects development process.

Accelerating the learning curve and reducing the risk of contradictory code.

Reducing Cost of Change

Conceptual Contours

Decompose design elements (operations, interfaces, classes, and Aggregates) into cohesive units.

Standalone Classes

The class will be completely self-contained and can be studied and understood alone.

Self-contained class significantly eases the burden of understanding a Module.

Design By Contract

Defensive programming style

Clean code

DRY

Dont repeat yourself

SOLID

S - Single responsibility principlea class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class)

O - Open/closed principlesoftware entities should be open for extension, but closed for modification.

L - Liskov substitution principleobjects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

I - Interface segregation principlemany client-specific interfaces are better than one general-purpose interface.

D - Dependency inversion principleone should Depend upon Abstractions. Do not depend upon concretions.

High cohesion & Low coupling

Loose coupling makes it possible to:Understand one class without reading others

Change one class without affecting others

Improves maintainability

High cohesion makes it easier to:Understand what a class or method does

Reuse classes or methods

YAGNI & KISS

You aren't gonna need it

Keep it simple, stupid

TDD

Focus into acceptance criteria

Make code testable

Agile method

Definition of Done (DoD)

Clear DoD make Design By Contract and TDD coding style applied easier

Technical backlog

Manage by PM or Technical Leader

Easy to monitorDebt size

The velocities of debt fixing

Fix by debt priority

No mixture between technical and feature task

Visible and clear to everybody

Cost of Change

Code of change curve with the feedback cycle

Fail fast

Refactor AS SOON AS POSSIBLE

III. Measuring & Tools

Measurement

Only one rule you need remember

Thats the joke

Metric 1

Compiler warning / error

Metric 2

TODOs

Metric 3

Amount of Duplicate code

Metric 4

Test coverage & C.R.A.P index (Change Risk Analysis and Predictions)

Metric 5

Total Line Of Code in 1 file

@Bulk members: BulkLogicComponent.php, do you remember?

Evaluate Debt

Debt (in man days) = cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold

Where :

Duplications = cost_to_fix_one_block * duplicated_blocks Violations = cost_to fix_one_violation * mandatory_violationsComments = cost_to_comment_one_API * public_undocumented_apiCoverage = cost_to_cover_one_of_complexity * uncovered_complexity_by_tests (80% of coverage is the objective)Complexity = cost_to_split_a_method * (function_complexity_distribution >= 8) + cost_to_split_a_class * (class_complexity_distribution >= 60)

Tools

Sonarqube

SonarQube(sonarqube.org) is an open platform to manage code quality.

PMD - Don't shoot the messenger

Is a source code analyzer.

Only CPD (the copy-paste-detector) is supported for Scala :(

Jacoco Scoverage

Both of them are code coverage tool

Jenkin plugin is supported

Gatling Stress test tool

Gatling is an open-source load testing framework based on Scala, Akka and Netty

Scenario recorder and developer-friendly DSL

Ready-to-present HTML reports

Resources

Read these:

One more thing...

References

https://en.wikipedia.org/wiki/Technical_debt

http://www.levihackwith.com/how-to-read-and-improve-the-c-r-a-p-index-of-your-code/

http://www.sonarqube.org/evaluate-your-technical-debt-with-sonar/

https://blog.codinghorror.com/paying-down-your-technical-debt/

https://dzone.com/articles/real-cost-change-software

http://www.agilemodeling.com/essays/costOfChange.htm

http://www.dodgycoder.net/2013/01/big-ball-of-mud-design-pattern.html

https://pressupinc.com/blog/2015/04/why-software-becomes-a-big-ball-of-mud/

http://www.slideshare.net/lemiorhan/technical-debt-do-not-underestimate-the-danger

http://www.gregerwikstrand.com/technical-debt-reduction/

Thank you!