1. 깨끗한 코드

코드가 존재하리라

어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하기란 불가능 하기에 코드가 사라질 가망은 없다.

궁극적으로 코드는 요구사항을 표현하는 언어라는 사실을 명심

나쁜코드

나쁜 코드에 발목이 잡혀 고생한 기억은 많다. 실제로 고행이라는 이름도 있다.

어째서 나쁜 코드를 짰는가?

-> 당장 급해서, 서두르느라

자신이 짠 쓰레기 코드를 쳐다보며 나중에 고쳐야겠다고 생각한다. But, 나중은 오지 않는다. (르블랑의 법칙)

나쁜 코드로 치르는 대가

나쁜 코드는 개발 속도를 크게 떨어뜨린다. -> 코드를 고칠 때마다 엉뚱한 곳에서 문제가 생기기 때문 ->

결국 생산성이 0에 수렴 -> 재설계를 시작 ->

기존의 것을 100% 수용하지 않으면 관리층에서는 대체하려고 하지 않을 것이고,

오래 지속되다보면 이탈 맴버가 생겨 흐지부지하게 된다.

Conclusion.

시간을 들여 깨끗한 코드를 만드는 노력이 비용을 절감하는 방법이며, 전문가로서 살아남는 길

태도

우리는 프로다.

나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가(프로)답지 못하다.

원초적 난제

빨리 가려고 나쁜 코드를 양상하는 경우가 있다.

하지만 이는 잘못된 판단으로 빨리가는 유일한 방법은 언제나 코드를 깨끗하게 유지하는 습관이다.

깨끗한 코드라는 예술?

깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다.

열쇠는 코드 감각이다.

‘코드 감각'이 없는 프로그래머도 나쁜 모듈을 알아보긴 하지만 거기서 끝이다.

우리는 저자다

Javadoc 에서 @author 필드는 저자를 소개

저자는 독자와 잘 소통할 책임이 있다.

코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다. 우리는 끊임없이 코드를 읽는다.

그렇기에 읽기 쉬운 코드를 짜야 한다.

보이스카우드 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

결론

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.

책은 단지 다른 예술가가 사용하는 도구와 기법, 그리고 생각하는 방식을 소개할 뿐이다.

이 책을 어떻게 활용할지는 독자에게 달렸다.

사견을 덧붙이자면..?

돌아보면 항상.. 안되는 것보단 굴러가는 쓰레기라도 만든다는 느낌으로 일단 구현을 우선했던 것 같다.

물론, 만들면서 더 좋은 건 없을까 고민은 했지..만

잠깐일 뿐이다. 구현을 다 하면 다른 거 하기 바쁜 그런 생활을 보냈던 것 같다.

그리고 ‘코드 감각’ 이라는 얘기가 나오는데, 이 부분은 리펙토링 책에 나오는 ‘냄새’ 와 비슷하지 않은가 싶었다.

어느 정도 경험에 의해 생기는 그런..?

보이 스카우트 규칙이야 워낙 유명하니.. (남자고 군필자라면 다 알거다..)

마지막에 나오는 결론은 많은 생각을 하게 한다.

예술에 대한 책을 읽는다고 예술가가 된다는 보장은 없다.


클린 코드는 이전에 한 번 읽었었다.

읽을 때마다 이렇게 해야지 하는 마음은 생기는데, 막상 코드 앞에서의 나는 책의 내용을 많이 실천하지는 못하는 것 같다.

이번에는 읽은 챕터마다 정리를 할 예정이니 자주 보면서 많이 실천하려고 노력하지 않을까? 싶다 :)