Clean code through understanding and communication

Clean code through understanding and communication

Luke Carwardine
LINE App Dev Team7 Software Engineer
https://linedevday.linecorp.com/jp/2019/sessions/S2-17

Be4518b119b8eb017625e0ead20f8fe7?s=128

LINE DevDay 2019

November 21, 2019
Tweet

Transcript

  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