$30 off During Our Annual Pro Sale. View Details »

Clean Code Principle for Software Engineer

Clean Code Principle for Software Engineer

Clean Code Principle for Software Engineer

Didik Tri Susanto

October 27, 2022
Tweet

More Decks by Didik Tri Susanto

Other Decks in Programming

Transcript

  1. Clean Code Principle for
    Software Engineer
    Didik Tri Susanto, 26 Oct 2022

    View Slide

  2. Contents
    ● Why Clean Code?
    ● Benefit & Goal
    ● Principle
    ● Approach
    ● Dealing with Legacy Code

    View Slide

  3. Why Clean Code

    View Slide

  4. Good Code VS Bad Code

    View Slide

  5. View Slide

  6. What is Clean Code
    “Clean code always looks like it was written by someone who cares”
    ~ Michael Feathers

    View Slide

  7. Not only working software, but also
    well-crafted software
    Manifesto of Software Craftmanship

    View Slide

  8. Benefit & Goals

    View Slide

  9. ● Increase Maintainability == Reduce maintenance cost
    ● Reduce onboarding time for new developer
    ● Reduce tech debt
    ● Reduce time to add or modify existing features
    ● Happy developer

    View Slide

  10. View Slide

  11. Principles

    View Slide

  12. Code for Human

    View Slide

  13. “Always code as if the person who ends up maintaining your code is a violent
    psychopath who knows where you live.”

    View Slide

  14. Follows Coding Standard
    ● PHP: PHP Standard Recommendation (PSR)
    ● Javascript: Airbnb coding standard
    ● Go: Effective Go

    View Slide

  15. Code Review or Pair Programming
    ● Sharing context
    ● Finding insight and alternative solution
    ● Knowledge transfer
    ● Managing your ego

    View Slide

  16. Be patient, writing good codes takes time

    View Slide

  17. Technical Approach

    View Slide

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

    View Slide

  19. Bad Good

    View Slide

  20. Avoid Magic Values
    Bad Good

    View Slide

  21. Even Better …

    View Slide

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

    View Slide

  23. Good Functions
    ● Should be small as possible
    ● Should do just one (or multiple by context) thing
    ● Should have fewer arguments
    ● No side effects

    View Slide

  24. View Slide

  25. View Slide

  26. Try to prevent nested condition
    Bad Good

    View Slide

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

    View Slide

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

    View Slide

  29. KISS - Keep It Simple Stupid
    ● Code less
    ● Easy to understand, debug, and modify
    ● Complex code != smart

    View Slide

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

    View Slide

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

    View Slide

  32. Dealing With Legacy Code

    View Slide

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

    View Slide

  34. Do we need to refactor the bad codes?
    It depends! What is your organization’s prioritization?

    View Slide

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

    View Slide

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

    View Slide

  37. QnA

    View Slide