2. 정돈된 코드 유지하기

누구도 지저분한 코드로 작업하는 걸 좋아하지 않는다.

좋은 코드를 염두에 두고 있으면, 자연스레 코드의 외관에 신경을 쓰게 된다. 코드의 외관은 작업할 코드의 난이도를 결정한다.

코드의 레이아웃에 대한 논쟁이 증가할수록 의미 없는 논쟁으로 빠지게 될 확률이 100%에 가까워 진다.

※코드 레이아웃에 대해 싸우는 것을 멈추고, 자신만의 코드 레이아웃을 만드는 올바른 방법을 익히자

- 보이는 것이 강력하다.

코드의 레이아웃이 중요하지 않다고 할 수는 없다. 어떤 부분이 문제가 되는지 이해해야 한다.

좋은 코드는 명백하며 일관성이 있다. 레이아웃은 거의 눈에 들어오지 않는다. 주의를 끌거나 초점을 흐리지 않은 채 코드의 의도만을 보여주기 때문이다.

좋은 표현 기법은 아름다움을 위해서가 아니라 실수를 줄이기 위해서 중요하다.

명명 또한 마찬가지이다. 나쁜 명명은 단순한 방해 이상으로 완전히 위험할 수도 있다.

일관성 없는 레이아웃과 뒤족박죽인 명명은 코드의 품질이 높지 않다는 징후다. 프로그래머가 레아아웃을 시견 쓰지 않는다면, 품질 문제에도 신경을 쓰지 않을 것이다. 

- 의사소통

두명의 관객을 위해 코딩을 하라

컴파일러와 동료 프로그래머이다.

코딩은 컴퓨터 위에서 하지만 그것을 읽는 것은 사람이다. 

- 지금 코드를 작성하고 있는 당신, 구현 실수를 하지 않으려면 코드는 아주 명확해야한다,

- 몇 주 혹은 몇 달 후에 소프트웨어 배포를 준비할 당신 자신

- 서로의 코드를 통합해야 하는 같은 팀에 있는 다른 동료 

- 이전 버전에 있는 버그를 조사해야 할 미래의 유지 보수 프로그래머

보기에는 예뻐도 의도를 파악하기 어려운 코드가 있다는 점이 있다. 에뻐 보이면서도 터무니 없이 유지하기 어려운 경우도 있다.

주석박스는 유지보수가 쉽지 않기 때문에 되도록이면 간결히 정리하자.

- 레이아웃

코드의 레아아웃은 분야별로 수많은 레이아웃이 존재하지만, 각자 나름의 이유가 있다. 당신의 코드 구조를 개선하고 의도를 드러내는 데 도움이 되는 한 어떤 레이아웃을 택하든 상관없다.

단, 코드를 훑어보는 것만으로도 전체 형태와 구조를 파악할 수 있어야 한다. 

: 구조 잘잡기

글을 쓰듯 코드를 작성해야한다. 코드를 장, 문단, 문장 단위로 자르자. 비슷한 것끼리 묶고 다른 것은 나누라. 함수는 장과 유사하다. 각 장은 별개지만 서로 관련이 되는 코드가 있다. 

코드 연관성과 관련된 순서는 중요하다. 코드를 읽을 사람을 고려하자. 가장 중요한 정보는 마지막이 아닌 맨 앞에 놓는다. 합리 적인 순서로 API를 배치한다. 클래스 정의 최상단에 읽을 사람이 관심있어하는 것을 놓는다. 즉 private 보다는 public을 먼저 적는다.

: 일관성

한꺼번에 모든 레이아웃 스타일을 지키려 애쓰지 말자. 딱 하나만 골라서 일관성 있게 사용하라. 사용하는 언어에 가장 잘 맞는 걸 고르는 것이 좋다. 기본 라이브러리의 스타일을 따르자.

레이아웃 규칙을 따르지 않은 파일을 작업하는 경우에는 해당 파일의 레이아웃 규칙을 따르자.

- 명명

이름은 사물의 정체성을 의미한다. 이름은 사물을 설명하고, 행위나 사용법을 나타낸다. 잘못 명명된 변수는 혼동을 일으킬 수도 있다. 좋은 이름은 서술적이고, 정확하며, 관용적이어야 한다.

그 어떤 사물이든 간에 정확하게 무엇인지 알아야만 이름을 붙일 수 있다. 명확하게 설명하지 못하거나 어떻게 쓰일지 모른다면 제대로 이름을 붙일 수 없다.

: 불필요한 반복을 피하라.

둘러싸인 클래스의 문맥이 확실하게 정의되어 있다면 불필요한 단어의 사용을 피하고, 간단한 단어로 표현하라

: 명확하게 하라

간결함보다 명확함이 우선이다. 

문맥이 전체 내용을 좌우한다. 이름은 수수께기일 필요가 없다.

:관용어법을 지키라

관용적인 이름을 선호하자. 언어에서 주로 쓰이는 대문자화 규약을 따르자. 이들은 합당한 이유가 있을 때만 어길 필요가 있는 강력한 습관이다.

: 정확하게 하라

명명을 정확하게 하라. 명확하지 않은 이름은 코드를 읽는 사람으로 하여금 자료형의 역할이나 성격에 대해 엉뚱한 가정을 하게 만든다.

- 스스로 가다듬기

코드를 정리정돈 해야 하는 경우에는 기능 변경과 모양 변경을 동시에 진행하지 말라. 소스 관리 시스템에 모양 변경과 기능 변경을 별도의 단계로 나누어 커밋하자. 두 가지가 섞여 있는 커밋 내용을 보면 혼란스럽다. 레이아웃 변경이 기능면에서의 실수를 알아채지 못하게 만들 수도 있다.

ps.

소스 코드 관리에 대해선 앞서 이야기한것 처럼 참 많은 것들이 있다.

아직 업계에서, 개인적으로도 일을 시작한지 오래 되지 않았기 떄문에 상당히 어려운 부분이고, 잘 안되는 부분이기도 하다.

기능구현이 눈이멀어 막 짜고 다음에 정리한다거나, 그러다보니 자연스럽게 더러운채로 넘기는 경우도 많았고, 저리하면서 하자고 하니 속도가 안나와서 결국 제자리로 돌아간적도 많다. 그래도 습관이란게 중요하니 다시 열심히 해봐야겟다.