회사에서 입사하며 클린 코드, 클린 코더, 클린아키텍처 등의 책을 선물해주시면서 책을 읽어보라고 권하셨다. 이에 클린 코드 책을 보게 되었다. 이 글은
초반까지 읽은 부분에 대해서 간략한 소감 및 정리글이다.
attitude
코드들이 나쁜 코드들로 빠르게 변화하는 이유는 여러 가지가 있다. 요구 사항, 서비스 및 상황의 변화가 될 수 있고, 마감 기한에 영향을 받을 수 있다. 너무 짧으면 일단 구현에 급급하게 되니까. 허나 좀 인상적이었던 부분은 이 책에서는 우리(프로그래머)의 책임도 있다고 얘기한다.
매니저가 기간을 짧게 요구할 수 있고 상황에 따른 변화가 생기기 마련이지만 그들은 그들의 해야할 일을 하는 것이다. 중요한 점은, 프로그래머가 책임감을 갖고 있어야한다고 느껴졌다. 마감기한을 짧게 준다고 그대로 기한에 맞춰서 구현만 시킨다던가 수동적인 자세로 코드를 작성하는게 아니라 그로 인해 발생할 수 있는 문제, 상황에 따른 타협 등 팀과의 커뮤니케이션을 잘 해야겠다는 등의 생각이 들었다. 보이스카웃 룰에 대해서도 얘기하는데, "캠프장은 처음 왔을 때 보다 더 깨끗하게 해두고 떠나라" 라는 룰이다. "코드를 더 깨끗하게 만들고 떠나라.." 멋있다.
좋은 코드란?
여러 저명하신 분들이 정의하는 좋은 코드가 무엇인지 기술하고 있다.
한 단어로 요약하자면 읽기 좋은 코드가 좋은 코드라는 생각이 들었다.
이름 짓기
의미있게 구분하라 (의미없는거 붙이지 마라)
정말 처음 코딩을 처음 접했을 때, 이름 짓는게 정말 어렵다고 누가 얘기하는 걸 들었을 때 그냥 하는 소리로 들렸다. 헌데 정작 프로젝트들을 좀 해보고 이 책을 또 보다보니 좋은 네이밍이라는 것은 거저 얻어지는 것이 아니구나라는 생각이 들었다.
accountList 와 같은 것을 피하라는데, 뜨끔했다. ~List 와 같은 네이밍을 꽤 써왔기 때문이다. 차라리 bunchOfAccount를 쓰라고 한다. 리스트 형이 아닌 다른 형태로 변경 될 수 있기에.
또 ProductInfo, ProductData 와 같이 info, data는 노이즈와 별 차이가 없다는 점도 '헉' 하는 포인트였다. 생각해보면 인포나 데이터가 아닌건 없기에 그런 듯 하다. 마찬가지로 변수 명에 variable이 들어간다 던가, table이 들어가는 것도 지양해야한다. NameString 도 마찬가지다. 네임이 스트링이 아닌 소수일 수 있나? 굳이 스트링을 붙여야하나? 내가 무의식적으로 여러 번 붙였던 것들을 지적해준 느낌이 들었다.
검색가능한 네이밍을 사용하기
사용되는 범위가 넓을 수록 네이밍의 길이를 길게하라고 한다. 이 부분은 시원함을 느꼈다. 회사 프로젝트처럼 프로젝트가 큰 경우 거의 대부분을 검색으로 작업이 시작되기 때문이다.
앞에 이상한거 붙이지 말기
m_dsc = name; IShapeFactory 와 같이 앞에 나중에 보면 기억도 안날 이상한 접두사라던가, 인터페이스라고 저런거 갖다 붙이지 말아라.
클래스명
Manager, Processor,Data, Info 이런 거 붙이지 말고 동사로 만들지 말아라. 메소드는 동사로.
같은 범위에서는 컨셉당 하나로 통일하기
get, fetch, retrieve 이런 것들 같은 범위에서 쓰면 헷갈리겠다.
함수
함수는 한 모니터 단위를 넘어가지 않게. 작게 유지하기. 한 함수는 하나의 하나의 일만 하기. 인자 수는 작게. try catch 문은 더러(?)워지기 마련이니 따로 빼고, 중복 및 indent 가 많아지는 것은 문제가 있다는 뜻임.
주석
주석은 어떻게, 어떤 경우에 달아야한다라기 보다는 주석은 달지 않되 예외적인 경우에 남기도록하고 허용되는 예외를 학습하는게 중요하다고 느꼈다. 좋은 코드란 주석없이 이해가 가도록해야하며 그렇지 못할 경우에 주석이 덕지덕지 달리게 된다.
