Topic 38 우연에 맡기는 프로그래밍
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
우연에 맡기는 프로그래밍 하기
왜 코드가 망가졌는지 프레드가 모르는 까닭은 애초에 코드가 왜 잘 돌아가는지도 몰랐기 때문이다.
p.283
인정하기 싫지만 인정할 수 밖에 없다.. 믿어 의심치않는 코드도 무너지는 경험을 종종 해봤기 때문이다. 버그를 찾다보면 왜 이렇게 코드를 작성했는지 싶은 코드들이 많다.
구현에서 생기는 우연
“이제 돌아는 가니까, 그대로 놔두는 편이 더 나을 거야…’ 이런 함정에 빠지기 쉽다. 잘 작동하는 데 괜히 건드려서 일을 만들 필요가 있을까?
p.284
코드를 변경하고 리펙토링하고 싶지만 최소한 테스트 케이스가 없는 경우에는 손대기가 무섭다. 그렇기 때문에 테스트 케이스를 작성하고 리펙토링할 수 있는 기반이 우선시 되어야한다. 여하튼 가장 중요한 것은 코드를 놔두는 것이 결코 정답이 될 수 없다는 것이다.
상황에서 생기는 우연
현재 디렉터리에 쓸 수 있다는 것에 의존하고 있지 않은가?
p.287
위와 같은 경험은 한 2번 정도 있는데 로컬에서는 동작하나 배포하고 테스트 해보면 에러가 발생하여 원인을 찾아보니 디렉토리가 없어서 발생하였다. 로컬에서는 빈 디렉토리가 있어서 문제가 없었지만 실 환경에서는 해당 디렉토리가 없어서 에러가 발생한 것이였다. 이처럼 의존하고 있지만 의존하고 있다는 것을 잊으며 프로그래밍할 때가 많다. 조기에 발견돼서 다행이지만 이러한 부분은 운영 중 크나큰 장애로 이어질 수 있다. 그러므로 의존할 때 유동적으로 동작할 수 있도록 해야한다.
암묵적인 가정
테스트가 특히 가짜 원인과 우연한 결과로 가득 찬 영역이다.
p.287
테스트 케이스를 작성하다보면 잘 돌아간다는 착각에 빠진다. 사실 테스트 케이스는 여러 경우의 수 중 하나일 뿐인데 기능이 완벽하다고 착각하고 다른 경우의 수를 생각하지 못하기 십상이기 때문이다. 그러므로 테스트는 필요하지만 신봉하지 않고 꾸준히 업데이트와 다양한 상상이 필요하다. 그래서 우연한 결과가 아니라 필연의 결과들로 채우는 것이 이상적이겠다.
모든 차원에서 사람들은 마음속에 많은 가정을 품고 작업한다.
p.287
잘 동작한다는 것은 여러 경우에서 일뿐 모든 경우가 잘 돌아간다고 대변하지는 않는다. 그러므로 상상을 멈추지 않고 더 다양하고 때로는 여러 관점에서 살펴볼 필요가 있다.
Topic 38 느낌
Topic 38 에서는 끊임없이 고민하고 상상하고 준비하라는 마인드셋을 알려주고 있는 것 같다.