[독서] 육각형 개발자 4~7부

육각형 개발자 - 4부

일시: 2024-04-11 15:30 ~ 16:10
목차: 4부

• 읽고 든 생각
  • 리팩토링과 테스트는 빠른 구현을 해야하는 스타트업에서는 맞지 않는 느낌인가?
  • 4장: 코드 시각화 - 미로에서 프로세스를 시각화하는 것과 같은건가?
  • 113p: "응집도가 높아지면 구성요소가 역할에 따라 알맞게 분리될 가능성이 커진다." 반대 아닌가?
  • 리팩토링: 인턴이라 그런가, 기존 로직을 함부로 리팩토링하기가 걱정이 되긴 한다. 함부로 고쳤다가 문제가 생길까봐.
  • 프론트에서의 테스트는 어떤 것이 있을까? 운송 예약의 경우라면, 입력을 자동으로 넣고 예약이 됐는지 안됐는지를 테스트하면 될까?4부 - 코드이해
• 같은 용어를 사용했지만 서로 이해하는 바가 달랐다. => 우리들은 이런 상황에서 어떻게 하는가? 각자 어떤 방식을 사용하지?
  • 빅터: 용어에 대한 정확한 합의
  • 쿠키: 대화하다가 맞지 않는 부분이 있으면 바로 맞추고자 솔직하게 이야기함. 또한 이야기하는 바를 계속해서 기록하고 그림으로 그리면서 서로 머릿속에 그려지고 있는 바가 같은지를 확인한다.
  • 민: 잘 들어야한다. 내가 말하는 것만 생각하면 상대방의 이야기를 듣는 것보다 내 중심으로 생각하게 된다.
  • 하나의 문맥으로 모든 사람을 이해시키는건 불가능하다.
  • 그렇다면 하나의 문맥으로 다른 사람을 이해시키는건 불가능하다는 것을 인정해야한다.
  • 공유된 이해(Shared Understanding): 똑같은 말일지라도 다 다르게 이해한다.
  • 어떤 문맥을 통일하거나 강요해선 안된다. 커뮤니케이션을 통해 해결해야한다. 자신이 이해한 바를 서로 공유해야한다.
• 코드를 잘 짜는 개발자란 뭘까?
  • 코드를 글로 비유할 수 있다.
  • 코드는 문체, 문장
  • 로직, 알고리즘은 내용
  • 글을 잘 쓰는 사람이란 문체/문장 또는 내용
  • 디자인패턴은 개발자 본인의 생산성에 가깝다. 전세계 공통으로 좋다고 하는 디자인 패턴을 사용하면 본인이나 누군가가 이해하기 쉽다는 장점이 있다.
• 내 코드의 최우선 고객은 미래의 나다.

육각형 개발자 - 5부

일시: 2024-04-12 14:20
목차: 5부 ~ 7부

5부: 응집도

• 응집도와 결합도는 트레이드오프가 있을 수 밖에 없다.
• 누구도 답을 낼 수 없다.
• 응집도의 단점
  • 응집도가 너무 커지면 하나씩 꺼내기가 힘들다.
  • 집합별로 응집도가 다르다. 하나의 응집도가 너무 크면 다른 응집도가 낮아진다.
• 상속보다는 조립 원칙
  • 자바는 상속
  • 타입스크립트는 조립
  • 부모 클래스의 모든 기능을 자식 클래스에 다 쓰는 일이 별로 없다.
  • 그래서 상속을 하면 결합도가 쓸데없이 너무 높아진다.
• 그래도 상속이 좋은 이유
  • 자식 클래스에게 구현(오버라이딩)해야하는 기능을 강제할 수 있다. 조립은 구현을 강제할 수 없다.

6부: 리팩토링

• 리팩토링 === 방청소
• 제품은 날이 갈수록 복잡도가 올라간다.
• 복잡도가 높아진 제품에 기능을 추가하려면 엄청난 리소스, 인적자원이 소모된다.
• 대신 그렇다고 모든 코드에 리팩토링이 필요한건 아니다.
• 상황을 보고 생각해야한다.
• 리팩토링은 언제 해야할까?
  • 방청소는 매일, 평소에 자주 해야한다.
  • 리팩토링도 그냥 항상 하고 있어야 한다.
  • 능력없는 개발자일수록 중요한 개발 전에 리팩토링해야한다는 밈이있다.
• 리팩토링에 테스트가 필수인가
  • 요즘은 ide가 기본적으로 작은 리팩토링을 지원해주는게 있다.

7부: 테스트

• 학생한테 테스트는 필요없다.
• 코드 1만줄부터 고민해볼만하고, 10만줄부터는 필수이다.
• 컴포지션 테스트만으론 어렵다. 컴포지션 테스트하려면 모든 테스트를 고려하는 수 밖에 없다.
• 유닛테스트
• 리액트도 규모가 커지면 대규모 ui 테스트(유닛테스트)는 해야한다. 특히 결제/회원가입
• 그래도 주니어가 손댈 필요는 없다. 재미도 없다.
• 진짜 대규모 프로덕트에나 필요하다.