Skip to main content

김시용

1. 📌 핵심 개념 정리

✅ 요약하기

각자 해당 챕터에서 중요하다고 느낀 개념이나 아이디어를 간략하게 정리하고 개선 전, 후에 대한 예시 코드를 비교하며 개념을 설명합니다.

  1. 나쁜 코드
    • 제대로 짤 시간이 없다고 생각해서, 코드를 다듬느라 오랜 시간이 걸릴까봐 등의 핑계로 대충 짠 코드
    • 초반에는 생산성이 높지만, 후반부로 갈수록 생산성이 0에 수렴하게 됨
    • 관리자, 고객보단 전적으로 프로그래머의 잘못 (환자가 의사한테 손을 씻지 않고 수술하라 요청했어도 질병과 감염의 위험은 환자보다 의사가 더 잘 아니까 환자 말을 그대로 따르는 행동은 전문가 답지 못하기 때문)
  1. 좋은 코드
    • 간단하게, 읽시 쉬운 코드를 뜻함
    • 자세하게, 중복 줄이기, 한 기능만 수행, 표현력 높이기, 초반 간단한 추상화 고려하기
    • 자신이 저자라 생각하고 코드 짜기 (독자들을 생각하며 코드 짜기)

2. 🤔 이해가 어려운 부분

🔍 질문하기

책을 읽으며 이해하기 어려웠던 개념이나 명확하지 않았던 내용을 정리합니다.

  1. 론 제프리스의 클린 코드

    • 어려웠던 부분
      초반 부터 간단한 추상화 고려하기 부분

    • 궁금한 점
      해당 방법의 장점들과 실제 자세한 예시가 궁금함 (chatGPT 통해 물어보기)

    • 궁금증에 대해 찾아본 결과

      인터페이스 기반 개발(Interface-Based Development) 또는 "프로토타이핑 후 점진적 개선" 방식과 관련

      1. 코드의 유연성을 유지
        • 특정 기능이 완벽하게 구현되지 않아도, 외부 코드가 해당 기능을 사용할 수 있도록 인터페이스 또는 추상 클래스를 제공할 수 있습니다.
        • 이후 세부 구현을 변경해도, 이를 사용하는 코드에는 영향을 주지 않습니다.
      2. 일관된 설계 방향 유지
        • 추상화를 먼저 정의하면 팀원들이 기능의 목표와 사용 방식을 이해하기 쉽습니다.
        • 추상화된 메서드를 먼저 사용하면, 구현이 없더라도 코드가 어떻게 동작할지를 미리 예상할 수 있습니다.
      3. TDD(Test-Driven Development)와 잘 맞음
        • 먼저 인터페이스/추상 클래스를 작성하고, 목(Mock) 객체를 만들어 테스트 가능한 구조를 만듭니다.
        • 실제 구현이 없어도, 시스템이 전체적으로 어떻게 동작할지 미리 테스트할 수 있습니다.

3. 📚 참고 사항

  • SOLID 원칙 : 다양한 설계 원칙 중 하나 먼저 살펴보기
    • SRP : 각 클래스가 하나의 역할만 담당하도록 분리하여 유지보수가 쉬워진다.
    • OCP : 확장에는 열려 있고, 수정에는 닫혀 있어야 한다.
    • LSP : 자식 클래스는 부모 클래스로 대체할 수 있어야 한다.
    • DIP : 상위 모듈은 하위 모듈에 의존하면 안 된다. 즉, 인터페이스 또는 추상 클래스에 의존해야 한다.
    • ISP : 클래스가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다. 즉, 인터페이스를 세분화하여 특정 클라이언트가 필요하지 않은 기능을 강제로 구현하지 않토록 해야 한다.

📢 논의하기

관련된 자료가 있다면 공유하고, 더 깊이 논의하고 싶은 아이디어나 의견을 정리합니다.

  1. 관련 자료 공유
    • 추가 자료
      관련 블로그 글이나 공식 문서 링크를 제공합니다.
  1. 논의하고 싶은 주제
    • 주제
      논의하고 싶은 내용을 간략히 정리합니다.
    • 설명
      논의하고 싶은 이유를 작성합니다.
Back to top