개발자의 교과서로 알려져있는 클린 코드를 읽어보려고 한다
6주 내 완독이 목표.
이번 주는 1,2장을 읽었다

이 블로그에 쓰는 내용은 총정리보다는 새로 알게 된 정보와 알면 좋을 것 같은 정보들을 쓸 예정이다

제 1장 깨끗한 코드

• 나쁜코드
  우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안 돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다.
  나중은 결코 오지 않는다.

시작부터 뼈를 때린다

• 원초적 난제
  기한을 맞추려면 나쁜 코드를 양산할 수밖에 없다고 느낀다. → 빨리 가려고 시간을 들이지 않는다
  빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다

• 깨끗한 코드란?
  • 비야네 스트롭스트룹(C++ 만든사람) : 우아하고 효율적인 코드. 속도뿐만 아니라 CPU 자원을 낭비하지 않는 코드
  • 데이브 토마스, 앤디 헌트(실용주의 프로그래머) : 이미 창문이 깨진 건물은 사람들이 쳐다보지 않는다. 세세한 사항까지 신경쓴 철저한 오류 처리. 한 가지를 잘하는 코드(단일 책임인듯)
  • 그래디 부치 : 단순하고 직접적인 가독성이 좋은 코드. 추측이 아닌 사실에 기반하여 필요한 내용만 담은 코드
  • 큰 데이브 토마스(위에 사람이랑 다른 사람) : 다른 사람이 고치기 쉬운 코드. 작을수록 좋다
  • 마이클 페더스 : 주의 깊게 작성한 코드
  • 론 제프리스 : 모든 테스트를 통과, 중복이 없음, 시스템 내 모든 설계 아이디어 표현, 클래스/메서드/함수 등을 최대한 줄임(작게 추상화)
  • 위드 커닝햄(위키 창시자) : 짐작하는 기능을 그대로 수행하는 코드 → 코드를 해독하느라 머리를 쥐어짤 필요가 없어야 함

대단한 사람이 많은 것 같음

우리 업계에는 특정 언어를 신봉하는 광신자가 아주 많다. 하지만 프로그램을 단순하게 보이도록 만드는 열쇠는 언어가 아니다. 언어를 단순하게 보이도록 만드는 열쇠는 프로그래머다!

자바만 쓸 줄 아는 나에게 하는 말 같다..

• 우리는 저자다
  저자에게는 독자가 있다. 그리고 독자와 잘 소통할 책임도 있다. 다음에 코드를 짤 때는 자신이 저자라는 사실을, 여러분의 노력을 보고 판단을 내릴 독자가 있다는 사실을 기억하기 바란다.
  새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다.

• 보이스카우트 규칙
  적극적으로 코드의 퇴보를 막아야한다. 체크아웃할 때보다 좀 더 깨끗한 코드를 체크인한다면 코드는 절대 나빠지지 않는다. 한꺼번에 많은 시간과 노력을 투자해 코드를 정리할 필요가 없다.

이 책의 모든 내용들이 정답은 아니겠지만, 나보다 많은 코드를 짠 사람들의 의견이니만큼 한 번 의도를 생각해 볼 시간을 가져보는 것은 좋을 것 같다.

제 2장 의미 있는 이름

• 의도를 분명히 밝혀라
  좋은 이름을 지으려면 시간이 걸리지만 좋은 이름으로 절약하는 시간이 훨씬 더 많다.

  • 변수의 존재 이유는?
  • 수행 기능은?
  • 사용 방법은?
  • 따로 주석이 필요하다면 의도를 분명히 드러내지 못했다는 말이다.

• 코드의 함축성은 문제가 될 수 있다.

  • 단순히 이름만 함축하지 않고 풀어서 설명해도 함수가 하는 일을 이해하기 쉬워진다.

• 그릇된 정보를 피하라

  • 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하면 안됨
  • 실제 List가 아니라면, List라고 명명 X → 근데 실제 List라고 하더라도 안넣는게 좋다고 함
  • 서로 흡사한 이름을 사용하지 않도록 주의

• 의미 있게 구분하라

  • 컴파일러나 인터프리터만 통과하려는 생각으로 코드를 구현하면 문제가 발생한다
  • 연속된 숫자를 덧붙이거나 불용어를 추가하는 방식은 적절하지 못함 → 이름이 달라야 하면 의미도 달라져야 함
  • 읽는 사람이 차이를 알도록 이름을 지어라

• 검색하기 쉬운 이름을 사용하라

  • 숫자나 e 같은 것들은 피해라

그동안 매직 넘버 같은 것들 그냥 냅다 사용했는데 검색하는거 생각해보니까 변수 선언을 꼭 해줘야겠다는 생각이 들었따....

• 인코딩을 피하라

  • 헝가리식 표기법
  • 멤버 변수 접두어
  • 인터페이스 클래스와 구현 클래스

• 자신의 기억력을 자랑하지 마라

  • 반복 루프 범위가 아주 작고 다른 이름과 충돌하지 않을때의 i,j,k는 괜찮다(l은 헷갈려서 절대 안됨)
  • 명료함이 최고

• 클래스 이름
  • 명사나 명사구가 적합
  • 동사는 사용하지 않음

• 메서드 이름
  • 동사나 동사구가 적합
  • 접근자(get), 변경자(set), 조건자(is)
  • 생성자를 중복 정의 할 때는 정적 팩토리 메서드 사용
  • 생성자 사용을 제한하려면 해당 생성자를 private로 선언

Complex fulcrumPoint = Complex.FromRealNumber(23.0);

Complex fulcrumPoint = new Complex(23.0);

위의 코드가 더욱 이해하기 쉬움

• 기발한 이름은 피하라
  • 재미난 이름보다 명료ㅛ한 이름 선택

• 한 개념에 한 단어를 사용
  • 추상적인 개념 하나에 단어 하나를 선택해 고수 - fetch, retrieve, get으로 각각 부르지 마라

근데 이건 혼자 개발하는게 아닌 이상 명확한 규칙을 정해놓고 해야할 것 같다. 근데 막상 규칙이 있어도 매번 보지 않아서 처음에 각인되지 않는 이상은 계속 다르게 쓸듯

• 불필요한 맥락을 없애라
  • 일반적으로 짧은 이름이 긴 이름보다 좋다 → 단, 의미가 분명한 경우에 한함

끝

아 이제 2장 읽었는데 규칙이 너무 많다