특정한 종류의 소프트웨어가 있어서 아무도 블로그 포스팅을 쓰지 않는다. 오하이오에 있는 제조 회사의 급여를 관리한다. 당신이 방문한 적 없는 도시의 열차를 예약한다. 2011년부터 생산되어 왔으며, 세 번의 CTO와 민간 투자 회사 인수를 생존했으며, 이를 유지하는 사람들은 나이 많은 선원들이 경험이 많은 배에 대해 이야기하는 방식으로 이에 대해 이야기한다. 읽으며실제 생활에서는 무너지지 않는 변화 안전 시스템 블루프린트는 우리가 이러한 시스템을 얼마나 드물게 공부하고, 이 산업에서 우리가 발표하는 것의 대부분이 반대의 이야기인지를 기억시켜 주었다 — 초보 프로젝트, 리팩토링, 언박싱 비디오와 같은 아키텍처적 유사물. 지루한 소프트웨어가 승리하고, 우리는 거의 결코 그 이유를 묻지 않는다.
우리가 계속 외면하는 생존자 편향
어떤 컨퍼런스 일정을 둘러보고 다섯 년 이상 된 시스템에 대한 발표를 세어보세요. 손가락이 바닥나기 전에 슬롯이 바닥나게 될 것입니다. 산업은 신선함에 대한 구조적인 선호도를 가지고 있으며, 그 선호도는 조급한 엔지니어들이 좋은 아키텍처가 어떤 모습인지 생각하는 것을 조용히 왜곡합니다. 그들은 논의되는 시스템에서 배우는데, 이는 현재 구축되고 있는 것들에 비례하여 불균형되게 많은 시스템을 의미합니다. 이는 그들이 아직 실패할 시간이 없는 시스템에서 배우고 있다는 것을 의미합니다.
시간이 있어서 실패했지만 관리되지 않은 시스템들은 이력서에서 시각적으로 무뚝뚝하게 보이는 특징을 공유하는 경향이 있습니다. 그들은 오래된 데이터베이스를 사용합니다. 중간에 누구도 분할하려고 하지 않는 모노리스가 있습니다. 그들은 현재 정론이 허용하는 것보다 더 많은 사람들이 참여하는 배포 프로세스를 가지고 있습니다. 그리고 계속 작동합니다. 흥미로운 질문은 이러한 시스템들이 현재 기준으로 "좋은" 것인지 여부가 아니라, 우리가 계속 잊어버리는 것을 이해하고 있다는 점입니다.
물리적인 힘으로의 변화
엔지니어들은 변화를 추상적으로 생각하는 경향이 있습니다 — 기능 요청, 리팩토링, 이전 작업 등. 하지만 변화는 구조에 작용하는 물리적인 힘처럼 행동합니다. 그것은 방향, 크기, 그리고 주파수를 가집니다. 작고 자주 발생하는 변화를 흡수하는 시스템은 드물고 거대한 변화를 흡수하는 시스템과 다르게 행동합니다. 마찬가지로 매일 교통을 처리하는 다리와 지진을 대비하는 다리는 다르게 행동합니다. 모든 변화를 동일하게 취급하는 것은 팀들이 수백 개의 작은 배포를 부드럽게 처리했던 아키텍처가 단일 거대한 이전 작업 중에 산산조각 나게 되었을 때 놀랐던 방법입니다.
는 주제에 대한 가장 유용한 장문 글 중 일부에서 등장합니다. IEEE 컴퓨터 협회가 발간한 회복 엔지니어링에 대한 시리즈는 같은 관찰을 계속해서 되돌아옵니다: 복잡한 시스템의 실패 모드는 거의 결코 구성 요소에 관한 것이 아닙니다. 그것은 구성 요소 간의 연결에 관한 것이며, 연결은 정확히 바로 그것이 바뀌는 것입니다 - 조용히, 누적적으로 - 누군가가 작은 수정을 배포할 때마다. 다리의 유사성은 비유가 아닙니다. 그것은 실제 메커니즘입니다.
오래된 코드베이스가 옳게 알고 있었던 것
몇 년 동안 지역 결제소의 금융 정산 시스템을 개발했습니다. 그 핵심은 제가 운전 가능한 나이가 되기 전에 작성되었습니다. 처음 6개월 동안은 그것을 만지는 것이 두려웠고, 그 이후로는 매달 명확해졌습니다. 그 코드 베이스의 일부 패턴은 여전히 제 마음에 남아있으며, 그 이후로 만나는 모든 오래 지속되는 시스템에서 그것들을 볼 수 있습니다.
- 누구도 건드리지 않는 경계. 린터나 코드 리뷰에 의해 강제되는 경계가 아닙니다. 경계를 넘으려면 다른 팀이 다른 건물에 소유한 다른 데이터베이스에 쓰는 것이 필요하기 때문에 강제됩니다. 물리적 분리는 솔직한 아키텍처를 만듭니다.
- 고백처럼 읽히는 로그. 모든 중요한 작업은 무엇을 할 것인지, 어떤 입력을 가지고 있었는지, 그리고 무엇을 결정했는지 기록했습니다. 디버깅을 위해 - 책임감을 위해. 여섯 주 후에 무언가 잘못되었을 때, 당신은 그 결과뿐만 아니라 그 사유를 재구성할 수 있었습니다.
- 우수한 코드에 대한 병리학적 공포. 경험 많은 엔지니어들은 정확하고 잘 테스트되었으며 더 빠른 풀 리퀘스트를 일상적으로 거부했습니다. 이유는 2029년 2시에 이를 디버깅하는 사람이 이해하지 못할 것이라는 것입니다. 그들은 거의 항상 맞았습니다.
- 의도적으로 몇 달이 걸리는 마이그레이션들.수주간의 이중 쓰기, 더 나아가 수주간의 이중 읽기, 오래된 길이 마침내 제거되기 전에 긴 검증의 꼬리가 있었습니다. 이전 이동은 지루했습니다. 그것이 포인트였습니다.
- 공유 가능한 변경 가능한 상태에 대한 알레르기. 성능 때문이 아니라, 동시성 이론 때문이 아니라, 공유 가능한 변경 가능한 상태가 기관 기억이 죽는 곳이기 때문입니다. 두 시스템이 같은 행을 건드리면 결국 행이 무엇을 의미하는지에 대해 서로 다르게 생각하게 될 것입니다.
변화의 비용은 무료라고 속이는 것의 비용
현재 세대의 도구는 변화를 저렴하게 만들었다. 컨테이너는 초에 몇 초 안에 시작된다. 기능 플래그는 아무것도 하지 않는 코드를 배포하고 나중에 켜도록 허용한다. 인프라-코드는 단일 명령으로 환경을 재생산할 수 있게 한다. 모든 것은 현실이며, 이것이 변화를 실제로 저렴하게 만들지는 않는다. 이는 변화를 배포하는 행위를 저렴하게 만든다. 비용은 나중에 결과 시스템을 이해해야 하는 사람들에게 인지 부담의 형태로 나타난다.
컴퓨팅 메커니즘 협회는 이에 대해 꾸준한 경험적 연구 결과를 발표했으며, 그들이 운영 복잡성에 대해 수집한 자료는 ACM Queue 아카이브에 있습니다는 팀의 시스템이 변화를 누적할 때 실제로 무슨 일이 일어나는지에 대한 가장 바탕이 되는 글 중 일부입니다. 계속해서 나타나는 패턴은 시스템이 어떤 단일한 나쁜 결정 때문에 실패하는 것이 아니라, 모든 결정이 개별적으로 합리적이었고, 그 결정들의 누적된 무게는 어떤 한 엔지니어도 머릿속에 들을 수 있는 범위를 초과했으며, 팀은 여전히 도구들이 아무것도 잘못되지 않은 것처럼 느끼게 되어 배포를 계속했기 때문입니다.
실용적인 재해석
시스템이 원래 작성자보다 오래 살아남는 경우, 그중에서도 한 가지를 가져가라: 이 코드를 맥락 없이 상속받는 사람을 위해 최적화하라. 지난 주에 작성한 당신의 버전이나 설계가 여전히 생생한 다음 분기에 유지보수할 당신의 버전이 아니다. 낯선 사람. 2028년에 입사해 특정 기능이 왜 존재하는지와 삭제할 수 있는지 알아보려는 신입사원. 당신이 내리는 모든 선택은 그 사람에게 선물이거나 과부하가 될 수 있다. 생존 가능한 시스템은 대부분의 선택이 선물이었던 시스템이다.
이것은 유산 코드에 대한 로맨틱한 관점이 아닙니다. 오래된 시스템은 실제 문제가 있습니다 — 그들은 죽은 경로를 모아, 폐기된 가정을 인코딩하며, 어려운 일을 더 어렵게 만듭니다. 하지만 그들은 초장기 프로젝트에 없는 하나의 장점이 있는데, 그것은 현실과 접촉해 살아남았다는 것입니다. 그들은 잘못되었고, 수정되었고, 다시 잘못되었고, 다시 수정되었으며, 모든 수정의 잔여물은 아무도 아키텍처 다이어그램으로 포착할 수 없는 종류의 지혜입니다. 일반적으로, 그 지혜를 바꾸는 일이 아닙니다. 그것을 확장하는 일입니다.
아무도 가르쳐주지 않는 교훈
이곳에는 강의가 없습니다. 자격증도 없습니다. 시스템이 생존할 수 있게 만들어질 프레임워크도 없습니다. 이 학문은 더 가까운 것에 가깝습니다 — 매번 커밋하기 전에 변경 사항이 시스템이 흡수할 수 있는 것인지 아니면 조용히 미래의 무게로 쌓일 것인지 묻는 습관입니다. 이러한 감성을 가진 엔지니어들은 단기적으로는 동료들보다 배포 속도가 느리지만, 장기적으로는 극적으로 빠르게 배포합니다. 그 이유는 그들이 끊임없이 인지하지 못했던 채무를 갚고 있지 않기 때문입니다.
죽지 않으려는 시스템은 행운이 아니다. 그들은 미래를 진지하게 생각하는 사람들에 의해 만들어졌고, 대부분 현재를 진지하게 생각하는 직업에서 보상을 받는다. 오래 지속되는 것들의 소스를 읽고, 무료한 소프트웨어를 공부하라. 그들이 무엇을 하지 않는지 주의하고, 각 파일에 묻어 있는 억제의 양을 주의하라. 규율은 코드베이스에 바로 있으며, 누군가가 그것을 교체해야 할 낡은 것으로 보다는 규율로 인식할 수 있도록 기다리고 있다.