목록으로
'언젠가 읽기' 컨텐츠는 논문이나 영문 컨텐츠 등 언젠가 읽으려고 즐겨찾기 하고선 읽지 않고 계속 미룰만한 컨텐츠를 읽고 요약하거나 소개합니다.

aposd-대-클린-코드/README.md at main · johnousterhout/aposd-대-클린-코드

개요

  • 대화 개요
    이 문서는 소프트웨어 디자인에 관한 두 전문가, John Ousterhout와 Robert “Uncle Bob” Martin 간의 심도 있는 토론을 정리한 것이다. 주요 주제는 메소드 길이, 주석 작성 방식, 그리고 테스트 주도 개발(TDD)에 관한 것이다. 두 사람은 공통의 가치(모듈성, 유지보수성)를 인정하면서도, 접근 방식과 우선순위에서 크게 다르다는 점을 보여준다.

메소드 길이

  • 분해의 장단점
    • John은 메소드를 너무 작게 분해하면 인터페이스가 단순해지는 대신, 코드의 전체 구조를 이해하기 위해 서로 연관된 여러 작은 메소드를 동시에 기억해야 하는 “얕은” 인터페이스와 결합 문제가 발생할 수 있다고 주장한다.
    • Bob은 가능한 한 짧고 명확한 메소드를 선호하며, 작은 단위로 분리함으로써 개발자가 한 번에 기억해야 할 정보를 줄일 수 있다고 본다. 그러나 이는 때때로 메소드 간의 결합과 의존성을 초래할 수 있다.
  • 예시: PrimeGenerator
    • 예제 코드를 통해 너무 세세하게 분리된 메소드가 오히려 이해를 어렵게 만들고, 호출 관계와 부수 효과(side effect)를 파악하기 힘들게 된다는 점이 논의되었다.

주석

  • 주석의 필요성 vs. 코드 자체의 명료성
    • John은 복잡한 알고리즘과 비직관적인 설계 결정을 독자가 쉽게 이해할 수 있도록 주석이 필수적이라고 주장한다. 주석은 코드만으로는 전달하기 어려운 “왜”와 “어떻게”의 정보를 제공한다.
    • Bob은 긴 메소드 이름이 주석의 역할을 대신할 수 있다고 보며, 주석은 종종 신뢰할 수 없고 유지보수에 어려움을 줄 수 있다고 우려한다. 다만, 복잡한 알고리즘에서는 주석이 도움이 될 수 있다는 점도 인정한다.
  • 주요 논쟁점
    • 인터페이스를 설명할 때는 주석과 메소드 이름의 적절한 균형이 필요하며, 지나치게 장황한 주석은 오히려 혼란을 야기할 수 있다.
    • 코드에 내재된 의도와 설계 결정을 외부에 명확히 드러내기 위해, 중요한 부분에는 주석이 반드시 필요하다는 점이 강조되었다.

테스트 주도 개발 (TDD)

  • TDD의 장점
    • Bob은 TDD가 짧은 개발 사이클을 통해 초기 버그를 빠르게 발견하고, 낮은 수준의 문서 역할을 하는 단위 테스트를 제공하며, 모듈 간 결합도를 낮춰 두는 효과가 있다고 본다.
    • 또한, TDD를 통해 지속적인 리팩토링이 가능해져, 코드의 유지보수성과 신뢰성이 높아진다고 주장한다.
  • TDD의 단점
    • John은 TDD가 개발자를 너무 전술적인 관점에 머물게 하여, 전체적인 설계 관점을 간과하게 만들고, 처음 작성된 “잘못된 코드”가 점차 누적되어 나쁜 디자인으로 이어질 위험이 있다고 본다.
    • TDD의 “테스트 통과에만 집중”하는 방식은 장기적으로 시스템의 복잡성을 높이고, 전체적인 설계 품질에 악영향을 줄 수 있다는 우려를 표명한다.
  • 비교: Bundling 접근법
    • John은 TDD 대신, 기능 단위(메소드나 클래스)별로 코드를 작성한 후 단위 테스트를 추가하는 “번들링” 방식을 선호한다. 이 방식은 전체 설계에 대한 고민을 먼저 하도록 유도해, 불필요한 전술적 코드 작성을 줄일 수 있다고 본다.
    • 두 접근법 모두 올바른 리팩토링과 디자인 사고가 동반된다면 비슷한 결과를 낼 수 있지만, 평균 및 최악의 경우 결과에서 TDD의 위험이 더 크게 나타날 수 있다고 주장한다.

종합 결론

  • 디자인 균형의 중요성
    • 두 전문가 모두 모듈성, 코드 가독성, 그리고 유지보수의 중요성을 인정하지만, 지나치게 세분화하거나 주석을 극단적으로 줄이는 등 한쪽으로 치우친 접근은 오히려 문제를 야기할 수 있다는 데 의견이 모인다.
  • 핵심 메시지
    • 좋은 소프트웨어 디자인은 메소드 분해, 주석 작성, 그리고 테스트 전략 사이의 적절한 균형에 달려 있다.
    • 설계의 근본적인 목표는 개발자가 코드를 쉽게 이해하고 변경할 수 있도록 정보를 명확하게 전달하는 것이다.
    • 최종적으로, 각 방법론은 개발자의 경험과 팀의 문화에 따라 그 효과가 달라질 수 있으며, 어느 한쪽만을 맹신하기보다는 상황에 맞게 균형 잡힌 접근이 필요하다.

함께 읽으면 좋은 참고 자료

  • Clean Code
  • A Philosophy of Software Design
  • Literate Programming

[출처] aposd-vs-clean-code/README.md at main · johnousterhout/aposd-vs-clean-code