ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 클린코드 - 더 좋은 코드란?
    여러가지/book 2018. 7. 20. 10:23

    Clean Code - 로버트 C. 마틴


    장인 정신을 익히는 과정은 두 단계로 나뉜다. 바로 이론과 실전. 첫째, 장인에게 필요한 원칙, 패턴, 기법, 경험이라는 지식을 습득해야 한다.
    둘째, 열심히 일하고 연습해 지식을 몸과 마음으로 체득해야 한다.

    깨끗한 코드를 작성하는 방법은 배우기 어렵다. 단순히 원칙과 패턴을 안다고 깨끗한 코드가 나오지 않는다. 고생해야한다. 스스로 연습하고 실패도 맛봐야 한다. 남들이 시도하다 실패하는 모습도 봐야 한다. 그들이 넘어지고 일어서는 모습도 봐야 한다. 결정을 내리느라 고민하는 모습, 잘못된 결정으로 대가를 치르는 모습도 봐야한다.

    Clean Code

    코드가 존재하리라

    코드는 요구사항을 상세히 표현하는 수단 - 기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업, 바로 이것이 프로그래밍이다.

    나쁜 코드

    우리 모두는 자신이 짠 쓰레기 코드를 쳐다보며 나중에 손보겠다고 생각한 경험이 있다. 우리 모두는 대충 짠 프로그램이 돌아간다는 사실에 안도감을 느끼며 그래도 안돌아가는 프로그램보다 돌아가는 쓰레기가 좋다고 스스로를 위로한 경험이 있다. 다시 돌아와 나중에 정리하겠다고 다짐했었다. 물론 그때 그 시절 우리는 르블랑의 법칙을 몰랐다. 나중은 결코 오지 않는다.

    나쁜 코드로 치르는 대가

    매번 얽히고설킨 코드를 '해독'해서 얽히고 설킨 코드를 더한다. 시간이 지나면 쓰레기 더미는 점점 높아지고 깊어지고 커진다. 청소할 방법이 없다. 불가항력이다.

    아 오늘 겪은 일이다. 3개월 전 짠 코드를 리펙토링하며 나름대로 최대한 코드를 짜봤지만, 설계를 그대로 유지한체 짜다가 문득 이건 아니다 싶어 멈췄었다. 그렇다 내가 만들고 있던건 괴물이었다.

    태도

    좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

    원초적 난제

    기한을 맞추는 유일한 방법은, 그러니까 빨리 가는 유일한 방법은, 언제나 코드를 최대한 깨끗하게 유지하는 습관이다.

    깨끗한 코드라는 예술?

    깨끗한 코드와 나쁜 코드를 구분할 줄 안다고 깨끗한 코드를 작성할 줄 안다는 뜻은 아니다. 깨끗한 코드를 작성하려면 '청결'이라는 힘겹게 습득한 감각을 활용해 자잘한 기법들을 적용하는 절제와 규율이 필요하다. 코드감각

    깨끗한 코드란?

    • 보기 즐거운 코드
    • 의존성을 최대한 줄여야 유지보수가 쉬워진다. // 내가 만든 괴물은 이거 때문에 탄생하고 있었다.
    • 세세한 사항까지 꼼꼼하게 처리하는 코드.
    • 한가지만 집중.
    • 가독성
    • 명쾌한 추상화
    • 작성자가 아닌 사람도 읽기 쉽고 고치기 쉽다.
    • 중복이 없다.

    고로

    1. 중복을 피하라.
    2. 한 기능만 수행하라.
    3. 제대로 표현하라.
    4. 작게 추상화하라.

    우리는 저자다.

    우리는 코드를 읽는 시간 대 코드를 짜는 시간 비율이 10 대 1을 훌쩍 넘는다. 새 코드를 짜면서 우리는 끊임없이 기존 코드를 읽는다. (...) 주변 코드가 읽기 쉬우면 새 코드를 짜기도 쉽다.

    보이스카우트 규칙

    캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라.

    • 변수 이름 하나를 개선
    • 조금 긴 함수 하나를 분할
    • 약간의 중복 제거
    • 복잡한 if문 하나를 정리

    이 작은 개선이 좋은 코드를 만든다.




    최근 내가 짜고 있는 코드가 그냥 돌아가기만 하는 쓰레기이지 않을까 라는 고민이 많이 들었었다. 물론 그럴 수 밖에 없는게 난 코드를 짜기 시작한지 6개월 밖에 안됐다. 일주일 전에 짠 코드는 신 만이 아는 코드이다. 라고 하지 않는가? 그런데 내가 지금 리펙토링 중인 코드는 무려 3개월 전 코드이다. 3개월된 초보가 짠 코드를 6개월 된 초보인 내가 보고 있으니 얼마나 가관이겠는가?

    • 너무나 높은 의존성.
    • 똑같은 구조에 이름만 다른 함수.
    • 스네이크 케이스와 카멜케이스가 동시에 등장하는 변수명.

    지금 내가 마주하고 있는 코드들이다.


    어디서 들은건 있어서 여러가지 기교를 부리며 리펙토링 하는 중에 갑자기 코드를 보는데 내가 짜고 있는 코드가 괴물이 되어가는 걸 느꼈다. 중복을 줄이기 위해 덕지덕지 예외처리를 하며 억지로 합쳐놓은 코드, 함수를 작게 만들어야 된다는 말에 밑도 끝도 없이 잘라낸 함수들, 그리고 함수가 늘어나다 보니 더 높아진 의존성, 이 의존성을 께트리기위해 사용되는 전역변수들.


    이건 아니다란 생각에 지금까지 작업하던 것을 멈추고 내가 짤려는 로직이 무엇인지 처음부터 다시 생각했다.


    그리고 더 좋은 코드를 쓰고 싶다는 마음에 이 클린 코드를 구매하게 되었고. 오늘 배송이 와서 앞부분만 조금 읽어 보았다.


    이 인트로는 개인적으로 성경의 창세기와 맞먹는 임펙트를 내게 주었다. 내가 겪었던, 그리고 앞으로 겪을 문제들을 명확하게 정의 해주는 구절들의 향연이었다. 나에겐 이런 것들이 필요했다.

    문제는 내가 지금 다룰 수 있는 코드는 JS와 파이썬 밖에 없는데 예제 코드가 자바이다.

    읽다보면, 해답이 나오지 않을까?

Designed by Tistory.