16. 설계를 방해하는 개발 프로세스와의 싸움

내용


커뮤니케이션

  • 콘웨이 법칙

    • 시스템의 구조는 그것을 설계하는 조직의 구조를 닮아 간다.

    • 커뮤니케이션 비용 구조의 법칙

      • 팀 내부에서 이뤄지는 커뮤니케이션은 비용이 낮고, 팀 외부와의 커뮤니케이션 비용이 높다는 비용구조 자체가 시스템 구조에 영향을 준다.

      • 즉 팀원 간 커뮤니테이션 문제는 팀원 간 커뮤니케이션 비용이 높다.

  • 역콘웨이 법칙

    • 소프트웨어 구조를 먼저 설계하고, 이 후 소프트웨어 구조에 맞게 조직을 편성한다.

  • 심리적 안정성

    • 어떤 발언을 했을 때, 부끄럽거나 거절당하지 않을 것이라는 확신을 느낄 수 있는 심리상태

설계

  • '일단 어떻게든 움직이는 코드를 빨리 작성하는 것이 좋다' 는 아닐수도

    • TDD로 하는 것이 더 빨리 개발지 완료된다는 비교 실험도 있음.

  • 클래스 다이어 그램을 그려보자

    • 클래스 설계 <-> 구현 피드백 사이클을 돌리기 위해

  • 한번에 완벽하게 설계하려 하지 말자

  • 클래스를 작게 나누면, 인스턴스 생성 비용이 발생해서, 성능이 떨어질 수는 있음.

    • 그렇지만 무시할 수 있을 정도

    • 하드웨어, 소프트웨어 성능이 지속적으로 향상되고 있으므로 인스턴스 생성 비용이 상대적으로 낮아지고 있음.

  • 설계 규칙을 다수결로 결정하면 코드 품질이 떨어짐

    • 일반적으로 결과가 좋지 않다.

    • 그럼 잘 아는 사람이 잡아주면 좋을듯

  • 설계 규칙을 정할때 중요한 점.

    • 설계 규칙에는 이유와, 의도를 적는것이 좋다.

      • '같은 조건 분기가 여러 개 구현되면 인터페이스 설계를 검토한다' -> 수정 누락의 가능성이 높아진다.

구현

  • 깨진 유리창 이론

  • 기존 코드를 믿지 말고, 냉정하게 파악하기

    • 아무 의심 없이 코드를 받아들이지 말자

리뷰

  • 코드 리뷰 구조화 하기

  • 코드를 설계 시점에 리뷰하기

  • 존중과 예의

    • 기술적 올바름, 유용성보다는 함께 일하는 동료를 존중하는 것이 먼저

해야하는 것

![[Pasted image 20250601165832.png]]

하지 말아야 하는 것 ![[Pasted image 20250601165913.png]]

  • 정기적으로 개선 작업 진행하기

    • 좋지 못한 코드, 나중에 하자, 이 부분 issue화 해서 관리하자

팀의 설계 능력 높이기

정리


  • 심리적 안정성

    • 어떤 발언을 했을 때, 부끄럽거나 거절당하지 않을 것이라는 확신을 느낄 수 있는 심리상태

  • '일단 어떻게든 움직이는 코드를 빨리 작성하는 것이 좋다' 는 아닐수도

    • TDD로 하는 것이 더 빨리 개발지 완료된다는 비교 실험도 있음.

  • 설계 규칙을 다수결로 결정하면 코드 품질이 떨어짐

    • 일반적으로 결과가 좋지 않다.

    • 그럼 잘 아는 사람이 잡아주면 좋을듯

  • 기존 코드를 믿지 말고, 냉정하게 파악하기

    • 아무 의심 없이 코드를 받아들이지 말자

      • 이 코드는 무엇을 해결하고 싶은 코드일까?

      • 이 코드가 달성하려는 목적이 무엇일까?

참고


  • https://product.kyobobook.co.kr/detail/S000202521361

Last updated

Was this helpful?