Clean Code 14장 점진적인 개선
명령행 인수 구문분석기 사례 연구
어떻게 짰느냐고?🙄
깨끗한 코드를 짜려면 먼저 지저분한 코드를 짠 뒤에 정리해야 한다
- 돌아가는 프로그램을 목표로 잡는 것이 아니다
- 여기서 그치는 것이 아니라 점점 개선해 나가야 한다
그래서 멈췄다❌
코드를 확장해 나가면서 코드가 더 나빠질 거라는 생각이 든 순간 저자는 기능을 더 추가하지 않고 리팩터링을 시작했다.
점진적으로 개선하다💦
-
프로그램을 망치는 가장 좋은 방법 중 하나는 개선이라는 이름 아래 구조를 크게 뒤집는 행위다
-
변경을 가한 후에도 시스템이 변경 전과 똑같이 돌아가야 한다
-
TDD(테스트 주도 개발)을 사용하면 좋다
-
변경을 할 때마다 테스트를 통해 변경을 가하기 전과 똑같이 돌아간다면 변경을 한다
결론❗❗
그저 돌아가는 코드만으로는 부족하다. 나쁜 코드는 더 오랫동안, 심각하게 개발 프로젝트에 영향을 미친다.
코드는 언제나 최대한 깔끔하고 단순하게 정리하자
느낀점🙊
코드를 일단 짜고 나면 '나중에 다시 보면서 리팩터링 해야지'하지만 막상 다시 돌아와서 보는게 어려웠다. 계속 해나가야 하는 과제들이 있고 '일단 프로그램이 돌아가니까-'싶기도 하고 그랬는데, 결론 부분에서 단순히 돌아가는 코드에 만족하는 프로그래머는 전문가 정신이 부족하다고 말한 부분에서 좀 많이 찔렸다.
리팩터링을 하게 되면 확실히 코드가 보기 편해지고 깔끔해지고 더 좋아지는 게 보인다. 근데 그 과정 자체가 익숙하지 않다보니까 시간을 투자하는 부분이 줄어드는 것 같다.
학교에서 하는 과제나 프로젝트들은 한 번 만들고 제출하면 끝인 경우가 많다. 그래서 학교에서도 리팩터링의 중요성에 대해서 배워본 적이 없고, 또, 굳이 해야하나 싶은 생각이 들었던 것 같다. 하지만 실무에 나가게 되면 한 번 쓰고 끝인 시스템은 거의 없을 것이다. 그렇기 때문에 유지보수가 필요한 거고 리팩터링이 필요한 거라는 생각이 들었다. 지금만을 생각하기 보다는 앞으로 내가 짜게 될 코드들을 생각하면서 리팩터링에 대해 습관을 들여놓을 필요가 있겠다는 생각이 들었다.
