[클린코드]14.점진적인 개선

지난 번 읽을 때 대충 읽었던 장인데, 이번에 읽을 때는 꼼꼼하게 읽으려고 노력했다. 앞의 장들은 깨끗한 코드를 위한 원칙들에 대한 설명이었다면, 14장은 예제를 함께 푸는 듯한 느낌이었다.
실제로 어떤 식으로 코드를 정리하는지, 무엇을 고려해서 리팩터링을 하는지 분석하면서 읽어보았다. 상황에 따라 고려해야할 것들이 달라지기는 하겠지만, 전체적인 흐름을 공부하면서 대략적으로는 감을 잡을 수 있었다.

📆TIL(Today I Learned) 날짜

2022.04.26

📑오늘 읽은 범위

14.점진적인 개선

✍🏻책에서 기억하고 싶은 내용

지난 수십여 년 동안 쌓아온 경험에서 얻은 교훈이라면, 프로그래밍은 과학보다 공예(craft)에 가깝다는 사실이다. 깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다는 의미다.

대다수 신참 프로그래머는 이 충고를 충실히 따르지 않는다. 그들은 무조건 돌아가는 프로그램을 목표로 잡는다. 일단 프로그램이 ‘돌아가면’ 다음 업무로 넘어간다. ‘돌아가는’ 프로그램은 그 상태가 어떻든 그대로 버려둔다. 경험이 풍부한 전문 프로그래머라면 이런 행동이 전문가로서 자살 행위라는 사실을 잘 안다.

점진적으로 개선하다
프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다. 어떤 프로그램은 그저 그런 ‘개선’에서 결코 회복하지 못한다. ‘개선’ 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다.
그래서 나는 테스트 주도 개발(Test-Driven Development, TDD)이라는 기법을 사용했다. TDD는 언제 어느 때라도 시스템이 돌아가야 한다는 원칙을 따른다. 다시 말해, TDD는 시스템을 망가뜨리는 변경을 허용하지 않는다. 변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다는 말이다.

소프트웨어 설계는 분할만 잘해도 품질이 크게 높아진다.

단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다. 설계와 구조를 개선할 시간이 없다고 변명할지 모르지만 나로서는 동의하기 어렵다. 나쁜 코드보다 더 오랫동안 더 심각하게 개발 프로젝트에 악영향을 미치는 요인도 없다.

그러므로 코드는 언제나 최대한 깔끔하고 단순하게 정리하자. 절대로 썩어가게 방치하면 안 된다.

❓궁금한 내용, 잘 이해되지 않는 내용

• 없음