1am wish

* 개발 도서 리뷰 게시물은 책을 요약해둔것이 아닌, 책을 읽고 독자인 제가 깨달은 점, 받아들인 점을 작성한 글입니다.

나는 여태까지 코드를 짤 때 주석을 상세히 작성하는게 매우 중요하다고 생각했다. 다음에 코드를 다시 마주했을 때 이해하기도 편하고 코드를 읽지 않고도 의도를 이해할 수 있었기 때문이다.

그러나 이 책에서는 주석은 필요악이라는 표현을 썼다. 

코드에서 의도를 제대로 표현하지 못해서 주석에 주저리주저리 내용을 작성하는 것이기 때문이다.이제 버전관리 프로그램도, IDE도 너무나 발전했기 때문에 주석에 이력 남기기와 같은 행위는 필요 없어졌고, 정확하지 않는 변수명을 주석으로서 보충하는 것도 시간이 흘러 의도가 변할 수 있다. 물론 시스템을 구현하는데 근거가된 정책, 프로그램을 구동하는데 알아야할 참고사항과 같이 꼭 필요한 주석도 있다. 하지만 이렇게 꼭 필요한 경우를 제외한 주석들은 필요가 없다.. 

내가 여태까지 코드에 의도를 표현하는 것과 코드를 읽는 것에 있어서 매우 게을렀구나 라는 생각을 했다. 이걸 이제서야 알았다니 아쉬운 마음이 들었다.

그래서 이제라도 주석 사용을 최소화하기 위해 함수를 쪼개고 함수와 변수에 좋은 이름을 부여하여 주석없이도 쉽게 이해할 수 있는, 코드 자체로 설명이 되는 코딩을 해야겠다고 생각했다.

또한, 2,3 장에서 변수 명과 함수 명을 자세하게 쓰는 것을 강조한 이유가 이해되었고 4장의 내용으로써 완벽히 설득되었다!

* 개발 도서 리뷰 게시물은 책을 요약해둔것이 아닌, 책을 읽고 독자인 제가 깨달은 점, 받아들인 점을 작성한 글입니다.

함수는 프로그램의 가장 기본 단위이다.

이러한 함수를 만들 때 3장에서 강조하는 것은 다음과 같이 요약해봤다.

함수는 중복없이 딱 한가지의 일을하며 작게 만들어야한다.

이 말을 듣고 나는 내가 만들어낸 중복있는 코드이 생각났다.. 이런식으로 내가 잘못 양산해낸 코드가 얼마나 많겠는가 싶어서 잠시 우울해졌지만, 이를 개선할 생각에 또 머리를 굴리게 됐다. 중복을 없앨 방법은 다양하다.1. include 방식2. 함수로 분리3. 다형성을 이용해서 하위 클래스 내에 숨기기.4. 부모 클래스로 몰아버리기등등 .. 또 어떤 방식이 있을지 나만의 방식으로 생각해봐야겠다.오늘 내가 싸놓은 코드는 어떤 식으로 개선할지 구상이 끝났으니 내일 출근길은 즐겁겠군 !

* 개발 도서 리뷰 게시물은 책을 요약해둔것이 아닌, 책을 읽고 독자인 제가 깨달은 점, 받아들인 점을 작성한 글입니다.

사실 개발을 해본 사람들이라면,, 모두가 공감할 것이다. 이름 짓는데 시간이 많이 소요된다 .. 네이밍은 정말 어렵다 .. 2장은 나와같이 네이밍이 어려운, 깨끗한 네이밍이 어려운 개발자들을 위해 만들어준 지침 목록이다.ㅎㅎ

결국 이 책을 관통하는 '읽기 쉬운 코드'를 만들기 위한 이야기들이지만 그 중에서 내가 인상깊게 배운 몇 가지만 추려보았다!!

1. 이름은 의도가 분명하게 !
   1. 변수(또는 함수, 클래스)의 존재 이유, 수행 기능, 사용방법은? 따로 설명 주석이 필요하다면 의도를 분명히 드러내지 못한 것이다. 
2. 정확한 정보 제공
   1. 변수에 약어를 사용X 풀어서 작성O
3. 발음하기 쉬운 이름을 사용하라
4. 검색하기 쉬운 이름을 사용하라
5. 클래스 이름 : 명사나 명사구가 적합
6. 메서드 이름 : 동사나 동사구가 적합
   1. 접근자, 변경자, 조건자는 javabean 표준에 따라 앞에 get,set,is를 붙인다.
   2. 생성자를 중복정의할 때는 정적 팩토리 메서드를 사용한다.(메서드는 인수를 설명하는 이름을 사용)

내가 가장 깨달은 부분은 1번 "이름은 의도가 분명하게"다. ㅎㅎ 그동안 변수이름이 이렇게 길어져도 되나? 하면서 내맘대로 추린 변수들이 많은데 책에 나오는 몇가지 예시를 읽으면서 변수가 긴것보다, 변수가 뭔지 알 수 없는게 더 치명적이라는 것을 깨닫고, 내가 여태까지 작성한 멍청한 변수 이름들에게 미안했다 .. 앞으로는 주석보다는 이름에 명시!

* 개발 도서 리뷰 게시물은 책을 요약해둔것이 아닌, 책을 읽고 독자인 제가 깨달은 점, 받아들인 점을 작성한 글입니다.

이 책의 1장에서는 왜 깨끗한 코드가 그렇게 중요한지, 깨끗한 코드가 무엇인지 알지 못하고 책을 읽으려는 (나와같은) 독자에게 그 이유를 더 극대화시켜서 새겨넣어주었다. 

내가 간추린 이유는 다음과 같다.

코드를 짤 때, 새 코드를 작성하는 것보다 기존 코드를 읽는 시간이 훨씬 많다. 코드를 짜는 시간을 늘이는 것은 이 이전 코드들이고, 이 이전 코드들이 읽기 어려운 '나쁜' 코드들 이기 때문에 언제나 코드를 깨끗하게 유지하는 습관이 필요하다.

나는 이 이야기가 학생이든, 주니어든, 시니어든 개발자는 모두가 경험했을 것이라고 생각한다.

그렇다면 깨끗한 코드는 무엇인가? 나는 위 이유에서 깨끗한 코드란결국 읽기 좋은 코드인가 라고 생각했다.

• 깨끗한 변수이름
• 깨끗한 함수
• 깨끗한 클래스
• 모든 테스트 통과
• 중복 제거
• 등등 ..

개발 계의 큰인물들이 말하는 깨끗한 코드는 위과 같이 추릴 수 있었는데, 결국 유지보수하기 좋은 코드를 일컫는 이야기다. 깨끗한(유지보수하기 좋은) 코드는 다음 작업에서 다시 읽을 때 시간을 줄여주고, 이후 작성되는 코드에도 깨끗한 코드가 유지되고, 결국 원활한 소통, 생산성 향상에 큰 도움이 될 것이다.

1장의 가장 인상적이었던 한줄 !

보이스카우트 규칙 : 캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.