Conway's Law
· 연결된 개념 9개
콘웨이의 법칙은 조직이 대화하는 모양대로 시스템이 생긴다는 말이에요. 세 팀이 함께 만들면 팀끼리 말이 잘 안 통하는 자리마다 선이 그어져, 결과물도 큰 덩어리 셋으로 나뉘기 쉬워요.
비유가 깨지는 곳 그냥 따라오는 결과로만 볼 필요는 없어요. 원하는 아키텍처가 있으면 팀 구조부터 그 모양으로 바꾸는 역 콘웨이 전략을 쓸 수 있고, 집단 코드 소유로 이 경향을 누그러뜨리기도 해요.
조직은 자신의 의사소통 구조를 그대로 닮은 시스템을 설계한다는 법칙. 멜빈 콘웨이(Melvin Conway)가 1968년에 관찰했다. 팀이 셋이면 시스템도 큰 덩어리 셋으로 나뉘는 경향이 있다.
출처: Laws of Software Engineering: Conway's Law · How Do Committees Invent? 멜빈 콘웨이
한 요소를 바꿀 때 다른 요소도 바꿔야 하는 관계. 결합도는 언제나 "어떤 변경에 대해" 결합되어 있는지를 함께 말해야 의미가 있다. 같은 두 모듈도 어떤 변경에는 묶여 있고 어떤 변경에는 독립적일 수 있다.
동작하는 복잡한 시스템은 언제나 동작하던 단순한 시스템에서 진화한 것이라는 법칙. 처음부터 복잡하게 설계한 시스템은 동작하지 않고, 고쳐서 동작하게 만들 수도 없다는 경고가 뒤따른다. 존 골(John Gall)이 1975년 『Systemantics』에서 말했다.
켄트 벡이 정리 시점을 판단하려고 꺼내는 경제학 틀. 소프트웨어는 두 가지 가치를 만든다. 오늘 하는 일(동작)과, 내일 새로 할 수 있게 되는 일(옵션)이다. 구조는 동작을 바꾸지 않지만 옵션을 만든다.
켄트 벡이 "코드를 바꾸기 전에 먼저 정리해야 할까?"라는 질문 하나를 붙잡고 쓴 얇은 책. 아주 작은 구조 변경인 정리의 기법, 언제 정리할지의 관리, 왜 그런지의 이론을 차례로 다룬다.
"모든 지식은 시스템 안에서 단일하고 명확하며 권위 있는 표현을 하나만 가져야 한다." 앤디 헌트와 데이브 토머스가 『실용주의 프로그래머』에서 정리한 원칙이다. 코드 줄의 반복만이 아니라 규칙·데이터·지식의 중복을 말한다.