요약 📚
이번주에는 클린코드 ~3장까지 책을읽고 이에 대한 독서록을 작성 하려한다. 1장에서는 이책의 제목이자 우리가 바라는 "클린코드"가 어떤 코드를 의미하는지 정의해보고 이책의 대략적인 구조에 대해서 알아보았다. 이를 바탕으로 2장에서는 의미있는 변수명, 3장에서는 함수를 사용할때 어떤식으로 이름을 짓고 구조를 어떻게 만들어야 좋은 함수라고 할 수있는지를 알 수 있었다.
깨끗한코드
책의 구성은 먼저 깨끗한 코드에 관한 이론적인 부분들을 설명하고 이를 실제코드 분석을 통해서 어떤 코드가 깨끗한 코드를 말하는지를 좀 더 직관적으로 보여주고 마지막으로 휴리스틱에 대해 정의한다고 한다.
...지금까지 우리가 요구사항 명세 분야에서 배운 교훈이라면, 제대로 명시한 요구사항은 코드만큼 정형적이며 테스트 케이스로 사용해도 좋다는 사실이다!
정말 지금 내 상황과 맞아서 너무 공감되는 부분이었다. 2월부터 본격적으로 MES프로젝트를 시작하기 위해 지금 2주동안 공급업체쪽에 상주하면서 현재사용하는 기능들 및 추가 요구사항들을 인터뷰를 통해 듣고 화면설계서와 요구사항정의서를 작성하는데 이 부분을 읽으면서 뭔가 지금 이렇게 고생하면서 해야되는 이유를 찾은듯한 기분이었다.
...급해서?서두르느라?아마 그랬으리라. 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 시간을 보냈다가 상사한테 욕 먹을까봐, 지겨워서 빨리 끝내려고, 다른업무가 너무밀려서...모두가 겪어본 상황이다.
...물론 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.
1장을 읽으면서 가장 찔끔했던 부분이다. 개발일정은 언제나 촉박하고 그렇다보니 시간에 쫓겨 정확한 검증을 거치지 않거나 올바른 변수명을 사용하지 않고 코드를 만들었고 이는 결국 쓰레기코드를 만드는 원인이 되었다. 물론 그때는 우선 코드를 완성하고 유지보수 및 테스트단계에서 코드를 다시 재수정하면 될거라고 생각했지만 역시나 그런일은 오지않았다...
처음만들때부터 충분한 고민을 거치고 코드를 만들어야 한다는걸 다시한번 통감하게 되는 부분이었다.
뒷부분을 읽으면서 쓰레기코드가 어떤일을 발생시키는지 나오는데 결국 이런 쓰레기코드들이 모여 생산성이 떨어지게되고 어떠한 방식으로도 해결이 안되어 결국에는 기존의 코드를 엎어버리고 재설계를 들어가게 되는 최악의 상황이 발생 했다고 한다.
그렇다면 깨끗한 코드는 무엇일까? 이책에서 저자는 개발분야에서 유망하고 노련한 프로그래머들에게 의견을 물었다고한다.
- 논리가 간단해야 버그가 숨어들지 못한다. 의존성을 최대한 줄여야 유지보수가 쉬워진다. 오류는 명백한 전략에 의거해 철저히 처리한다.
(by 바야네 스트롭스트룹)- 가독성이있어야한다.
(by 그레디 부치)- 특정 목적을 달성하는 방법은 하나만 제공한다. 의존성은 최소이며 명확히 정의한다. 다른사람이 고치기 쉬워야한다.
(by 큰 데이브 토마스)
여러 프로그래머들이 깨끗한 코드에 대한 정의를 했지만, 결국 말하는 바는 하나로 귀결되게된다. 중복을 피하라. 한기능만 수행해라. 제대로 표현하라. 작게추상화하라
올바른 변수명 짓기
개발을 하다보면 어느순간 고민하는게 있다. 바로 '변수명'이다. 작업을 하다보면 어떤 변수명을 사용해야 나중에 수정할때 직관적으로 알 수 있을까? 짧고 간단한 변수명은 없나?에 대한 고민을 하게된다. 실제 프로젝트를 할때도 뭔가 내가 익숙한 변수명 패턴들을 사용하게 되었고 처음에는 문제가 없지만, 변수가 많아지거나 복잡해지면 점점 이상한 변수명을 사용하게 된다. 이 책에서는 변수명을 만드는 규칙?팁?같은걸 알려준다.
- 의도를 분명하게 밝혀라
- 그릇된 정보를 피해라
흡사한 이름을 사용하거나 일관성이 떨어지는 표기법 사용은 지양해야 하고 알파벳 특성상 소문자L(l) 대문자 O는 숫자와 같이 사용했을때 오해의 소지가 있다.- 의미있게 구분하라
의미가 불분명한 Info/Data등의 사용은 지양해야한다.
이 책에서는 변수명의 길이에 대한 고민을 크게하지 않는것처럼보인다. 나는 그동안 프로젝트를 진행하면서 변수명을 최대한 짧게 쓰기위해서 함축을 하다보니 나중에 의미를 이해하기 힘든 경우가 종종 있었는데, 책에서는 변수명이 길어지는 것을 감안하더라도 의미있게 이름을 작성해야 한다고 한다.
함수
- 작게만들어라.
- 한가지만해라 (= 부수적인 효과를 넣지마라)
- 함수당 추상화 수준은 하나로
- 반복하지마라
- 함수에서 인수(매개 변수)를 최소화해라. 가능하면 단항인수를 사용해라.
- 오류 코드보다 예외를 사용해라.
이상이 함수를 만드는 법으로 추천하는 방법이라고 한다.많은 부분들 중에서 공감되는 부분도 있고 아직 공감하지 못하는 부분도 있지만 1장에서 여기나온 규칙들이 정답은 아니라고 했기 때문에 선택적으로 받아들일 것같다. 함수를 작게 만들어서 가독성을 높이고 반복을 줄여서 무의미한 코드를 줄이는 부분들과 예외를 사용하는 부분들은 공감이 가는부분들이었다. 길어지는 코드들은 나중에 수정할때 오류가 발생하기 때문에 한가지 기능으로 함수를 작성하는 부분들은 필요하지만 최종적으로 3-7에 작성된 함수들을 봤을때 한두줄로 이루어진 함수들이 과하게 많아지는 느낌을 받아서 필요에따라서 부수적인 효과들을 하나로묶어서 함수의 갯수가 과하게 늘어나는 것을 방지하는것은 어떨까라는 생각이 들기도 하였다.
