What is Clean Code
“Clean code always looks like it was written by someone who cares”
~ Michael Feathers
Slide 7
Slide 7 text
Not only working software, but also
well-crafted software
Manifesto of Software Craftmanship
Slide 8
Slide 8 text
Benefit & Goals
Slide 9
Slide 9 text
● Increase Maintainability == Reduce maintenance cost
● Reduce onboarding time for new developer
● Reduce tech debt
● Reduce time to add or modify existing features
● Happy developer
Slide 10
Slide 10 text
No content
Slide 11
Slide 11 text
Principles
Slide 12
Slide 12 text
Code for Human
Slide 13
Slide 13 text
“Always code as if the person who ends up maintaining your code is a violent
psychopath who knows where you live.”
Slide 14
Slide 14 text
Follows Coding Standard
● PHP: PHP Standard Recommendation (PSR)
● Javascript: Airbnb coding standard
● Go: Effective Go
Slide 15
Slide 15 text
Code Review or Pair Programming
● Sharing context
● Finding insight and alternative solution
● Knowledge transfer
● Managing your ego
Slide 16
Slide 16 text
Be patient, writing good codes takes time
Slide 17
Slide 17 text
Technical Approach
Slide 18
Slide 18 text
Meaningful Names for Variables, Methods, Classes,
Arguments
● Should be sufficient enough to understand the purpose or context
● One should not have to read the whole code to figure out what a function does or what a class
represents or to understand why a variable exists
● No need comments
Slide 19
Slide 19 text
Bad Good
Slide 20
Slide 20 text
Avoid Magic Values
Bad Good
Slide 21
Slide 21 text
Even Better …
Slide 22
Slide 22 text
Other naming best practices
● Name functions as verbs. Ex: save, create, deductBalance
● Name classes as nouns. Ex: User, UserController
● Use pronounceable names. Ex: modificationTimestamp, isActive, createAndSave
Slide 23
Slide 23 text
Good Functions
● Should be small as possible
● Should do just one (or multiple by context) thing
● Should have fewer arguments
● No side effects
Slide 24
Slide 24 text
No content
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
Try to prevent nested condition
Bad Good
Slide 27
Slide 27 text
Do we need comments?
● No. Your code should be self explain
● Only put comment if necessary
○ Some trade off
○ Deprecation warning
○ What point or process needs to be aware
Slide 28
Slide 28 text
DRY - Don’t Repeat Yourself
“Every piece of knowledge must have a single, unambiguous, authoritative representation within a system”
● Actually duplication is fine*
● Extract part of code that can be reused to a class or function
Slide 29
Slide 29 text
KISS - Keep It Simple Stupid
● Code less
● Easy to understand, debug, and modify
● Complex code != smart
Slide 30
Slide 30 text
YAGNI - You Aren't Gonna Need It
● “Maybe we need use that in the future”
● Only code what you need to build
● Avoid adding unnecessary dependencies or complexity
● Leads to over engineering
Slide 31
Slide 31 text
Design Pattern & System Design
● Understanding design patterns can help us to make decision with our code
○ Creational pattern
○ Structural pattern
○ Behavioral pattern
● Understanding system design to prevent tech debt or over engineering
○ Monolith Design
○ Domain Driven Design
○ Microservices
○ Architectural Pattern
Slide 32
Slide 32 text
Dealing With Legacy Code
Slide 33
Slide 33 text
● Do not judge it
● Understand how it runs
● Understand the structure & pattern
● Understand the business context
● Raise your empathy
● Leave better than you found it
Slide 34
Slide 34 text
Do we need to refactor the bad codes?
It depends! What is your organization’s prioritization?
Slide 35
Slide 35 text
Working on new or modifying features
● Follow current structure with better approach
● Plan and communicate if you are proposing approach that might totally different with current
structure
● Add unit tests or automated tests if possible
● Do pair programming or code review
● Done is better than perfect
Slide 36
Slide 36 text
Clean Code is a Journey
● Remember, your first code must be awful. Keep practice
● Learn design patterns and system designs
● Get more insight, find mentor or developer fellows, contribute to open source