📍느낀점
1장에서 실용주의 프로그래머가 되기 위한 기본 마음가짐을 익히고 이제 부터는 접근법에 대해 알아본다. 클린 코드, 클린 아키텍처, 실용주의 프로그래머가 말한다. 중복을 피하라
이번장에서는 실용주의 프로그래머가 될 수 있는 다양한 방법을 배웠다.
[2장. 실용주의 접근법] 을 읽고
✅ 기억해야할 문장
Topic 8 좋은 설계의 핵심
✏️ 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.
✏️ 어떤 게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 것이다. 이 말을 코드에 적용해 보면, 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰져야 한다. 그래서 우리는 ETC 원칙을 따른다. 바꾸기 더 쉽게 Easier to Change.ETC. 이게 전부다.
✏️ 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다.
좋은 설계의 핵심은 얼마나 쉽게 바꿀수 있느냐에 있다. 언제나 의식적으로 코드를 작성하고 나서 방금 추가한 내용이 전체 시스템을 바꾸기 어렵게 만들지 않았는지 항상 체크해야 한다. 시스템에 어떤 영향을 가할지 판단하기 어렵다면 작성하는 코드가 바꾸기 쉽게 만들어야 한다. 그래야 나중에 바꿔야 할 경우 지금 작성한 코드가 다음에 작성한 코드의 앞길을 가로막지는 않을테니까. 또한 이 코드가 시스템에 어떤 영향을 가할지 판단할 수 있는 직관도 키워야 한다.
Topic 9 DRY:중복의 해악
✏️ 사람들은 대부분 유지 보수란 버그를 고치고 기능을 개선하는 것을 의미하기 때문에, 애플리케이션이 출시되었을 때 비로서 유지 보수가 시작된다고 믿는다. 우리는 이들이 틀렸다고 생각한다. 프로그래머는 늘 유지 보수 모드에 있다. 유지 보수는 별개의 활동이 아니며 전체 개발 과정의 일상적인 부분이다.
✏️ 소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가 DRY라 부르는 원칙을 따르는 것이다. DRY원칙은 다음과 같다. 모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다. (Don't Repeat Yourself) 우리는 DRY가 '실용주의 프로그래머'의 도구 상자에서 가장 중요한 도구 중 하나라고 생각한다.
코드를 작성하다보면 중복은 언제나 마주하는 문제다. 코드가 길어질 수록 중복을 체크하지 못하고 넘어가는 경우도 있고 유지 보수를 위해서 소스를 수정하다가 중복을 만들기도 한다. 어떤 책을 읽더라도 언제나 강조하는 것은 중복은 없어야 한다는 것이다. 중복을 제거하다보면 중복에도 여러 유형이 있다는 것을 알게 된다. 막연하게 중복을 제거하다보면 우연적으로 발생한 필연적인 중복까지도 제거하려한다. 따라서 제거해야하는 중복인지 우연으로 발생한 중복인지를 구분할 수 있는 능력을 키워야 하고, 제거해야하는 중복에서도 어떤 유형의 중복인지를 파악한다음 최선의 방법으로 중복을 제거할 수 있어야 한다.
Topic 10 직교성
✏️ 직교성(orthogonality)은 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는데 있어 매우 중요한 개념이다. 직교성의 원칙을 적용하는 방법을 직접 배우면 여러분이 만드는 시스템의 품질을 즉각 개선할 수 있을 것이다.
✏️ 컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기(decoupling)를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. 잘 설계된 시스템에서는 데이터베이스 코드가 사용자 인터페이스와 서로 직교할 것이다.
새로운 기능을 추가하거나 기존의 기능을 변경하다보면 나도 모르게 버그가 발생하는 경우가 많이 일어난다. 수정한 코드가 자연스럽게 연결되어 있는 기존의 코드에 영향을 가하면서 오류가 발생한다. 이럴 경우 수정한 코드에 영향을 받는 기존의 코드들을 모두 훑어봐야 하며 영향을 받지 않도록 또는 오류가 발생하지 않도록 모두 수정해야 한다. 명백한 설계 오류이며 개선해야할 문제다. 직교성을 고려하지 않고 프로그램을 만들어 왔기 때문에 작은 수정사항이 생기더라도 테스트를 하는 것이 두려웠다. 컴포넌트간의 연결 때문에 전체 테스트를 진행해야 했고, 시간도 많이 소요되었으며 오류는 필수적으로 발생했고 그 오류를 처리하는 시간 또한 필수적으로 발생했다.
✏️ DRY 원칙은 시스템 내부의 중복을 최소화하고, 직교성은 시스템 컴포넌트 간의 상호 의존도를 줄인다. 당연한 말이겠지만 DRY 원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것이다. 디버깅, 테스트, 유지 보수 또한 쉬워질 것이다.
Topic 11 가역성
가역성(可逆性 / reversibility)은 반응 시 초기 상황으로 되돌아올 수 있는지의 여부를 일컫는 말이다. 가능하면 가역, 불가능한 것을 비가역이라고 한다. [나무위키]
✏️ 영원한 것은 없다. 여러분이 어떤 사실을 굳게 믿고 그 사실에 전적으로 의존하고 있다 하더라도 그 사실 역시 언젠가는 변할 것이 뻔하다.
✏️ 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지 못하기 때문이다.
✏️ 결정이 바뀌지 않을 것이라 가정하고서 발생할지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.
✏️ 누구도 어떤 미래가 펼쳐질지 알 수 없으며, 우리 분야는 특히 더 그렇다.
간단한 프로젝트라도 프로젝트 초기에 결정된 사항들이 쉽게 변경되는 것을 본적이 있다. OS가 바뀐적도 있었고, 툴이 바뀐적도 있었다. 언제든지 요구사항은 변경될 수 있다. 나의 의지와는 관계없이. 따라서 유연한 소프트웨어를 개발할 수 있어야 한다. 쉽게 변하는 요구사항에 쉽게 반응할 수 있는 소프트웨어가 필요하다.
Topic 12 예광탄
✏️ 실용적인 관점에서 봐도 예광탄은 상대적으로 비용이 적게 드는 방법이다.
✏️ 예광탄 코드는 한 번 쓰고 버리려고 만드는 것이 아니다. 앞으로도 계속 사용할 코드다. 예광탄 코드도 다른 제품 코드와 마찬가지로 오류 검사, 올바른 구조, 문서화, 자체 검사를 갖추어야 한다.
✏️ 예광탄은 지금 맞히고 있는 것이 무엇인지 보여준다. 그러나 그것이 꼭 목표물이라는 보장은 없다. 그럴 경우 목표물에 맞을 때까지 조준을 옮겨야 한다. 이것이 핵심이다.
✏️ 프로토타입은 나중에 버리는 코드를 만든다. 예광탄 코드는 기능은 별로 없지만 완결된 코드이며, 최종 시스템 골격 중 일부가 된다. 프로토타입은 예광탄을 발사하기 전에 먼저 수행하는 정찰이나 정보 수집과 같은 것이다.
코드를 작성할 때 무작정 코드부터 작성하면 좋은 결과물을 얻기 힘들다. 그렇지만 완벽에 대한 욕심 때문에 상세한 계획과 준비기간을 갖는다고 해도 움직이는 요구사항을 맞추는 것 또한 불가능하다. 코드부터 무작정 작성하자는 말이 아니다. 때로는 예광탄을 사용해서 목표물에 근접하는지 확인하는 작업이 필요하다. 예광탄을 사용하면서 보이지 않는 곳에서 범위를 좁혀 나간다. 어느정도 목표물에 근접하다면 이제는 실탄을 발사하면 된다. 보이지 않는 곳에서 맞추기를 기대하기 보다 예광탄 사용하자.
Topic 13 프로토타입과 포스트잇
✏️ 프로토타입은 제한된 몇 가지 질문에 답하기 위한 것이므로 실제 제품보다 훨씬 적은 비용으로 빠르게 개발할 수 있다.
✏️ 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프로토타입을 만들고 있는게 맞는지 자문해 보라. 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다.
✏️ 프로토타이핑으로 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다.
✏️ 프로토타이핑은 학습 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는것이 아니라 이를 통해 배우는 교훈에 있다.
예광탄과 프로토타입을 읽고 프로토타입보다 예광탄을 사용하는 것이 무조건 더 이점이 아닌가 생각을 했다. 하지만 프로토타입과 예광탄의 장단점은 분명하게 차이가 나며, 세부 사항에 얽매이지 않고 빠르게 피드백을 얻을 수 있다는 점에서 프로토타입은 사용할만한 가치가 있다고 생각한다. 프로토타이핑은 예광탄처럼 지속해서 사용할 수 있는 프레임워크를 만드는데 초점을 두는 것이아니라 학습을 통해 경험을 쌓는것에 초점을 둔다.
Topic 14 도메인 언어
무슨 말인지 하나도 이해를 못했다... 좀 더 알아보고 다시 정리할 예정
Topic 15 추정
✏️ 추정하는 법을 배우고 추정 능력을 개발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘하게 될 수 있을 것이다.
✏️ 누군가 추정치를 물었을 때 스스로 물어보아야 할 첫 번째 질문은 여러분의 답변이 사용될 상황이 무엇인지다. 질문자가 매우 높은 정확도의 답을 요구하는가, 아니면 단순히 큰 그림만을 요구하는가?
✏️ 모든 추정치는 문제의 모델에 기반한다. 그런데 모델을 작성하는 기술에 대해 깊이 파고들기 전에 항상 좋은 답을 알려주는 기본적인 추정의 비법을 하나 밝히겠다. 이미 그 일을 해본 사람에게 물어보라.
✏️ 가끔은 프로젝트의 일정을 정할 수 있는 방법이 해당 프로젝트를 경험해 보는 것뿐일 때가 있다.
✏️ 경영진은 보통 프로젝트가 시작되기도 전에 하나의 정확한 숫자를 원하기 때문이다.
✏️ 누군가 추정해 달라고 말하면 뭐라고 대답해야 할까?"나중에 연락드릴게요."라 말해야 한다.
가끔식 뜬금없이 다른 누군가가 추정을 요구할 때가 있다. 지금 하고있는 프로젝트가 얼마정도 걸릴지, 어떤 기능을 추가하고 싶은데 그 기능을 추가할 경우 일정이 얼마나 딜레이 되는지 등 그 자리에서 쉽게 대답할 수 없는 추정을 요구한다. 그때마다 항상 그 자리에서 계산을 해보려 노력했고 즉흥적인 대답을 했다. 다행히도 추정치에 맞는 기간을 얻을 수는 있었지만 아닌적도 있었다. 때문에 항상 조급한 마음을 갖고 일할 수 밖에 없었다. 그 자리에서 답하기보다 매우 정확한 모델은 아니여도 여러 추정기법을 사용해서 더 나은 답을 할 수 있어야 한다.
