천천히 설계를 키워나가기
최근에 회사에서 새로운 프로젝트를 초기 단계 부터 구성하는 작업을 하고 있다.
주된 방침은 내적 퀄리티를 희생하지 않으면서도, 사용자에게 완결성있는 기능(가치)을 지속적으로 전달하는 것이다.
작업을 하면서, 무엇에 신경을 더 써야하고 무엇에 신경을 덜 써야하는지 매번 헷갈린다. 문제가 되는 것은 늘 특정한 구조에 집착해서 상황에 맞지 않는 설계를 만들어낸다는 것이다. 구조나 패턴은 그렇게 사용하면 편해지는 점이 있어서 하는 것인데, 처음 부터 지나치게 패턴을 의식하고 사용하려 한다.
범위를 줄이는 것과 요구사항을 단순화시키는 것의 차이도 경계해야 할 것 같다. 내적 퀄리티를 유지하기 위해서 가장 최소의 기능을 제공하도록 했으면, 그 기능에 대해서는 완결성을 유지해야 하는 것 같다.
예를 들어, 사용자가 사칙 연산 풀 수 있게 하는 대신에, 덧셈 문제만을 풀 수 있도록 요구 사항을 변경하는 경우에, 덧셈 문제를 정말 풀 수 있는지에 대해서는 단순화가 이루어지면 곤란하다. 덧셈문제를 푸는 동안에는 제대로 된 피드백을 받을 수 있어야 하고, 부적절한 상황이 발생하면 안된다.
회사에서 경험한 것을 글로 썼으면 좋겠다. 구조를 이상하게 잡았던 경험이나, 도메인 설계가 잘 안된 경험, 완결성있는 기능을 제공하기 위해 노력했던 경험들을 모두 남기면 좋겠다.
동작하는 골격
동작하는 골격이란 전 구간을 대상으로 자동 빌드, 배포, 테스트를 할 수 있는 실제 기능을 가장 얇게 구현한 조각을 말한다. 여기엔 첫 기능을 구현할 수 있을 정도의 자동화, 주요 컴포넌트, 통신 메커니즘이 포함될 것이다.
지금까지 되풀이 해서 배운 교훈이 하나 있다면 바로 배포 과정을 자동화하는 것만큼 프로세스를 이해하는 데 도움이 되는 것은 없다는 점이다.
프로그래머의 뇌
현재 6장 까지 읽었다. 책의 첫부분에서 코드를 읽는데 어려움을 느끼는 이유를 세가지 인지과정 모델로 나누어서 설명하고 있다. 각 인지과정마다 어려움의 원인이 다르기 때문에, 읽기 효율을 향상시키기 위해서는 서로 다른 방법으로 수련을 해야한다.
지금은 연습에 조금 더 힘을 쏟을 시기인 것 같다. 나에게 가장 유의미한 연습은 직접 코드를 프린트해서 읽고, 어떤 수단의 청킹이든 동원해서 모두 외운 후에 다시 재현해보는 것이다. 사실 타인의 코드를 읽는 일에 많이 서툴기 때문에, 꼭 필요한 연습이라고 생각한다.
읽은 후에는 anki 를 사용해서 새로 얻은 지식을 정리해보자.
