2019 DevDay Clean Code Through Understanding and Communication > Luke Carwardine > LINE App Dev Team7 Software Engineer

Introduction > Messy code can be a symptom of poor business design or requirements > Clean code is often thought of as coding principles and patterns

Introduction > Poor design and requirements can come about through misunderstanding: > of the problem > how the problem should be solved > through the language

Example > Why would a sofa be a car? > What were the requirements? > What was the problem that was being solved?

"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

Understanding the Issues > Don't assume the given proposal/design/requirement/ solution is correct > What is the original problem?

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

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

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

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)

Scenario 1 > Future items can have different properties > Adjusted requirement > Sales system must support sales of new types of items Improved Solution

Addressing the Issues Discussion > Take language differences into consideration > Keep communication channels open

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!

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)

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

Scenario 2 > Language in code now reflects natural language > Adjusted requirement > Must add if sofa "has wheels" Improved Solution (Translation)

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)

Addressing the Issues Viewpoints > Differing solutions to a problem > Different understanding of how outcomes are obtained

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?"

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.

Scenario 3 > Adjusted requirement > Sofas must be movable Improved Solution

Addressing the Issues Push Back > Be polite > Don't be afraid to push back if something doesn't seem right

Addressing the Issues Push Back > Suggest alternatives > Explain the problem clearly

Thank You