[개발 일기] 2025.05.21 - 점진적인 개선 (Feat : 클린코드)

💡 개요

 

오늘은 개발 서적 클린코드의 ‘14장-점진적인 개선’ 부분을 읽으면서 느낀 점을 정리해 보자.

 

 

 

🛠️ 점진적인 개선

 

클린코드의 14장은 거의 90%가 코드이다…

 

 

대부분 애플리케이션의 main() 메서드가 받는 파라미터를 관리하는 Args 관련 코드의 점진적인 개선에 관련된 코드이다.

 

굉장히 지저분한 코드에서 점차 깔끔한 코드로 발전해나가는 모습이 인상적이니까, 꼭 읽어보면 좋슴다.

 

 

그래서 간략하게 저자가 하고싶은 말을 정리만 해보자.

 

 

일단 14장의 이름인 ‘점진적인 개선’ 이라는 의미는 일단 ‘1차 초안을 작성해서 점진적으로 개선하자?’ 나쁜 건 아니다.

 

 

근데 그건 진짜 어렵다.

 

 

많은 신입 개발자들은 ‘일단 코드를 작성하자!’ 라고 생각하고, 만약 정상적으로 동작하면 ‘어? 되네??’ 하고 넘겨버린다. (사실 나다.)

 

 

즉, 1차 초안과 같이 일단 코드를 작성하는 것은 좋다. 그런데 반드시 코드는 최대한 깔끔하고 단순하게 정리해야 하는 것이다.

 

 

그 이유는 다음과 같다.

 

• 프로젝트에 나쁜 일정이 있다? 변경하면 된다.
• 잘못된 요구사항이 있다? 수정하면 된다.
• 나쁜 팀 역학이 있다? 복구하면 된다.

 

하지만 코드가 잘못된 순간, 이는 어떤 방식으로 팀의 발목을 잡을 지 알 수 없다.

 

 

 

🤔 점진적인 개선과 TDD..?

 

개발자에게 개선이 어려운 이유는 바로 ‘개선’ 전과 똑같이 프로그램을 돌리기가 아주 어렵기 때문이다. (Git 잘 사용하면 되긴 해..)

 

 

그렇기 때문에 여기선 TDD을 점진적 개선에 사용하라고 나온다.

 

 

그 이유는 일단 TDD가 잘 작성되어 있다면, 점진적으로 개선하기 전과 개선한 후의 테스트 결과가 동일해야 한다는 점 때문이다.

 

 

TDD의 목적은 프로그램의 신뢰성을 높이는 것도 있지만, 개발자가 기능을 구현하거나 수정할 때 프로그램을 망가뜨리는 변경을 절대 허용하지 않기 때문이다.

 

 

만약 코드를 수정했는데, 테스트가 성공하지 못한다는 것은 프로그램을 망가뜨리는 것이기 때문에 바로 테스트 실패 결과를 뱉는다.

 

 

만약 기능 수정・개선을 진행한다??

 

 

난 무조건 아래 원칙을 지킬 것이다.

 

while (true) {
    코드_수정();
    boolean testResult = 테스트_코드_실행();
    
    if (!testResult) {
       throw new Exception("코드 수정했더니 테스트 실패함!!")
    }
}

 

 

 

👨🏻‍💻 참고

 

https://product.kyobobook.co.kr/detail/S000001032980