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

Clean code through understanding and communication

Clean code through understanding and communication

Luke Carwardine
LINE App Dev Team7 Software Engineer

LINE DevDay 2019

November 21, 2019

More Decks by LINE DevDay 2019

Other Decks in Technology


  1. 2019 DevDay Clean Code Through Understanding and Communication > Luke

    Carwardine > LINE App Dev Team7 Software Engineer
  2. Introduction > Messy code can be a symptom of poor

    business design or requirements > Clean code is often thought of as coding principles and patterns
  3. Introduction > Poor design and requirements can come about through

    misunderstanding: > of the problem > how the problem should be solved > through the language
  4. Example > Why would a sofa be a car? >

    What were the requirements? > What was the problem that was being solved?
  5. "It's What the Business Wanted" > Business direction may have

    dramatically changed > Developer must help guide design and requirements > "The business" doesn't understand the code base
  6. Understanding the Issues > Don't assume the given proposal/design/requirement/ solution

    is correct > What is the original problem?
  7. Addressing the Issues Roles and Responsibilities > Make sure stakeholders

    know who is responsible for what > Introduce all stakeholders into the process as early as possible
  8. Addressing the Issues Roles and Responsibilities > If no one

    wants to take responsibility, take control (and inform others) > Raise issues early to avoid fixed business plans
  9. Scenario 1 Odd Business Requirements > The business has made

    decisions that are fixed and cannot be changed > Lack of stakeholder input > Lack of people wanting to take responsibility > Code base does not reflect new direction of the business
  10. Scenario 1 Odd Business Requirements > Requirement > Sales system

    must support sales of both sofas and cars > Problem with current solution > While Sofas and cars have similar properties, a car isn't a logical extension of a sofa. > Scenario > The business has decided to sell cars in addition to sofas as they share similar characteristics (number of seats and color)
  11. Scenario 1 > Future items can have different properties >

    Adjusted requirement > Sales system must support sales of new types of items Improved Solution
  12. Addressing the Issues Discussion > Take language differences into consideration

    > Keep communication channels open
  13. Addressing the Issues Discussion > Ask "obvious" questions to ensure

    everyone is on the same page > Ask questions early > If you don't understand, make sure to ask!
  14. Scenario 2 Lost in Translation > Language used in requirements/business

    does not match language used in code base > This can be both > natural language translations (e.g. Japanese ⬄ English) > business language that is non-obvious (i.e. jargon)
  15. Scenario 2 Lost in Translation > Requirement > Must add

    if sofa "is a car" > Problem with current solution > Language in code base does not match natural/business language > Scenario > Wheels are being added to sofas. Object + wheels = car in "fictional language".
  16. Scenario 2 > Language in code now reflects natural language

    > Adjusted requirement > Must add if sofa "has wheels" Improved Solution (Translation)
  17. Scenario 2 > Business language is now explained to those

    unfamiliar with the jargon > Adjusted requirement > Must add if sofa "has wheels (i.e. is a car)" Improved Solution (Business)
  18. Addressing the Issues Viewpoints > Differing solutions to a problem

    > Different understanding of how outcomes are obtained
  19. Addressing the Issues Viewpoints > Is a key factor missing?

    > Misunderstanding the problem > Unknown requirements > Translation issues > Before coding - Think > “Does the requirement/solution make sense?"
  20. Scenario 3 Differing Viewpoints > Requirement > Must add if

    sofa "is a car”. > Cars can be moved. > Problem with current solution > Requirement doesn't make sense. > Confirm actual requirement with person making them! > Scenario > Sofa location must be updated when moved. Person making requirements considers movable objects to be cars.
  21. Scenario 3 > Adjusted requirement > Sofas must be movable

    Improved Solution
  22. Addressing the Issues Push Back > Be polite > Don't

    be afraid to push back if something doesn't seem right
  23. Addressing the Issues Push Back > Suggest alternatives > Explain

    the problem clearly
  24. Thank You