DAY 4

🔖 오늘 읽은 범위 : cp2. Toolkits and Libraries ~ Prototypes and Post-it Notes

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

</aside>

• When you bring in a toolkit (or even a library from other members of your team), ask yourself whether it imposes changes on your code that shouldn’t be there.
• If an object persistence scheme is transparent, then it’s orthogonal. If it requires you to create or access objects in a special way, then it’s not. Keeping such details isolated from your code has the added benefit of making it easier to change vendors in the future.
• Keep your code decoupled. Write shy code—modules that don’t reveal anything unnecessary to other modules and that don’t rely on other modules’ implementations.
• Avoid global data. Every time your code references global data, it ties itself into the other components that share that data.
• The Singleton pattern in Design Patterns is a way of ensuring that there is only one instance of an object of a particular class. Be careful with singletons— they can also lead to unnecessary linkage.
• Avoid similar functions. Duplicate ode is a symptom of structural problems. Have a look at the Strategy pattern in Design Patterns for a better implementation.
• Building unit tests is itself an interesting test of orthogonality.
• Bug fixing is also a good time to assess the orthogonality of the system as a whole. Do you change just one module, or are the changes scattered throughout the entire system? When you make a change, does it fix everything, or do other problems mysteriously arise?
• There are no final decisions Instead of carving decisions in stone, think of them more as being written in the sand at the beach. A big wave can come along and wipe them out at any time.
• Tracer code is not disposable: you write it for keeps. It contains all the error checking, structuring, documentation, and self-checking that any piece of production cod has. It simply is not fully functional.
• Tracer development is consistent with the idea that a project is never finished: there will always be changes required and functions to add. It is an incremental approach.
• Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system. Think of prototyping as the reconnaissance and intelligence gathering that takes place before a single tracer bullet is fired.
• Prototype to learn Prototyping is a learning experience. Its value lies not in the code produced, but in the lessons learned.

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

</aside>

I thought tracer code is basically prototyping until I read the next paragraph 😂