리팩토링을 내장할 수 있다면?
도메인 모델링 세미나 7
연재의 이름과는 어울리지 않는 듯도 하지만, 직업 일상에서 벌어지는 자극을 담아서 엮는 일은 가치가 있다고 판단하여 (독자들에게는 다소 비약일 수 있지만) 관련 글을 연재로 남긴다.
정돈을 택하느냐? 빨리 기능을 추가하느냐?
메일링 리스트로 Kent Beck의 글을 받아보는데 낮시간에는 잘 읽지 않는다. 낮시간의 나의 일과는 거리가 있는 내용이라 보통은 퇴근 후에 머리를 비우고 읽어야 공감을 할 수 있기 때문이다.
제목을 보자마자 나는 낮에 했던 대화들 때문에 상상을 해버렸다. 제목에서 내가 받은 인상을 검증할 목적으로 스크롤을 하며 내 인상을 지지하는 구절만 찾았다. 이런 행동도 '읽는다'는 말로 불러야 할지 모르겠다. 암튼 글의 내용은 아주 정교한 설명들이 이어졌고 내가 당장 찾는 것과는 거리가 있었다.
좋은 코드 = 수정하기 쉬운 코드
<아키텍처는 의사소통에 관한 문제라서?>편에서 예고한 바로 그 회의때 했던 이야기가 떠오른다.
다음 주에 어느 개발팀 자문을 하러 가는데 업무 분담 기준에 대한 논의를 할 예정이다. 그때 공감을 얻기 위해 이런 이야기를 해야 될 지도 모르겠다.
그 자리에서 나는 서로 무엇을 하고 있는지 한눈에 알아볼 수 있는 개발자용 칸반을 만들 것을 제안했다. 그리고 나서 서로 하는 일의 내용에 해당하는 코드를 모두 함께 보는 코드 리뷰를 일상화 시켜야 한다고 주장했다. 그러한 근거라고 화이트보드에 내가 쓴 문장이 아래 한 줄이다.
좋은 코드 = 수정하기 쉬운 코드
그리고, 팀으로 공감을 이뤄야 하는데, 그러려면 서로가 작성한 코드에 대해 충분한 대화를 나눠야 한다고 주장했다. 그 대화는 구두로만 이뤄지는 것이 아니라 일상이 되려면 코드 저장소(github 이나 gitlab)의 기록으로 벌어져야 한다. 그런 대화들이 충분히 나눠지면 우리는 수정하기 쉬운 코드에 대한 공감을 만들어낼 수 있다.
이런 여파로 Kent Beck의 제목을 보자마자 이건 햄릿식의 절체절명의 선택이 되는게 아니라 굉장히 작은 단위의 일상의 고민으로 만들 수 있어야 한다는 가정을 하게 된 것이다.
아키텍처이면서 문화냐일까?
이는 또한 <아주 이상적인 아키텍처>편을 쓰면서 포착한 아키텍처에 대한 이상향을 다시 떠오르게 했다. 그러한 아키텍처가 살아있으려면 코드로 구현되어야 하고 동시에 코드를 수정하는 개발자들이 인식하는 개념이 되어야 한다. 그래서 코드 수정하는 가운데 계속해서 반영되어야 하는데... 그런 양상은 결국 일종의 조직 문화 혹은 개발 문화라 불릴 수 있다.
지난 도메인 모델링 세미나 연재
5. 아주 이상적인 아키텍처
