오늘 TIL 3줄 요약

- When you are write code, you should consider ETC and DRY, orthogonality

- There are no final decisions. you should prepare about reversibility

- The only way to determine the timetable for a project is by gaining experience on that same project

TIL (Today I Learned) 날짜

- 2022.03.21

오늘 읽은 범위

- 2.A Pragmatic Approach

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

Topic 8 The Essence of Good Design

- ETC:Easier to Change

- You may need to spend a week or so deliberately asking yourself “did the thing I just did make the overall system easier or harder to change?”

Topic 9 DRY The Evils of Duplication

- Programmers are constantly in maintenance mode.maintenance is not a discrete activity, but a routine part of the entire development process.

- Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

- DRY is about the duplication of knowledge, of intent. It’s about expressing the same thing in two different places, possibly in two totally different ways.

- not All Code Duplication IS Knowledge Duplication

- What you’re trying to do is foster an environment where it’s easier to find and reuse existing stuff than to write it yourself.

Topic 10 Orthogonality

- Once you have your components mapped out, ask yourself: If I dramatically change the requirements behind a particular function, how many modules are affected?In an orthogonal system, the answer should be "one."

- Don't rely on the properties of things you can't control.

Topic 11 Reversibility

- The mistake lies in assuming that any decision is cast in stone—and in not preparing for the contingencies that might arise.

- there are no final decisions. you also need to think about maintaining flexibility in the areas of architecture, deployment, and vendor integration.

- Forgo Following Fads

Topic 12 Tracer Bullets

- Prototyping generates disposable code. Tracer code is lean but complete, and forms part of the skeleton of the final system.

Topic 13 Prototypes and Post-it Notes

- But if you find yourself in an environment where you cannot give up the details, then you need to ask yourself if you are really building a prototype at all. Perhaps a tracer bullet style of development would be more appropriate in this case

- Before you embark on any code-based prototyping, make sure that everyone understands that you are writing disposable code.

Topic 14 Domain Languages

Topic 15 Estimating

- The first part of any estimation exercise is building an understanding of what’s being asked.

- choose the units of your answer to reflect the accuracy you intend to convey.

- Build a Model of the System -> Break the Model into Components -> Give Each Parameter a Value -> Calculate the Answers

- We find that often the only way to determine the timetable for a project is by gaining experience on that same project.

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

- When I was writing a code, I wanted to write a duplicate code for easier to Change , but I wondered if it would violate the DRY. After reading the part Not All Code Replication IS Knowledge Replication, now I know that DRY was not limited to code

- I didn't understand the difference between 'Tracer Bullet' and 'Prototype', I search for Internet and understood it. Prototype focuses on only one function (UI, SQL query, etc.), Tracer Bullet focuses basic business logic (To create one ToDo). In addition, 'Tracer Bullets' seemed to be useful in agile development.

- https://stackoverflow.com/questions/4047335/tracer-bullets-vs-prototypes

- When my boss asked me about Estimating long-term task, it was difficult to answer because there were many inaccurate parameters. Now I got a hint about how to answer after reading Topic 15 Estimating.