읽기 좋은 코드, 좋은 코드 작성하기

이번에는 최근에 읽은 책인 '읽기 좋은 코드가 좋은 코드다'에 대해서 리마인드도 할겸 조금이라도 생각하게 만들었던 문장들에 대해 정리해보는 시간을 가지도록 하겠습니다. 책을 읽으면서 그동안 저의 안좋았던 코딩 습관들에 대해서 다시 한 번 돌아보는 시간을 가졌고 뭔가 어렵게 짜려고 하기 보다는 심플하면서도 읽기 좋은 코드를 짜도록 노력해야겠다고 다짐하며 정리를 시작하도록 하겠습니다. 가볍게 한 번 읽어주시면 좋을 것 같습니다. ⇒ 코드는 다른 사람이 그것을 이해하는 데 들이는 시간을 최소화하는 방식으로 작성되어야 한다. ⇒ Alt + / = 자동완성(이클립스) >> 그동안 ctrl+space를 많이 사용했는데 옆의 명령어는 바로 자동완성을 해주는 기능 ⇒ 팀에 새로 합류한 사람이 이름이 의미하는 바를 이해할 수 있을까? 만약 그렇다면 그 이름은 괜찮은 것이다. (네이밍의 중요성, 내 주관적인 의미에만 집중해서 작성하지 않기!!!) ⇒  대상을 자세히 묘사하는 구체적인 이름을 사용하라. ex) ServerCanStart()보다는 CanListenOnPort() ⇒ 변수명에 중요한 세부 정보를 덧붙여라. 예를 들어 밀리초의 값을 저장하는 변수 뒤에 _ms를 붙이거나 이스케이핑을 수행하는 변수의 앞에 raw_를 붙이는 것이다.  ⇒ 본인이 지은 이름을 "다른 사람들이 다른 의미로 해석할 수 있을까?"라는 질문을 던져보며 철저하게 확인해야 한다. ⇒ 경계를 포함하는 한계 값을 다룰 때는 min과 max를 사용하라.(start, end보다는 경계를 표현하기 위해서는 min, max가 더 정확) ⇒ 주석의 목적은 코드를 읽는 사람이 코드를 작성한 사람만큼 코드를 잘 이해하게 돕는 데 있다. ⇒ 코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말자.(너무 뻔한 내용들에 대해서는 주석으로 남기지 않는다.) ⇒ 일반적으로 사람들은 코드가 가진 나쁜 가독성을 메우려고 노력하는 '애쓰는 주석'을 원하지 않는다. 프로그래머들은 이러한 규칙을 대개 좋은 코드 > 나쁜 코드 + 좋은 주석이라는 공식으로 설명한다. (나쁜 코드를 짜고 주석을 다는 방식이 아닌 누가 봐도 이해할 수 있는 좋은 코드를 짜는데 집중하자) ⇒ 좋은 주석은 단순히 '자신의 생각을 기록하는 것' 만으로도 탄생할 수 있다. 즉, 코딩할 때 생각했던 중요한 생각을 기록하면 된다. ex) 놀랍게도, 이 데이터에서 이진트리는 해시테이블보다 40%정도 빠르다.  ⇒ 작성하는 코드의 이러저러한 내용을 훗날 수정할 거라는 생각이 들면, 그러한 생각을 주석으로 작성하는 일은 당연하게 받아들여야 한다는 사실이다. 주석은 코드를 읽는 사람에게 코드의 질이나 상태 그리고 추후 개선 방법 등을 제시하여 소중한 통찰을 제공한다. ⇒ 상세하고 공식적인 문서를 작성해야 한다는 생각에 압도당하지 말라. 잘 선택된 몇몇 문장이 아무것도 없는 것보다는 훨씬 나은 법이다. ⇒ 주석을 다는 목적은 코드를 작성하는 사람이 알고 있는 정보를 코드를 읽는 사람에게 전달하는 것이다.  [ 주석으로 설명하지 말아야 하는 것 ] :: 코드 자체에서 재빨리 도출될 수 있는 사실 :: 나쁜 함수명과 같이 나쁘게 작성된 코드를 보정하려고 '애쓰는 주석'. 그렇게 하는 대신 코드를 수정하라. [ 주석으로 기록해야 하는 것 ] :: 코드가 특정한 방식으로 작성된 이유를 설명해주는 내용 :: 코드에 담긴 결함. TODO:혹은 XXX:와 같은 표시를 사용 :: 어떤 상수가 특정한 값을 갖게 된 '사연' ⇒ 기본적으로 if/else를 이용하라. ?: 를 이용하는 삼항 연산은 매우 간단할 때만 사용해야 한다. (삼한 연산자로 표현은 간결해지지만 오히려 읽기 이해하기 힘들어지는 연산들이 있다. 이때는 삼한 연산자보다는 읽기 쉽게 if/else를 사용하여 코딩하도록 하자.) ⇒ "전역 변수를 피하라". 전역 변수는 어디에서 어떻게 사용되는지 일일이 확인하기 어려우므로 이는 합당한 조언이다. 또한, 전역 변수의 이름과 지역 변수의 이름이 중복되어 이름공간이 더러워 질 수도 있고, 어떤 코드가 지역 변수를 변경할 때 실수로 전역 변수를 변경하거나 혹은 그 반대의 경우가 일어 날 수 있다. ⇒ 할머니에게 설명할 수 없다면 당신은 제대로 이해한 게 아닙니다. -알버트 아인슈타인 (참 맞는말이다. 무엇인가를 이해했다는 건 해당 지식이 전무한 사람에게도 설명할 수 있어야 한다. 그만큼 제대로 된 이해는 중요하다 ) ⇒ 복잡한 생각을 다른 사람에게 설명할 때 중요하지 않은 자세한 내용 때문에 듣는 사람을 혼동시키는 일이 종종 있다. '쉬운 말'로 자신의 생각을 지식이 부족한 사람에게 전달하는 기술은 매우 소중하다. (누군가에게 설명하기 위해서는 해당 부분에 대한 완벽한 이해가 수반되어야 함을 명심하자. 이해하면 설명하고 싶어진다 by 김동범) ⇒ 일반적인 '유틸리티'를 많이 생성하여 중복된 코드를 제거하라. ⇒ 사용하지 않는 코드 혹은 필요 없는 기능을 제거하라. ⇒ 코드를 제거하는 작업을 코딩을 하는데 투자한 시간이 쓸모 없는 시간이었다고 여기는 사고를 버려야 한다. 프로그래밍은 창의력을 요구하는 분야다. 사진사, 작가, 영화감독 같은 사람은 모든 작업 결과를 보존하지 않는다. (코드 리무버가 되기 위해서는 해당 소스 코드에 대한 정확한 이해와 판단이 필요하다. 즉 아무나 코드를 제거할 수 없다.) ⇒ 매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라. 라이브러리 전체를 암기하라는 게 아니다. 그냥 그 안에 무엇이 있는지 감을 잡아놓고, 나중에 새로운 코드를 작성할 때 "잠깐만, 이건 전에 API에서 보았던 것과 뭔과 비슷한데..."하고 생각할 수 있기를 바라는 것이다. ⇒ 다른 프로그래머는 종종 테스트 코드를 실제 코드가 어떻게 동작하며 어떻게 사용되어야 하는지에 관한 비공식적인 문서라고 생각한다. 따라서 테스트 코드가 읽기 쉬우면, 사용자는 실제 코드가 어떻게 동작하는지 그만큼 더 쉽게 이해할 수 있다. (테스트 코드의 중요성) 이렇게 리마인드 할 겸 내용을 정리해 보았는데 정리하면서 다시 한 번 머리에 각색이 된 것 같다. 앞으로도 꾸준히 코드를 작성함에 위의 내용들에 유의하며 작성할 수 있도록하고 꾸준히 해당관련 도서 (리팩토링, 클린코드)등을 읽으며 리마인드 해보는 것도 많이 도움이 될 것 같다. 이상으로 포스팅을 마친다.