좋은 코드, 나쁜 코드 (Good Code, Bad Code)

2023년 카카오 신입 공채 기술 온보딩에서 코드 리뷰어로 활동할 때 참고하려고 구매했던 도서다. 나름 신간이면서 표지가 마음에 들기도 했고, 코드 품질은 언제나 관심이 있는 주제다. 읽어보니 책의 내용도 내용이지만, 적절한 컬러 사용과 보기 편한 편집으로 가독성도 매우 좋다.

 

이 책의 특이사항으로는 일단 예제 구성하는 데 사용한 언어에 있다. 보통 하나의 언어를 정해서 실행할 수 있는 예제를 구현하는 다른 책들과 달리 의사코드를 사용하여 예제를 구성하고 있다. 저자가 자기 생각을 전개하는 방식도 책의 제목과 순서는 배치 순서는 다르지만, 저자가 생각하기에 나쁜 코드와 좋은 코드를 대비시켜서 보여주고 왜 나쁘고 좋은지를 친절하게 설명해준다. 그리고, 모든 상황에 맞는 정답은 없다는 것을 계속 상기시켜준다.

이 책에 있는 그 어떤 것도 결코 깨뜨릴 수 없는 절대적 규칙이라고 생각하거나 그렇게 적용하면 안 된다. 훌륭한 판단력은 훌륭한 공학의 필수 요소이다

 

단위 테스트를 하나의 파트로 분리하여 크게 다루고 있는데, 단위 테스트만을 다룬 책들 못지않게 좋다. 목, 스텁, 페이크를 간단명료하게 잘 설명해준다. 그리고, 단위 테스트를 구성할 때 놓치기 쉬운 적절한 어설트 함수를 사용하는 것에 대한 이야기도 좋다.

 

내부 구현 세부 사항에 종속되는 목의 사용을 지양해야 한다는 것에는 동의하지만, 단위 테스트가 가능한 한 실제 의존성을 사용해야 한다는 저자의 생각에는 동의하지 않는다. 저자는 경험상 실제 의존을 사용하는 것이 좋았다지만, 나의 경험상 단위 테스트는 개발자의 로컬 환경에서 어떤 추가 설정도 없이 독립적으로 빠르게 실행할 수 있게 구성하고, 외부 의존성을 포함한 검증은 통합 테스트에서 하는 것으로 분리해서 관리하는 것이 좋았다. 단위 테스트에서 외부의 의존성을 분리하는 도구로 스텁과 페이크는 유용하다고 생각한다.

 

https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=302206399

[전자책] 좋은 코드, 나쁜 코드

단위 테스트는 코드가 어떻게 하는지가 아니라 무엇을 하는지 테스트하는 것입니다.
...
소프트웨어 공학이 엄밀한 과학은 아니며, (우리가 그렇게 해보려고 아무리 열심히 노력하더라도) 절대적인 규칙 몇 가지로 요약할 수 없다는 점이다. 모든 프로젝트는 서로 다르며, 절충점을 찾아야 하는 사항들이 거의 모든 경우에 존재한다.
...
코드의 가독성이 떨어진다면, 다른 개발자가 그 코드를 이해하는 데 많은 시간을 들여야 한다. 또한, 코드의 기능에 대해 잘못 이해하거나 몇 가지 중요한 세부 사항을 놓칠 가능성 역시 크다.
...
코드 작성은 복잡한 문제를 계속해서 더 작은 하위 문제로 세분화하는 작업이다.
...
하위 문제에 대한 해결책이 간결한 추상화 계층으로 제시되면 해당 하위 문제에 대한 해결책을 재사용하기가 쉬워진다. 그리고 문제가 적절하게 추상적인 하위 문제로 세분화된다면, 해결책은 여러 가지 다른 상황에서 유용하게 일반화될 가능성이 크다.
...
자신에게는 분명한데 다른 사람에게는 분명하지 않을 수 있다는 것, 혹은 다른 사람들이 무의식중에 자신의 코드를 작동하지 않게 만드는 것과 관련해 살펴본 모든 내용이 어느 순간 자신에게 적용된다. 1~2년 전에 작성한 코드를 다시 들여다보는 일은 다른 사람이 작성한 코드를 보는 것과 크게 다르지 않다.
...
다른 개발자가 어떻게 코드를 해석하고 오용할 수 있을지 생각해보고, 이러한 가능성을 최소화하거나 오용이 불가능하게 만드는 방식으로 코드를 작성하는 것이 유용하다.
...
기본값의 문제점은 오류가 발생했다는 사실을 숨긴다는 것인데, 이는 코드를 호출하는 쪽에서 모든 것이 정상인 것처럼 계속 진행한다는 것을 의미한다.
...
매직값(또는 오류 코드)은 함수의 정상적인 반환 유형에 적합하지만 특별한 의미를 부여하는 값이다. 매직값이 반환될 수 있다는 것을 알려면 문서나 코드를 읽어야 한다. 따라서 이것은 암시적 오류 전달 기법이다.
...
대부분의 컴파일러는 경고를 오류로 여기고 코드가 컴파일되지 않도록 설정할 수 있다. 이렇게 하는 것이 다소 과장되고 엄격해 보일 수 있지만, 개발자들이 경고를 알아차리고 그에 따라 행동하도록 강제하기 때문에 실제로는 매우 유용하다.
...
프로그래밍 언어의 그런 새로운 기능을 사용하고 싶은 마음이 간절히 들 때, 그것이 정말로 그 일에 가장 적합한 도구인지 솔직하게 생각해봐야 한다.
...
주의할 점은 의존성 주입을 좋아하는 개발자라도 의존성 주입 프레임워크를 항상 사용하는 것은 아니라는 점이다. 주의해서 사용하지 않으면 파악하기 어려운 코드가 만들어질 수 있다. 왜냐하면 프레임워크의 어떤 설정이 코드의 어떤 부분에 적용되는지 알기 어렵기 때문이다.
...
코드를 작성할 때 필요 이상으로 성능비용과 같은 문제에 주의를 기울이는 경우가 있다. 그러나 코드에 가정이 들어가면 취약성의 측면에서도 관련 비용을 수반한다는 것을 기억하는 것이 중요하다.
...
테스트에서 의존성을 실제로 사용할 때 설정이 필요하거나 하위 수준의 의존성에서 무언가 검증을 해야 한다면 통제할 수 없는 상황이 될 수 있다. 이 경우에는 테스트 더블을 사용하는 것이 더 낫다.
...
BDD는 사람마다 조금씩 다른 의미를 가질 수 있지만 이 철학의 핵심은 사용자, 고객, 비즈니스의 관점에서 소프트웨어가 보여야 할 행동(또는 기능)을 식별하는 데 집중하는 것이다. 이런 원하는 동작은 소프트웨어가 개발될 수 있는 형식으로 포착되고 기록된다. 테스트는 소프트웨어 자체의 속성보다는 이러한 원하는 동작을 반영해야 한다.
...
좋은 단위 테스트는 궁극적으로 중요한 행동을 테스트해야 한다. 이렇게 하면 테스트는 코드의 문제점을 정확하게 감지할 가능성을 극대화하며 구현 세부 사항에 독립적으로 된다.

-알라딘 eBook <좋은 코드, 나쁜 코드> (톰 롱 지음, 차건회 옮김) 중에서