Clean code through understanding and communication

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

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