실용주의 프로그래머 책에선 깨진 유리창 이론을 개발에 적용한다:
> 깨진 유리창 하나 - 조악한 설계의 코드, 형편없는 경영상의 결정 등 프로젝트 기간 동안 팀이 동고동락해야 하는 문제 -는 내리막길로 가는 첫걸음이다.
이 팁은 조심히 사용할 필요가 있다. 악용하기가 참 쉽다. 예를 들면:
코드 리뷰 과정에서 유난히 공격적인 코멘트가 달리는 경우가 있다. 기분이 좋진 않지만 딱히 틀린 말은 아니긴 하다. 그래도 "굳이?" 생각이 들어 그냥 넘어가도록 하겠다고 대답하면 빠르게 답변이 달린다.
"No broken windows"
대충 넘어가면 나중에 큰 화를 낼 거다. 그러니 고쳐라.
엄밀히 따지만 맞는 말이다.
하지만 깨진 유리창 이론을 방패 삼아 코드에 대한 유별난 강박증이나 독성 말투를 정의로운 행동으로 포장하려는 모습이 나는 불편하게 느껴진다.
편견을 과학적 논리로 정당화한 부끄러운 역사가 겹쳐 보인다.
"엄밀히" 따지면 "깨진 유리창 이론"은 문제가 많다.
90년도 뉴욕 경찰청에서 적용해 범죄율 감소에 효과를 보았다고 알려졌지만, 그 이후 많은 경제/사회학자들에게 지적 당했다.
"딱히 효과는 없었다" 부터 "인종차별적 치안활동을 장려했다" 까지.
npr.org/2016/11/01/500104506/broken-windows-policing-and-the-origins-of-stop-and-frisk-and-how-it-went-wrong
특히나 깨진 유리창 이론을 사용해 인종차별적 행동을 정당화 했다는 주장을 읽고 흠칫했다. 몇 달 전 소개한 "나이와 성별에 따른 코드 리뷰 딴지 수" 결과가 생각났기 때문이다:
twitter.com/dylayed/status/1499616650584215557
"Code wins argument" 같은 이상적인 슬로건을 내세우지만 우리의 편향이 그대로 드러난다.
좋은 질의 코드 작성이 중요하지 않다는 건 아니다. 코딩 컨벤션과 코드 리뷰를 통해 좋은 질의 코드를 유지하는 건 찬성이다.
단 독하거나 현학적인 지적으로 팀의 심리적 안정감을 해치면서까지 좋은 코드의 질을 고집하는 게 무슨 의미가 있는지 난 의문이 있다.
보통의 개발은 장거리 팀 운동이고, 심리적 안정이 팀 성과에 미치는 중요성은 이미 많은 분이 아실 거로 생각한다.
코드베이스의 유리창이 깨지는 걸 막으려고 팀원과의 신뢰를 깨트리는 건 아닌지 고민하며 "깨진 유리창 이론"을 적용했으면 한다.
rework.withgoogle.com/print/guides/5721312655835136/