방프리

읽기 시작한건 21년도였지만 잦은 야근과 쉬겠다는 핑계로 미룬지 3년만에 다 읽었다.하지만 다 읽은 후에도 담당 프로젝트 오픈과 라이브 대응으로 미루고 까먹고 또 다시 미루다 생각나서 작성하는 리뷰다.처음에는 하나하나 기억하려고 챕터 별로 정리하려고 했지만 그러기엔 이 도서를 끝까지 다 읽을 지도 미지수였고이것 말고도 해야할 게 너무 많아 그러고 싶지 않았다.이 책을 읽으면서 해당 도서에 대한 평가를 보니 부정적인 평가도 꽤나 접할 수 있었다.그렇다고도 생각되는게 도서 제목이 많은 사람들을 광신도로 이끌기에 최적화된 제목이 아닐까 싶다."클린코드", 제목만 봐서는 책을 읽기만 하면 아주 가이드처럼 완벽한 코드를 만들 수 있지 않을까?이것만 따라하면 돼!! 라는 생각을 심어주기엔 딱이기 때문이다.처음엔 꽤..

3. 함수 1. 작게 만들어라! - 함수는 작게 만들수록 좋다. 대략적으로 100줄 이하가 좋다. 2. 한 가지만 해라! - 한 가지 함수에 한 가지 일만 하도록 하자. 여러 일을 한 가지 함수에 넣는 순간 디버깅이 힘들어진다. 3. 함수 당 추상화 수준은 하나로! - 한 함수의 추상화 수준은 하나로 통일되어야 한다. 근본 개념인지, 세부 사항인지 구분이 어렵기 때문이다. 4. 위에서 아래로 코드 읽기 : 내려가기 규칙 - 책을 읽는 느낌으로 코드가 위에서 아래로 읽혀야한다. 논리에 맞게!! 5. 서술적인 이름을 사용해라! - 함수의 이름만으로 어떤 동작을 하는지 유추할 수 있도록 잘 짓자. 길어도 상관없다. 6. 함수 인수 - 무항일수록 좋다. 테스트도 간편해지도 확인해야할 값의 양도 적어지기 때문이다..

2. 의미있는 이름 1. 의도를 분명히 밝혀라. - 변수나 함수 그리고 클래스들의 이름들은 존재 이유, 수행기능, 사용 방법등을 유추할 수 있게 만들어야 한다. (코드를 읽어서 바로 내용을 알 수 있게 이름을 지어주자) 2. 그릇된 정보를 피해라. - 널리 쓰이는 의미가 있는 단어를 사용해서는 안된다. 여러 개를 묶는 변수는 List가 아닌 복수형으로 지정해주는 것이 좋다. List 컨테이너로 된 변수 또한 List로 지어서는 안된다. 비슷한 단어는 혼란만을 야기할 뿐이다. 일관성이 떨어지면 그릇된 정보일 뿐이다. 절대 o, l과 같은 다른 문자와 혼동이 일어날 수 있는 단어는 사용하면 안된다. 3. 의미 있게 구분하라. - 연속된 숫자를 덧붙이는 변수는 아무 의미 없는 변수이다. 읽는 사람이 차이를 알..

1장. 깨끗한 코드 1. 코드가 존재하리라! - 시스템의 자동화는 어느정도 이루어지나 한계점이 분명히 존재하기 때문에 코딩은 절대 사라지지 않는다. 또한 코딩은 요구사항을 표현하는 언어이다. 그러므로 분명하고 명시적으로 만들줄 알아야 한다. 2. 나쁜코드 - Leblanc' Law (Later Equals Never), 나쁜코드는 수정하지 않고 지나친다면 눈덩이가 불어나듯 감당할 수 없는 큰 문제로 다가오게 된다. 지금 문제에 직시했다면? 바로 고쳐나가자 3. 나쁜코드로 치르는 대가 - 처음에는 진도가 빨리 나가지만 얼마 안가 개발속도를 크게 저하시킨다. (몇 날 몇일을 버그를 고치는 것에 소비하게 된다.) 어느 시점에 도달하게 되면 더 이상 정리할 수 없을 정도로 커지게 된다. 물론 재설계의 방법도 있..