Managing Technical Debt

Managing Technical
Debt
By:
Adam Culp
Twitter: @adamculp

2
Managing Technical Debt
●
About me
– OSS Contributor
– PHP Certified
– Zend Certification Advisory Board
– PHP-Fig voting member (IBM i Toolkit)
– Consultant at Zend Technologies
– Organizer SoFloPHP (South Florida)
– Organizer SunshinePHP (Miami)
– Long distance (ultra) runner
– Photography Enthusiast
– Judo Black Belt Instructor

3
●
About me
– OSS Contributor
– PHP Certified
– Zend Certification Advisory Board
– PHP-Fig voting member (IBM i Toolkit)
– Consultant at Zend Technologies
– Organizer SoFloPHP (South Florida)
– Organizer SunshinePHP (Miami)
– Long distance (ultra) runner
– Photography Enthusiast
– Judo Black Belt Instructor
I am the
PHP Ninja!!!

4
●
Fan of iteration
– Pretty much everything requires iteration to do well:
●
Long distance running
●
Judo
●
Development
●
Evading project managers
●
Managing Technical Debt!

5
●
What is Technical Debt?

6
●
– Code Smells
...a code smell is any characteristic in the
source code of a program that possibly
indicates a deeper problem… - wikipedia
https://en.wikipedia.org/wiki/Code_smell

7
●
Code “smells”
– “Smells” hinting a refactor may be needed:
●
Duplicate Code (rule of 3)
●
Long Methods
●
Large Class
●
Long Parameter (argument) List
●
Divergent Change – cascade change to accommodate another
●
Shotgun Surgery – change ripples as bugs
●
Feature Envy – method uses parts from other class
●
Switch Statements – sacrifice polymorphism

8
●
Code “smells”
– Cont'd:
●
Lazy Class – class not doing much
●
Speculative Generality – something built for possible future
●
Temporary Field/Variable
●
Message Chains – object asking object asking object
●
Middle Man – directors in place but serve no real purpose
●
Inappropriate Intimacy – classes share private parts
●
Data Class – getters and setters, but nothing else
●
Comments – where comments cover bad code

9
● Comments can also be a bad “smell“
●
Comments are often used to cover up bad code.
●
Code should be self-documenting

10
● Coding Standards save time
●
Gives direction
●
PHP Framework Interoperability Group (https://www.php-fig.org).
●
Standard NOT important
●
Unless it‘s public code
●
Choose one
●
Stick with it
●
Consistency is key

11
● Names should be clear
●
Functions and variables should tell a story.
$elapsedTimeInDays;
$daysSinceCreation;
$daysSinceModified;
$fileAgeInDays;
$elapsed;
$createdDays;
$modifiedDays;
$age;
GoodBad

12
● Shy away from variations of the same name
●
To ensure names are different enough to portray difference.
$product
$productInfo
$productData
$productDescription
What is the difference between these?

13
● Certain characters are hard to understand
Lower case L
Uppercase O (oh)
Uppercase I (eye)
Bad

14
● Technical names help developers who actually read the code.
● Non-technical terms for client documentation.
● Class names should be nouns
●
Describe.
●
Ex. - Customer, Account, Product, Company.
● Method names should be verbs
●
Action.
●
Ex. - getCustomer, closeAccount, updateProduct, addCompany.
●
Pick a set of keywords and stick with them.
●
Ex. - fetch, get, add, update, remove, delete

15
● More on Clean Code
●
Functions:
●
Short
●
Single purpose
●
As expected
●
Well named
●
Recognizing bad doesn't mean we know how to make good
●
We know a good/bad song, but are not song writers
●
Clean code = caring developer
●
Does not require many comments

16
●
– Code Smells
– Impossible to avoid
– Builds up like credit card

17
●
Causes of Technical Debt?
– Happens while coding
●
Adding functionality
●
Enhancing logic

18
●
●
●
Enhancing logic
– Architectural
●
Passwords in source control
●
Domain names in code
●
Env info in code

19
●
●
●
Enhancing logic
– Architectural
●
●
●
Env info in code
– Deadlines

20
●
●
●
Enhancing logic
– Architectural
●
●
●
Env info in code
– Deadlines
– Tech un-savvy boss

21
●
●
●
Enhancing logic
– Architectural
●
●
●
Env info in code
– Deadlines
– Tech un-savvy boss
– YOU!

22
●
What about support items?
– Lack of documentation
– Lack of license
– No Sharing (OSS)
– Ignoring Community

23
●
Why Remove Technical Debt?
– More creating and less reading

24
●
– Easier onboarding

25
●
– Less bugs
– Reduce unexpected behavior

26
●
– Less bugs
– Reduce unexpected behavior
– Happier developers, customers, boss
– More money!

27
●
When To Remove Technical Debt?
– Always!
– Part of “Normal Development” cycle
●
Code...refactor...code...refactor...etc.

28
●
Tools To Find Technical Debt?
– Static Analysis
●
3rd party
– Exakat Cloud
●
Self-hosted is free
●
Cloud hosted commercial product
●
Pricing model is complicated

29
●
– Static Analysis
●
3rd party
●
SaaS
– Codacy
– CodeClimate
– Scrutinizer

30
●
– Static Analysis
●
3rd party
●
SaaS
●
OSS
– Codesniffer
– PHP Mess Detector (phpmd)
– PHP Copy/Paste Detector (phpcpd)
– PHPDepend
– PHPStan
– Phan
– PHPMetrics
Good source:
https://github.com/exakat/php-static-analysis-tools

31
●
Containers
– Job specific images
●
https://hub.docker.com/u/adamculp/

32
●
Containers
– Job specific images
●
https://hub.docker.com/u/adamculp/

33
●
Automation
– Static Analysis Automated
●
Continuous delivery/integration
●
Source control hooks
●
IDE

●
Thank you!
– Code: https://github.com/adamculp/
Adam Culp
http://www.geekyboy.com
http://RunGeekRadio.com
Twitter @adamculp
Questions?

Managing Technical Debt

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Managing Technical Debt

Ähnlich wie Managing Technical Debt (20)

Mehr von Adam Culp

Mehr von Adam Culp (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Managing Technical Debt