"소프트웨어 설계는 인간 관계의 연습입니다"
소프트웨어 설계와 인간관계?
제목은 <Tidy First?> 라는 소프트웨어 설계 책에서 저자 켄트 백의 첫 문장이다.
coupling, cohesion, power laws, refactoring 등 소프트웨어 설계의 중요한 개념들과 인간관계에는 어떤 관계가 있을까?
*그림 출처: https://beetroot.co/productivity/tidy-first-daily-empirical-software-design-why-it-works/
위 그림에서 동그라미가 소프트웨어 팀이며
웨이터는 시스템 동작의 변경을 요청하고
체인저는 코드를 변경한다.
- C는 changers (아마도 개발자)
- W는 waiters (아마도 기획자)
이 때 세가지 관계가 있다
- 웨이터와 개발자의 관계
- 팀 내 개발자 간의 관계
- 개발자 자신과의 관계
이 관계는 어떻게 진행되어야 할까?
*그림출처: https://beetroot.co/productivity/tidy-first-daily-empirical-software-design-why-it-works/
소프트웨어 개발에서 아이디어 (예: 편집 버튼이 필요해요)에서 변화 (UX, workflow, backend)로 전환할 때 그 새로운 기능이 더 많은 기능 요구사항을 생성하는 사이클이 시작되는 경우가 많다. 그래서 'Structure' 부분이 물 아래에 있다.
여기서 'idea'와 'behavior'의 루프만 돌면 기술 부채가 엄청 쌓이고, 아름다운 'structure'만 고집하면 사용자의 요구사항과는 멀어져 성과가 없는 설계가 될 수 있다.
그러면 좋은 흐름은?
피드백 루프에 반복 필요
- 아이디어를 빠르게 시도해보고
- 새로운 동작에 더 적합한 구조를 변경한 다음
- 다음 동작 변경을 완료
- (때로는 설계 변경이 새로운 아이디어를 제안)
생각해보기
소프트웨어 설계에 대해 이야기할 때 '인간 관계'를 언급한다는 점이 흥미로웠다. 나의 현재 고민 포인트는 '웨이터'와 '체인저'의 커뮤니케이션 부분인데, 어쨌든 소통이 잘 되려면 '체인저'의 의지도 중요하지만 함께 눈을 맞추고 논의할 수 있도록 시각화가 중요하겠다는 생각이 든다.
참고링크
https://beetroot.co/productivity/tidy-first-daily-empirical-software-design-why-it-works/
