감상문

Clean Code

ihl 2023. 5. 5. 16:17

스터디: https://github.com/lghihl/CleanCode-Archetecture

 

  작년에 클린코드 스터디를 진행했었다. 블로그에도 몇 가지 인상 깊었던 부분을 기록해보고자 한다.

 

  코드란 요구사항을 상세히 표현하는 수단이며, 프로그래밍은 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이다. 코드의 추상화 수준이 높아지면서 프로그래머가 작성하는 코드 수가 줄어들 수는 있겠지만 코드 자체가 사라지지는 않을 것이다.

 

  좋은 코드란 어떤 것일까? 사람마다 생각하는 기준이 다를 수 있지만 책에서 몇 가지 기준을 유명인의 말을 인용하여 제시하고 있다.

 

좋은 코드 조건

  • 읽기 쉽다.
  • 다른 사람이 고치기 쉽다.
  • 추측이 아닌 사실에 기반한다.
  • 시스템 내 모든 설계 아이디어를 표현한다.
  • 의미있는 이름을 쓴다.
  • 세세한 사항까지 꼼꼼히 신경썼고, 효율적이다.
  • 테스트 케이스가 있다.

  우리의 코드는 왜 나쁜 코드가 될까? 이 부분은 클린코드 뿐만 아니라, 클린 아키텍처 첫 장에서도 나오는 부분인데 "개발자가 전문가 답지 못했기 때문"이다. 좋은 코드, 좋은 구조를 사수하는 것은 프로그래머의 책임이다. 업무 관리자는 보통 좋은 코드/구조의 중요성을 평가할만한 능력을 갖추지 못했기 때문에 개발자를 고용하는 것이기 때문이다. 일반적으로 당장 시장에 출시하는 것이 먼저라는 말로 구조를 신경쓰지 않고 뼈빠지게 일하게 된다. 그러나 이는 개발자가 자신의 생산성을 유지할 수 있다고 착각하는 것이며, 시장의 압박은 결코 수그러지지 않아 결국 생산성이 0에 수렴하게 된다.

 

  시스템이란 구현할 프로그램이 아닌, 풀어가야할 이야기에 가깝다. 이야기를 쉽게 풀기 위해선 각 구성요소가 정확한 언어로 깔끔하게 맞아 떨어져야 한다. 즉, 일관성이 있어야 한다. 이를 이해한다면 프로그래밍을 하며 어떤 이름을 써야할지, 함수를 어떻게 써야할지 판단할 수 있다.

 

이름 짓는 기준

  • 의도가 분명함
    • 널리 쓰이는 의미가 있는 단어를 다른 의미로 사용하지 않는다.
    • 흡사한 일므을 사용하지 않는다.
    • 일관된 표기법을 사용한다.
    • 의미있게 구분할 것 ex. var1, var2 X
  • 검색하기 쉬움
  • 발음하기 쉬움
  • 한 개념에 한 단어 사용
    • fetch, get, reqeust, retrieve... 를 혼용하지 않는다.
    • 같은 코드 기반에 controller, manager, driver 등을 섞어 쓰지 않는다.
  • 한 단어에 2가지 목적을 사용하지 않음
  • 해법 영역에서 가져온 이름 사용
    • 전산용어, 알고리즘, 패턴, 수학 용어 등을 사용
    • 기술 개념에는 기술 이름을 적용
    • 적절한 용어가 없다면, 도메인 영역에서 단어를 가져올 것
  • 의미있는 맥락을 추가
    • 불필요한 맥락은 제거한다. ex. m_ 같은 불필요한 인코딩은 제거한다.

 

함수 작성 기준

  • 함수 크기는 짧을 수록 좋고, 중첩 구조는 지양한다.
  • 하나의 함수는 추상화 수준이 하나인 단계만 수행해야한다. 
  • 함수의 인수도 적을 수록 좋다.
  • 플래그 인수, Switch 등은 필연적으로 N가지 일을 한다. 다형성을 이용하여 해결하자
  • 부수효과를 일으키지 않는다.
  • 중복을 지양한다.

  책을 읽고, 다른 자료를 찾아 공부하면서 내가 아직 애자일과 TDD, 추상화에 대해 100%는 이해하지 못하고 있는 것 같다는 생각이 들었다. 책을 읽고나니, 많은 개발 조직들의 애자일 개발은 근본적으로 폭포수와 다를 바가 없다는 생각이 든다. 그렇다고 뭔가 애자일에 대해 깨달음을 얻은 것은 아니고 내가 생각했던 애자일이 그게 아니구나 라는 생각이 들었고 진짜 애자일을 경험해보고싶다는 생각이 들었다. 

 

  이 책에서 배우는 가장 중요한 부분은 좋은 코드의 조건을 구체적으로 알아가는 것 이라 생각한다. 누구나 좋은 코드를 만들고 싶고, 좋은 이름을 짓기위해 고민한다. 그러나 어떤 코드가 좋은지 어렴풋이 아는 것이 아니라, 구체적으로 자신만의 기준을 만들어나가는 것이 본인의 업무를 수행하고 커뮤니케이션하는데 굉장히 중요하다. 이런 의미에서 클린 코드라는 책은 나만의 좋은 코드 기준을 더 구체화할 수 있어서 좋은 책인 것 같다.