우디의 성장일기

코드를 깔끔하게 정리해서 코드가 모든 것을 말해준다면 주석은 필요가 없다. 그리고 코드가 변화하고 합쳐지는 과정에서 주석도 그에 따라 유지 보수가 되어야하지만 사실상 쉽지가 않다(코드 유지보수도 힘들어 죽겠는데.. 주석까지..? 이런 느낌이 아닐까). 주석을 줄이고 되도록이면 코드로 의도를 표현하자. 주석은 나쁜 코드를 보완하지 못한다 주석을 쓰는 이유는 대개 코드의 품질이 나쁘기 때문이다. 코드가 어지럽고 복잡해서 주석을 쓰는거라면 차라리 그 시간에 코드를 더 깔끔히 만들어라. 코드로 의도를 표현하라 코드만으로 의도를 전달하기 힘든 경우가 있다. 그럴 때 주석이 필요하다고 말하지만, 주석 대신 함수로 설명해도 충분하다! 아래와 같이 주석 대신 함수명을 통해서 코드의 의도를 설명할 수도 있다. // 학생..

작게 만들어라! 물론 사람마다 '작다'는 기준은 다르다고 생각한다. 책에 나와있는 조금 더 명료한 기준을 들자면 함수의 들여쓰기 수준은 1단 혹은 2단을 넘어가면 안된다. 그리고 if/else/while statement에 들어가는 블록은 한 줄이어야.. 한다고 나와있지만 현업(경험이 없는 지혜이지만)에서 그게 가능할까라는 의문이 든다. 과도한 캡슐화, 추상화는 오히려 독이 되지 않을까 싶어서 이 부분은 참고만 하고 넘어가야겠다. 어쨌든 책에서 말하고자 하는 바는 함수를 장황하게 쓰지 말라는 거니까. 한 가지만 해라! 함수는 한 가지만 잘하면 된다. 그리고 그것만 해야한다. 사실 OOP를 접하다보면 항상 듣는 말이다. 그리고 책에서 함수를 만드는 이유를 '큰 개념을 다음 추상화 수준에서 여러 단계로 나눠..

의미있는 이름은 중요하다고 생각한다. 프로젝트가 커지면 커질 수록, 협업 인원이 늘어날 수록 더 중요해지는 것같다. 클린 코드에서는 이름에 대한 몇 가지 원칙을 제시해주고있다. '의도를 밝혀라' 즉, 코드를 보았을 때 코드 맥락에 관한 정보를 제공할 수 있도록 하기위해서는 이름에 의도가 드러나야한다.(코드의 단순성 < 코드의 함축성) 가령, 보드판 게임에 관한 코드를 작성할 때 List 보다는 List, 그리고 if(cell[STATUS] == FLAGGED)보다는 if(cell.isFlagged()) 라는 명시적인 함수가 더 적절하다. '그릇된 정보를 피하라' 프로그래머에게 혼동을 줄 수 있는 이름들도 '그릇된 정보'에 해당하는 것같다. 명령을 담당하는 클래스를 Manager라고 했다가, 다른 쪽에서는..

마치 프로그래머들을 위한 책이라기 보다는 의외로 자기계발서같다는 생각을 했다. 코드를 깔끔하게 한다는 것, 그리고 그것을 위한 방법은 우리의 삶을 더 효율적으로 만들어주는 방식과 크게 다르지 않다고 생각한다. 특히 '세세함'에 대해서 이야기를 할 때에는 많은 생각을 하게했다. 코드 뿐만 아니라 내가 그냥 이정도면 되지 않을까? 라는 마음으로 그냥 넘겼던 일들을 다시 되돌아 보게 만든다. 그런 일들이 쌓이고 쌓여 지금의 나를 만들어온게 아닌가라는 마음에 앞으로 다가올 일들에 대해 조금 더 책임감을 가질 필요가 있다고 생각했다. 말 그대로 100을 위해서 100을 하겠다고 마음먹어 80을 완료하기 보다는 100을 위해서 나의 게으름, 예상치 못한 오류와 같은 변수들을 모두 감안하여 120, 150을 생각하고..