나쁜 코드

p4
우리 모두는 자신이 짠 쓰레기 코드를 쳐다며 나중에 손보겠다고 생각한 경험이 있다.
우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다.
물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

'나중은 결코 오지 않는다.'

왜 사람들이 아키텍처와 리팩터링을 그렇게 중요하게 생각하는지 알 수 있는 말이다.
프로젝트를 하다보면 새로운 기능을 추가하기 바쁘거나 기간 내에 빠르게 완성을 해야하는 상황에 닥친다.
이 때 '나쁜 코드'에 대한 신경을 쓰지 않은 채 앞만 보고 달려가게 되면 생산성은 계속 떨어지고 결국에는 코드를 갈아엎어야 하는 상황에까지 도달하게 된다.
절차 지향처럼 짜여진 객체 지향 코드, 수많은 책임을 갖고 있는 클래스나 메서드, 도저히 코드를 해석할 수 없게 선언된 변수나 메서드 이름들 등 간단한 리팩터링으로는 해결이 되지 않는다.

나같은 경우는 학교 프로젝트를 할 때 이런 경험이 많았다.
분명 내가 짠 코드임에도 도저히 해석하기 힘든 경우가 종종 있었다.
그래서 시간이 여유로운 프로젝트를 할 때는 설계나 리팩터링에 신경을 많이 쓰려고 노력을 하는 편이다.

하지만 아직 경험이나 지식이 부족한 상태에서는 내가 아무리 고민을 하고 노력을 해봐도 한계가 있고 오히려 그 부분에 집중하느라 프로젝트 자체에 대한 집중이 소홀해져 배보다 배꼽이 커지는 경우도 생겼다.

그렇기에 이번에 이 책을 스터디로 읽게 된 것을 정말 다행이라고 생각하고 열심히 공부해야겠다는 생각을 했다.

깨끗한 코드란

이 소제목에서 여러 거장 프로그래머들이 생각하는 깨끗한 코드란 무엇인지에 대해 적혀있다.
이들이 말한 깨끗한 코드의 키워드 중 중요하다고 생각했던 키워드는 다음과 같다.

가독성, 테스트, 주의를 기울인 코드, 중복 줄이기, 추상화, 책임 등

당연하다고 느껴지는 키워드들이기도 하다.
당연히 깨끗한 코드란 나를 포함한 여러 사람들이 읽었을 때 쉽게 읽을 수 있어야 하며, 좋은 설계를 통해 코드들이 각각의 적절한 책임을 가지고 모든 테스트 코드를 통과할 수 있어야 한다.
그렇게 되려면 자연스럽게 코드를 신경써서 작성하게 되고 중복된 코드 또한 사라질 거라고 생각한다.

우리는 저자다

우리는 저자이면서 동시에 독자다.

내 코드를 가장 많이 보는 독자는 아마 나 자신이 아닐까?

미래의 나를 위해서라도(하다못해 5분 뒤의 나를 위해서라도) 조금 더 코드를 잘 짜려고 노력하다보면 자연스럽게 나중에 내가 작성한 코드를 볼 독자들에게 좋은 저자가 되지 않을까 하는 생각이 들었다.

느낀 점

첫 장에서는 깨끗한 코드와 나쁜 코드에 대한 정의와 책을 읽을 마음가짐 정도를 잡게 해주는 내용이었던 것 같다. 🙂