장부, 양쪽 칸 다
사준 것들, 가치가 실제로 나타나는 순서대로.
- 고침한테 집이 하나 생겨. 원래 논거고, 여전히 제일 작은 거야. 공용 층의 결함은 한 번 고쳐서 배달되지, 한 번 고치고 두 번 잊히지 않아.
- 어긋남한테도 집이 생겨. 더 큰 거고. 첫 트랙의 앱 사이 버그는 아무한테도 안 속한 틈에 살았어. 주인이 있다는 건 그 틈한테 주소가 있다는 뜻이고, 주소가 있는 물건엔 테스트가 붙어.
- 수렴이 결정을 수면으로 올려. 구현 셋을 통일하면 저자마다 기본값으로 답하고 있던 질문에 누가 답해야 해. 에러 자세, 어휘, 뭔가 없을 때 벌어지는 일.
- 공용 층으로 수렴하는 앱이 공용 층을 개선해. 변환 넷 중 셋이 공용 컴포넌트를 바꿨고, 각각 그 저자들이 필요해본 적 없는 처방이었어.
- 다음 형제가 싸. 새 앱이 자기 사본을 기르는 대신 태어날 때부터 배관을 갖다 써.
그리고 치르는 값, 똑같이 분명하게.
- 공용 변경마다 붙는 배달 단계, 그리고 시스템이 아무도 설계 안 한 상태에 있는 창.
- 사람이 잊을 수 있는 규칙, 그래서 어긋남 검사가 선택 사항이 아냐.
- 프레임워크가 되려는 끊임없는 끌림, 태어날 때 적힌 규칙이랑 일부러 하는 확인으로만 버텨.
- 공용 파일에 대한 조율. 공용 층에 대한 변경은 모든 소비자에 대한 변경이고, 누가 원했든 아니든 그건 참이야.
필요한지에 대한 정직한 시험
중복이 있는 코드베이스 대부분은 이걸 짓지 말아야 해. 시험은 "중복 코드가 있나"가 아냐. 다들 있어. 질문 셋에 가깝고, 결정하는 건 세 번째야.
- 중복된 층이 설계상 똑같아? 앱이 진짜로 달라서 사본이 다른 거면, 추출은 아무도 못 섬기는 인자 범벅 함수를 낳아.
- 어긋남이 이미 뭔가를 치르게 했어? "그럴 수 있다"가 아니라 그랬냐야. 앱 사이 결함, 누가 보고한 불일치, 셋 중 둘에만 적용된 고침.
- 사본들이 지금 따로 답하고 있는 질문들에 대해 모든 소비자가 공용 답을 받아들이겠어? 아니면 배관 문제가 있는 게 아냐. 서로 달라야 하는 앱들이 있는 거고, 정직한 구조는 따로 구현 더하기 그 사이 적힌 계약이야.
공용 코드는 중복을 없애고, 적힌 계약은 조율할 필요를 없애. 다른 기구고 대부분의 가족은 둘 다 필요해. 두 물건이 닮으면 공용 코드로 손 뻗는 게 반사고, 그래서 그렇게 많은 공용 층이 애초에 배관이 아니던 걸 쥐고 끝나. 어떤 땐 맞는 답이 구현 셋이랑 문서 하나야. 그건 통합 실패가 아니라 설계고.
들고 갈 문장
이 퀘스트의 전부가 수 하나로 줄어. 계속 반복해서 적용된 수. 그 물건한테 주인을 주고, 맞는 결과를 기본값으로 만들어.
배관이 주인을 얻었어. 어휘 둘 사이의 틈이 주인을 얻었어. 패널의 얼굴이 주인을 얻었고. 그리고 매번 실제로 버틴 강제는 누가 기억해야 하는 규칙이 아니라, 아무것도 안 넘기는 걸 맞게 만드는 기본값이거나, 테스트를 깨뜨리는 검사거나, 한 자리에서 만들어져 사방에 배달되는 값이었어.
문서에 사는 규칙은 맥락한테 져. 기본값이랑 깨지는 테스트에 사는 규칙은 안 지고. 이 퀘스트를 만들어낸 작업장이 지어진 바로 그 교훈이야. 반대 방향에서 도착한.