DAY 3

🔖 오늘 읽은 범위 : cp2 A Pragmatic Approach ~ Design

<aside> 😃 책에서 기억하고 싶은 내용을 써보세요.

</aside>

• Our understanding changes day by day. New requirements arrive as we’re designing or coding. Perhaps the environment changes. Whatever the reason, maintenance is not a discrete activity, but a routine part of the entire development process.
• DRY - Don’t Repeat Yourself Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
• bad code requires lots of comments. The comments will inevitably become out of date, and untrustworthy comments are worse than no comments at all.
• Orthogonality: In computing, the term has come to signify a kind of independence or decoupling. Two or more things are orthogonal if changes in one do not affect any of the others. In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface.
• Eliminate effects between unrelated things. We want to design components that are self-contained: independent, and with a single, well-defined purpose.

<aside> 🤔 오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

</aside>

<aside> 🔎 궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

</aside>

• “Normalize it according to the underlying business model...Whatever the eventual solution, avoid this kind of unnormalized data” ➡️ what does “to normalize data” mean?

<aside> 💡 소감 3줄 요약

</aside>

• I got a habit of focusing on writing code that don’t need comments after reading Clean Code. Glad to see the same advice in this book.
• Orthogonality part was interesting. Even if I create functional components, they are often not completely independent in React world. Props might change, state might not be available anymore, etc. However this is what we’re trying to achieve in the pattern library we’re building at the moment.
• You gain productivity, reduce risks, if you have orthogonality in your project.