20150825 클린 코드 특강

2015-09-06

NHN NEXT 2015년 2학기 Web Programming 수업 중 외부 특강이 있었다. 지난 8월 25일 화요일엔, 네이버 Labs에서 yobi 시스템을 개발하신 채수원 님께 클린코드 강의를 들었다. 다음은 들으면서 내가 정리한 것들이다.

Why clean code?

  • 소프트웨어 개발비용 = 개발비용 + 유지비용 (유지비용이 더 크게 되어있다.)
  • 유지비용 = 이해 비용 + 수정 비용 + 테스트 비용 + 설치 비용: 사람에 의지하고 있다.

따라서 사람이 얼마나 이해할 수 있느냐에 따라 유지비용이 달라진다. 클린코드를 작성하는 이유는 단순 심리적인 이유가 아니라 경제적인 이유이다.

왜 클린코드를 짜기 어려울까?

  • 시간이 들어. 변수 이름, 메소드 이름도 고민하면서 짜야하지. 하지만 과연 시간 때문일까요?
  • 어떻게 그 코드로 가는지 과정을 본 적이 없고, 과정을 알아도 그 과정대로 연습을 하지 않았기 때문!
    => 과정에는 지식도 필요. 필요한 지식은 다음과 같다 - 클린코드, 리팩토링, 테스트, 디자인패턴
    => 연습하기 위해서는 코드리뷰 / 짝 프로그래밍이 유용하다.

그렇다면 클린코드란?

  • 사람을 위한 코드. 보편적인, 평균적인 이해하기 쉬움…
  • 읽는 그대로 로직이 등장하도록 하는 것이 클린코드이다.
  • 분해해서 병합하는 과정이 필요 없도록.

질문. 어느정도로 클린코드를 짜야 하는 건가? 성능을 생각하면서 클린코드를 짜는 것이 힘들다..

느릴 거라고 생각하는 부분이 느리지 않을 수 있다. 10번 도는 거랑 20000번 도는 건 같을 수 있다. 예측할 수 없다. 성능 튜닝에 대한 강박을 없애라!

크눅스는 말했다.
1) 제발 튜닝좀 하지마. 2) 개발하는 동안에

개발자들 사이에 이런 미신이 있다. “아낄 때 미리 아껴놓아야지.” VM 세대에서는 이게 다 깨진다. 튜닝은 나중에 하는 거다. 개발 중간엔 todo만 써둔다. like this - “나중에 성능체크 해볼 것”
클린코들 짤 때엔 읽기 쉽고 이해하기 쉽게에만 집중하는 게 좋다.

마틴 파울러의 리팩토링!!!

  • 리팩토링의 필수 3대 요소
    • 문제가 뭔지 이해하기
    • 문제를 어떻게 해결할 지 리팩토링 기법들
    • 테스트 코드

###질문. 한번만 쓰이는 메소드를 만들 필요가 있는가? 메소드가 많아진다는 것은 이해해야할 것이 많아진다는 뜻이잖아요…

어휘는 많이 사용해도 상관 없다. 충분히 뽑아도 된다. private 메소드. 용도 자체가 어휘로 쓰라는 것이다. public과 private으로 나누는 기준은 public은 외부로 노출되는 인터페이스이고, private은 내부적으로 사용하는 어휘일 뿐이다. 그래서 public은 public대로, private은 private대로 네이밍이 중요하게 된다. public, private 나누는 기준. public은 다른 사람이 들어와서 이 코드를 볼 가능성이 있음 - 최대한 깨끗하게 작성할 필요 있음. private은 다른사람이 이름만보고도 이해할 수 있을 정도의 메소드 - 그 안에 응축된 알고리즘이 들어가 있을 수 있다.

###질문. private 메소드는 테스트를 못하는데, 테스트와 private 메소드를 어떤 식으로 균형을 맞춰야 하나요?

private 메소드는 테스트 안해도 괜찮다. public method를 테스트함으로 테스트 다 된다. 근데 불안한 맘이 계속 드는건? private 메소드의 덩치가 커지는 경우! private를 테스트하는 툴도 있다. 또, private 메소드는 디딤돌같은 것이기 때문에 public으로 만들고 테스트를 한 뒤에 ignore를 해도 된다.

뛰어난 엔지니어를 결정짓는 요소는?

  • 결정해야하는 상황에서 좀 더 적절한 솔루션(정답은 없을 수도 있고 정답이 아닐 수 있다)을 확률적으로 잘 찾아내는 엔지니어.
  • 밸런싱을 잘 하는 엔지니어다!
  • 실패의 경험을 많이 쌓고, 그리고 그 실패의 경험으로 얼마나 교훈을 남길 수 있느냐. - 내재화시킬 수 있는가.
  • “나만의 실패 스토리”가 필요하겠구나..

코드 리뷰

  • 클린 코드를 짤 수 있는 효율적인 방법중 하나이다!
  • 시니어 엔지니어로 갈 수록 중요한 role은…. code review!

truck number?

  • 이것을 이해하고 이어서 짤 수 있는 사람의 수
  • 이상적으로는 whole team이겠지.

코드리뷰 진행 방식

  • 장기적으론 온라인으로 하는 것이 좋다.
  • 오프라인으로 하면 온라인으로 미리 봐놓구 모여서 논의한다.
  • pre-code commit..
  • 코드를 사람과 일치시켜서 얘기하지 않는다. (표현에 유의하기)
  • 상대의 지적을 비난으로 생각하지 않는다.
  • 리뷰시간이 논쟁으로 시간을 소모하지 않도록 주의한다. (마음 속의 카운터를 세지 말어라. 차라리 얘기를 하고 풀자.) => 우리는 한 팀으로 좋은 소프트웨어를 만드는 것이 가장 큰 목표이다. 이것만 잘 세우자!
  • 진행자를 선정 후에 타임박스를 놓고 진행! - 끝나기 10분 정도는 회고시간 about 코드 리뷰.

코드리뷰 후 결과 남기기

  • 딱 두가지 남기자:
    • for newbie 항목 (예를 들어 팀 내 정한 룰)
    • for required 항목 (반드시 알아야할 항목) 온라인 어딘가에 두고 어디서든 볼 수 있게 하면 충분!

결론

맞다. 클린 코드하기.. 어렵다. 현장에 가면 타협에 대한 싸움이 매일 있을 것이다. 지금 클린코드 짜지 않는 개발자들이 클린코드를 몰라서 짜지 않을까? 그들도 다 알면서, 하루가 지나고, 1년이 지나고 그렇게 10년이 지난 것이다. 그러니 당장…

  1. 한다!
  2. 목적은? - 버그찾기? 코드 지적? no. 배우고 가르쳐주는 시간.
  3. 유의사항 - 열린 마음!!