Introduction

Tidy First?
구름 COMMIT : 더 나은 코드를 위한 켄트백 Tidy First?

Tidy First?

서론

대부분의 소프트웨어 설계자는 설계 자체가 시간을 초월해서 이뤄지는 것처럼 행동하지만 실제로는 시간에 따라 변화하게 된다. 설계와 관련된 조언은 많지만 실제 사례에서 모순만 드러나는 경우가 많다. 책에서는 설계를 구성할 수 있는 환경 만드는 일에 집중한다. 그래서 환경을 만드는 경험에 기반한 소프트웨어 설계의 중요성을 강조한다.

개발 이론은 독자의 난이도를 고려해 시간 변수를 무시한 체 설명하기 때문에 실무에 적용하려면 이론과 현실 사이의 괴리감을 직접 경험해볼 필요가 있다. 해봤어?, 백문이불여일타 라고 물어보는 이유는 괴리감을 줄여 이상에 가까운 환경을 만드는게 목적이다. 책 이름이 깔끔함이 먼저다(Tidy First)인 이유는 실천 가능한 코드 정리에서 시작해 모순을 제거하며 이론에 가까운 환경을 만들 수 있도록 도와주기 위함이라 생각한다.

책을 읽으면 시스템 동작 변경과 시스템 구조 변경의 근본적인 차이점을 알 수 있다고 한다. 두 개에 차이는 사소하지 않다는 의미다. 주말동안 코드 정리 파트만 읽고 와닿거나 알게된 내용을 추렸다.

PART1 : 코드 정리

CHAPTER 10 : 명시적인 매개변수

처음에는 컬렉션을 넘겨 일부만 사용하거나 제거하는 상황을 의미하는가 했는데 DTO를 사용해 사용하는 매개변수를 모호하게 만드는 상황을 겨냥하는 말일 수 있겠다는 생각도 들었다. 결국 결합도를 줄이려면 모호하지 않은 변수는 받지 않아야 한다. 명확한 매개변수로 사전 조건을 만들어 견고한 코드를 지향할 수 있다.

CHAPTER 11 : 비슷한 코드끼리 & CHAPTER 12 : 도우미 추출 방법

긴 코드 라인을 가진 메서드가 있다면 비슷한 코드끼리 구분하기 위해서 개행(\n) 문자를 추가한다. 이 방식은 가장 간단하기 때문에 적극적으로 활용하길 추천한다. 복리처럼 뒤따르는 유연성을 모아 재설계할 수 있는 힘을 기를 수 있다. 책에서는 대표적으로 변수로 추출하거나 메서드로 추출하는 방법으로 응집도를 개선한다.

메서드로 추출하는 방법은 CHAPTER 12 : 도우미 추출 방법이라 해서 응집도 높은 요소 만들어 나가는 방법이다. 예로는 시간적 결합을 표현하기 위해서 사용하기도 한다.

필자는 보통 변수의 생명주기를 고려해 메서드를 추출하게 되는데, 비슷한 코드끼리 묶여있기 때문에 가능하다고 생각한다. 개행으로 그룹핑하는 건 간단하고 좋은 방법이다. 별개로 사용 목적으로 기준으로 도우미 추출하는 방식은 접근하기 어려웠다. 사용 목적에 따라 추출한다니 유틸 메서드를 만드는 느낌이라 조심스럽다.

CHAPTER 13 : 하나의 더미

필요한 만큼 하나의 더미처럼 느껴질 때까지 코드를 모은 후 정리한다. 코드를 만드는 데 가장 큰 비용은 읽고 이해하는 일이다. 코드를 모은 후 정리하게 되면 응집도를 높일 수 있는 길을 제시할 수 있다. 보통 다음 증상이 나타나면 고민해볼만 하다.

길고 반복되는 인자 목록
반복되는 코드, 반복되는 조건문
도우미에 대한 목적이 명확하지 않은 이름
공유되면서 변경에 노출된 데이터 구조

최근에 엑셀 파일 생성 로직을 일원화한 경험이 있다. 동일한 패턴을 모으고 동일하지 않은 패턴은 응집도에 따라 각자 관리하거나 메서드로 사용 할 수 있도록 정리하며 객체로 만들었다. 엑셀 파일이 생성될때마다 객체를 재사용하면서 코드 작성하는 일이 꽤나 간편해졌다.

CHAPTER 15 : 불필요한 주석 지우기

주석과 코드는 작성할 때와 나중에 볼 때 시간이 흐르고 나면 서로 맞지 않는 경우가 있다.

문서화로 고통받고 있다면 공감할 내용이다. 이전 이력이 남아 관리하기 어려워지는 순간이 있는데 과감하게 제거할 필요가 있다. 그래서 작업하기 전 문서와 작업 후 문서를 나눠 문서를 관리하고 작업하기 전 문서는 작업이 끝나면 한 곳에 모아 관리하고 있다.

PART2 : 관리

CHAPTER 18 : 코드 정리의 일괄 처리량

배포하기 전 코드를 일괄 정리한 양에 따라 복잡도가 올라간다. 일괄 정리한 코드 정리 작업이 많을 수록 통합 과정에서 지연 시간이 길어지고 충돌 가능성이 커진다. 또한 코드 정리 사이 상호작용이 있으면 병합 비용은 증가한다. 일괄 처리 규모를 축소해 검토 비용을 줄이고 지속적으로 통합하는게 비용을 줄일 수 있는 길이다.

일부 회사는 PR 양을 최소화하고 양이 크다면 사유를 써야 했다. 지금 든 생각은 일괄 처리로 인한 검토 비용을 경계 했다고 생각한다.

