- 2022. 05. 15 (일)
- 2장. 실용주의 접근법
요약
-
요구사항이 바뀌더라도 쉽게 대응할 수 있는 시스템을 만들어야 한다.
-
그러기 위해서 반복을 만들지 말고, 직교하는 시스템을 만들어라.
-
처음 시도해 보거나 위험이 예상되는 것은 프로토타입을 만들어서 실험해 볼 수 있다. 단, 프로토타입은 실험 후에는 버리는 코드여야 한다.
-
아예 백지에서 시작하는 프로젝트이거나, 실험에 사용된 코드가 나중에도 사용될 것 같다면 예광탄 스타일로 설계하는 것이 좋다. 예광탄 스타일은 프로젝트 골격과 간단한 알고리즘, UI만을 구성한 다음 여기에 살을 붙여 가는 방식이다.
DRY - 반복하지 마라 (Don’t Repeat Yourself) (p66)
나쁜 코드야말로 많은 주석을 필요로 한다. DRY 원칙은 낮은 차원의 지식은 그것이 속하는 코드에 놔두고, 주석은 다른 높은 차원의 설명을 위해 아껴두라고 말한다. 그러지 않으면 지식을 중복하게 되며, 변경할 때마다 매번 코드와 주석 모두를 바꾸어야 한다. p68
=> 정말 공감하는 말 !! 진짜로 잘 짠 코드는 주석이 없이도 어떻게 동작하는지 이해할 수 있는 코드라고 생각한다. 그러려면 로직을 적절하게 분리해서 그 로직을 아우르는 함수 이름으로 묶어내야 한다. 함수 이름만 잘 정해도 코드를 이해하는 것이 훨씬 수월해진다.
참을성 없는 중복은 발견하기도 쉽고 다루기도 쉬운 형태지만, 나중의 고통을 피하기 위해서는 훈련이 필요하고, 미연에 시간을 투자할 의지가 있어야 한다. p73
하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. p76 직교적인 시스템을 작성하면 두 가지의 큰 장점이 있다. 생산성 향상과 리스크 감소. p78
결정이 돌에 새겨지는 것이라 가정하고, 발생할지도 모를 우연한 사건들에 대해 준비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 해변가의 모래 위에 쓰인 글씨라 생각해 보자. 언제든지 큰 파도가 글씨를 지워버릴 수 있다. p92
요구사항을 메타데이터에 넣고, 필요한 수행문을 코드에 넣을 때 애스팩트나 펄 등을 이용하여 매커니즘을 자동화시켜라. 그리고 어떤 메커니즘을 이용하든 이를 되돌릴 수 있도록 하라. 무언가 자동으로 추가할 수 있다면, 역시 자동으로 빼낼 수도 있다. p93~94
아무것도 쓰여 있지 않은 백지가 가장 채우기 힘든 종이다. 일단 애플리케이션의 모든 요소 간 상호작용을 만들고 코드로 구체화까지 해 놓은 후라면, 여러분의 팀은 더 이상 무에서부터 많은 것을 만들어 낼 필요가 없어진다. p99
=> 예광탄을 사용하는 것은 아키텍처적 골격을 제공하고, 그 요소들이 실제로 상호작용하는 것을 보여주는 용도이다. 이 코드는 버려지지 않으며, 살을 붙여 가며 실제 애플리케이션을 만드는 데 사용할 수 있다. 예광탄 코드를 만들기 위해서는 애플리케이션의 골격에 단순한 로직과 UI만 채워 넣으면 된다. 이는 최종 시스템의 골격을 구성하게 된다.
프로토타입을 통해 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다. 또한 이전에 해본 적이 없는 것, 최종 시스템에 매우 중요한 것 등이 프로토타입의 대상이 된다. 증명되지 않았거나, 실험적이거나, 의심이 가는 것, 심적으로 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다. p105
