본능에 의해 코딩하는 것을 멈추라

최근 켄트벡의 구현패턴을 읽고 가장 뜨금 했던 문구입니다. 완성을 목표로만 달려왔던 저는 정말 큰 충격이었습니다. 그래서 이와 관련된 내용을 찾아보고 한번 정리를 해봤습니다.

일단, 좋은 프로그래머가 되려면 “돌아가기만 하면 되지” 라는 마인드를 가지면 안 됩니다. 타인과의 커뮤니케이션을 중시하고 코드의 과도한 복잡성을 피하면서도 유연성 있는 코드를 작성해야 합니다.

그 이유는 경제성 때문입니다. 소프트웨어 비용은 아래와 같습니다.

전체 비용 = 개발 비용 + 유지 비용
유지 비용 = 이해 비용 + 수정 비용 + 테스트 비용 + 설치 비용

초기 개발 비용보다 유지 비용이 더 많이 들기 때문에 우리는 모든 프로그래머가 커뮤니케이션하기 쉬운 코드를 짜서 유지 비용을 줄이려고 노력해야 합니다.

그런데 여기서 중요한 것은 아무리 좋은 코드가 남겨져 있어도 이해를 못 해서도 안됩니다. 상대방 코드의 해석과 의도를 이해하지 못한다면 오히려 버그로 오해할 수도 있습니다.

이해하기 쉽게 코드를 짜야 되며 우리는 그 코드를 이해할 수 있어야 합니다.

이해하기 쉬우려면 일단 코드 양이 적어야 합니다. 그리고 그 코드로 개발자 간의 커뮤니케이션이 가능해야 하고 단순하면서도 유연성이 좋아야 합니다. 그러기 위해서는 몇 가지 원칙이 필요하게 되는데 ‘켄트벡의 구현패턴’에서는 아래와 같은 원칙을 알려줍니다.

  • 지역적 변화와 최소 중복의 원칙
    • 코드를 수정할 때 함께 바꿔야 하는 부분을 최소화해야 한다.
    • 짧은 구문, 짧은 메소드, 작은 객체, 작은 패키지로 나누는 작업
  • 로직과 데이터의 결합
    • 로직과 데이터를 모두 수정해야 할 경우가 많으므로, 데이터와 그 데이터를 처리하는 로직을 밀접하게 배치 한다.
  • 대칭성
    • 하나의 아이디어를 프로그램 전체에서 일관된 방식으로 표현하는 통일성이 있어야 한다.
  • 선언적 표현
    • 복잡한 로직이 없다면 수행되는 로직을 선언적 표현을 사용해야 한다. 선언적으로 표현을 잘 하면 예외적인 경우를 생각할 시간을 줄여줍니다.
  • 변화율
    • 변하는 로직과 데이터를 함께 관리하고 변화율이 다른 로직과 데이터는 분리해야 한다.



처음에 이 내용을 봤을 때는 그냥 그렇구나 하고 지나쳤었는데 최근에 다시 읽었을 때는 엄청나게 중요한 내용이었다는 것을 알게 되었습니다. 혼자 작업하는 코드라고 해도 미래의 나는 지금 현재 나의 의도를 모를 수도 있습니다. 그래서 항상 의식하면서 변화율에 신경을 많이 쓰기로 했습니다. 물론 책에서 알려주는 내용이 완벽한 정답이라고 할 수는 없지만 저는 경험을 통해서 책에서 제시한 내용에 완전히 공감하게 되었습니다. 그래서 이와 관련된 내용을 좀 더 찾아봐야겠다는 생각이 들었고 탁월한 프론트엔드 엔지니어가 되는 법과 좋은 코딩을 위한 13가지 규칙을 읽고 한번 정리를 해보았습니다.


1. 문제를 해결하는데 그치지 말고 어떻게 동작하는지 파악하라.
지금 당장의 문제를 해결하려고 하지 말고 문제의 원인을 이해하고 근본적인 문제를 찾아 해결을 해야합니다. 그렇게 하지 않는다면 그와 관련된 같은 문제를 또 마주하게 될 수도 있습니다.

2. 명세(Spec)와 코드를 읽어라.
저의 경우 어떤 라이브러리를 사용했을 때 사용법과 Example 만 보고 “잘 되네?” 하고 넘겼습니다. 하지만 명세를 보면서 이해하고 스스로 능력을 기르고 해당 기술이 어떻게 동작할 수 있는지 생각하게 되면 그 기술의 주류이거나 심지어는 해당 기술의 발전에 기여할 수도 있습니다.

3. 있는 걸 다시 만들고 배운 것들을 기록해라.
위의 내용들을 실천하기 가장 좋은 방법은 좋은 라이브러리를 내가 직접 만들어 보는 것입니다. 제가 지금 가장 중요시 생각하고 있는 부분이기도 하고 저 또한 이 글을 읽자마자 시작했습니다. 그리고 우리가 흔히 알고 있는 교과서적인 문법만이 아니라 그 라이브러리의 사상과 아이디어, 패턴 등을 배울 수 있는 아주 좋은 기회라고 생각합니다.

4. 리펙토링 시간은 따로 주어지지 않는다.
예를 들어 “이번에 테스트 용도로 이거 하나 만들어 줘~ 한 번만 사용하고 안 쓸 꺼니깐 빨리 만들어줘~” 이런 말을 듣고 일단 대충 빨리 만들어서 업무를 끝마쳤을 때 6개월 뒤 “저번에 만든 거 반응이 좋아서 조금만 내용 다듬어서 정식적으로 내보내야 할 것 같아.” 이렇게 요청이 올 수도 있습니다. 물론 정말 한번만 쓸 수도 있지만 이런 상황이 생겼을 때 일 마무리를 잘 못 하게 되면 개발자의 책임이 생기게 됩니다. 그래서 일단 최소한의 시간 확보가 먼저입니다. 그리고 한 번만 사용한다고 하더라도 품질에 신경을 많이 써야 합니다. 정말 한 번만 사용할 수도 있지만, 개인 역량을 위해서라도 또는 미래의 나, 동료를 위해서라도 리펙토링에 신경을 많이 써야 합니다.

5. 최적화 vs 가독성.
데이터를 가공하는 로직에서 데이터를 find 하는 함수와 filter 를 하는 함수를 사용하는 코드를 보고 “그냥 for 문 하나로 처리하면 성능이 더 좋지 않을까?” 라는 생각을 할 수도 있습니다. 하지만 앞에서도 여러 번 이야기했던 것처럼 읽기 쉬운 코드가 우선입니다. 그 이유는 최적화시키는 것보다 코드를 읽는 시간과 자원이 더 많이 들기 때문입니다.

Reference