CHAPTER 19 : 리듬

구조 변경에 한 시간 이상 소요한다면 최소한의 구조 변경 시기를 놓친 것이다. 파레토 법칙에 따르면 변경 사항은 20% 범위 내에서만 발생한다. 그럼 변경한 내용들은 계속해서 수정된다. 그럼 변경 사항이 오래 남을 수 없게된다.

소프트웨어 설계는 길을 닦는 과정이며 변경한 내용은 누군가 지나가면서 없어질 가능성이 높으니 한 번의 구조 변경에 오랜 시간을 투자하지 말자. 동작 변경 사이마다 구조 변경을 진행하며 누군가가 쉽게 지나갈 수 있을만큼만 정리하자.

결론

모든 이야기가 단순한 만큼 가고자하는 길이 명확하다.

시간 변수는 괴리를 만든다.

개발하면서 프로젝트를 구상할 때 시간 변수를 제외하고 고민하는 건 위험한 일이었다. 당장 코딩 테스트만 해도 의사 코드만 작성하지 시간 변수에 변화를 고려하지 않는다. 업무에서 이론과 실무 사이 괴리로 당혹스러운 코드 수정이 많았는데, 책을 읽고 당혹스로운 원인을 명시할 수 있었다.

명시적이어야 한다.

이펙티브 테스트 책을 읽고 코드 흐름을 테스트로 제어할 수 있음을 확신할 수 있었다. 사전 사후 검사로 메서드 안에서 흐름을 제어하고 명세 테스트 구조 테스트를 이용해 작업 진행 중 테스트로 흐름을 제어할 수 있다.

책에서는 포켓몬 게임을 하듯이 진행해보는게 어떤지 물어보면서 굳이 멋진 단어로 하고자 하는 말을 치장할 필요가 없음을 느꼈다. 공감은 이해해서 시작한다. 나도 이런 멋진 책을 써보고 싶다.

구름 COMMIT : 더 나은 코드를 위한 켄트백 Tidy First?

서론

강연자는 개발 문화 차이가 있지만 코드 관리에는 근본적인 목표가 있음과 소프트웨어 설계는 지속성을 가짐을 강조했다.

본론

근본적인 목표

문화와 생명은 서로 공존하면서 진화하는 것처럼 협업 도구 진화와 업무 방식 변화에 따라 개발 문화 또한 성장했지만 우리가 추구하는건 유지 비용 감소를 위한 응집도 증가와 결합도 감소다.

코드 정리

동작 변경(리팩토링)으로도 쉽게 달성할 수 있지만 책은 코드 정리로 달성 할 수 있는 수단을 총 15가지 제시했다. 강연자는 15가지 수단을 (1) 컨텍스트가 명료하게, (2) 코드 줄이기, (3) 나누거나 아님 붙이거나로 간단하게 정리했다.

컨텍스트가 명료하게
코드 줄이기
나누거나 아님 붙이거나

코드 정리가 필요해보일 때 원인과 근거를 항상 붙여 부담되지 않을까 걱정됐는데, 단순히 세 문장으로 타협본다면 코드 리뷰 시작이 얼마나 편할까?

관리

관리는 결국 시간이라는 변수로 결정된다. 투자할 시간이 많아지면 퀄리티가 높아지고 적다면 퀄리티가 떨어지기 마련이다. 그렇다고 투자가 많을 수록 높은 퀄리티를 유지할 수 있을까? 그렇지 않다. 투자했던 코드가 사라질 수도 있기 때문이다. 소프트웨어 설계는 시간에 따라 변화하기 때문에 점진적으로 접근할수록 유리하다. 즉, 소프트웨어 설계는 길을 닦는 일이며 쓰임새를 지켜보며 지속해야 하는 일이다.

이론

설계는 결국 현재 소프트웨어가 하는 일과 미래에 새로운 일을 시킬 수 있는 가능성을 의미한다. 동작은 현재의 가치를 높이는 일이고 설계는 미래의 가치를 높이는 일이다. 어디에 가치를 둘지는 현재 놓인 상황에 따라 변화한다.

생존 부등식은 가치(value) > 가격(price) > 비용(cost) 순으로 가치를 나열한다. 그럼 코드도 유사하게 다음과 같이 정렬할 수 있다.

코드의 가치 > 고객 만족도 > 비용(시간)

결국 우리가 가진 상품(코드) 가치가 가장 중요하고 상품 가치로 인해 가격(고객 만족도)이 결정된다. 그렇다고 상품 가치를 높일 때 비용을 간과해서는 안된다. 생산라인에서 가장 안좋은 상황은 악성 재고가 남는 상황인데 사용하지 않는 코드가 남는다면 동일할테다.

결론

강연에서 책이 이야기하고 싶은건 세상을 바꾸고 싶다면 이불부터 정리하라는 윌리엄 맥레이븐의 명언이 머릿속에 남았다. 큰 변화는 사소한 변화에서부터 시작하며 언제나 자기 자신이 시작점이다는 것을 어필하고 싶어보였다.

사실 소프트웨어 설계는 프랙탈이므로 설계는 크게도 작게도 할 수 있지만 설계는 변화에 순응하는 방향으로 적용하는게 좋다. 변화에 순응하기 위해서 가장 중요한건 loosely coupled다.

개인적인 생각은 결국 인지할 수 있는 행동이어야 파악이 가능한데, 적절한 패턴이 있으면 서로 이해하기 쉬워보인다. 결국 설계는 패턴의 모음이며 보편적인 방식으로 이해도를 높일 수 있지 않을까 생각한다.