들어가기 전,
학부시절에 코드만 돌아가면 ㅇㅋ? 라는 생각을 주로 했다면 이제는 바뀔 때가 되었다고 생각한다. 왜냐하면 개발자로 살아간다면 코드는 계속 만들게 될텐데 계속 규모가 커지는 코드만 작성할 수는 없기 때문이다.
점진적인 개선이 왜 필요할까?
처음부터 우아한 코드를 한번에 만들어 낼 수 없다. 책에서는 프로그래밍은 과학보다 공예에 가깝다고 한다. 깨끗한 코드를 작성하려면 지저분한 코드를 작성한 뒤에 정리해야 한다는 것이다.
하지만, 쉽게 따르기엔 너무 어렵다. 무조건 돌아가는 프로그램을 목표로한 초기 개발자(나)는 프로그램이 '돌아가면' 다음 업무로 넘어간다. 하지만 이는 곧 자살행위와 같다.
Prototype으로 작성한 프로그램이 어느정도 인정받았다고 하자. 그러면 지금의 상태를 기반으로 발전하게 된다. 코드는 그대로 남은 채 점점 규모가 커지게 되고 나중에는 알아보기 힘들게 된다.
그렇기 때문에 정리가 필요하고 점진적인 개선을 통해 누구나 프로그래밍을 쉽게 할 수 있도록 만들어야 한다.
프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위이다. 어떤 프로그램은 그저 그런 '개선' 에서 결코 회복하지 못한다. '개선' 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.
그래서 나도 TDD를 배우면서 많이 좋아진 것 같다.
TDD는 어느 때라도 시스템이 돌아가야 되는 원칙을 가지고 있다.
그렇기에 내가 코드를 고쳐도 항상 변경 전과 똑같이 돌아간다는 장점을 가지고 있어 안전하다.
사실을 확인하려면 테스트 suite를 필요로 하는데 미리 준비해둬야 한다.
그리고 조심해야 될 점은 살충제 패러독스에 빠지지 말아야 한다.
코드가 바뀌면 기존 TestCase로 테스트해보고 난 뒤에 보완해야 된다.
소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다. 적정한 장소를 만들어 코드만 분리해도 설계가 좋아진다. 관심사를 분리하면 코드를 이해하고 보수하기 훨씬 쉽다.
이번에 기존 App에서 분리하는 작업을 맡았는데 그부분에서 분리하면 좋은 것들이 보이는데 월요일날 출근해서 개선해 봐야겠다 :)
