7장 코딩하는 동안 서론
데이비드 토머스, 앤드류 헌트
느낌표 ! (인상 깊은 문장 | 문맥)
일단 코딩에 들어가면 대부분 기계적인 작업, 즉 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 하면 된다고들 많이 생각한다. 우리가 보기에는 이런 태도가 소프트웨어 프로젝트가 실패하는 가장 큰 원인이다. 이런 태도 때문에 많은 시스템이 결국 너저분해지고, 비효율적이 되고, 구조가 망가지고, 유지 보수가 힘들어지고, 한마디로 완전히 잘못되고 만다.
p.273
마감 기한이 코 앞으로 다가올수록 점점 관대해지는 경험을 한적이 있다. 사실 마감이 다가올수록 더 신중하고 코드를 잘 작성해야하지만 그렇지못해 악의 구렁텅이로 빠지기 쉽상이다. 그런 악취나는 코드도 기계는 알아듣지만 사람이 알지 못하는게 문제이다. 그걸 수정하고 유지보수하기가 어렵거나 새로 만드는 것보다 노력이 더 들 수 있다. 그러므로 코드를 작성할 때는 느슨한 태도보다는 엄격해질 필요가 있다. 물론 너무 엄격하게 하려하다보면 설계에 너무 치중되어 시간 분배를 잘못하는 경우도 있다. 무엇이든 적절히가 중요하듯 적절하게 해야한다.
실용주의 프로그래머는 모든 코드를 비판적인 시각으로 바라본다. 자기 자신의 코드도 예외가 아니다. 우리는 우리가 만든 프로그램과 설계에서 언제나 개선할 여지를 찾아낸다.
p.274
코드가 잘 돌아갈 것으로 생각하기 십상이지만 어김없이 버그를 발견한다. 너무 긍정적으로 코드를 생각하면 놓치는 부분이 꼭 있다. 그럴 때마다 비판적인 시각을 가졌어야한다는 후회를 하곤한다. 물론 비판적인 시각이란 자신의 생각의 범주를 넓혀야하다보니 어려운 작업인 것은 또 분명하다.
테스트는 버그를 찾는 작업이 아니다. 여러분의 코드에 대한 피드백을 받는 작업이다. 설계 측면에서, API나 결합 측면에서 등 다양한 피드백을 받을 수 있다. 이 말인즉슨 테스트의 긍정적인 효과는 대부분 테스트를 수행할 때 나타나는 것이 아니라, 테스트에 대하여 생각할 때 그리고 테스트를 작성할 때 나타난다는 것이다.
p.274
ISTQB 자격증 공부할 때 테스트 목적 중 한 가지는 버그가 없다는 것을 증명하기 위함이 아니라 최소한의 신뢰를 보장하기 위함이라고 배웠던 기억이 난다. 하지만 저자는 이를 넘어 테스트는 코드의 긍정적인 영향을 준다고 설명하고 있다. 정말 그렇다. 테스트 케이스를 작성하기 위해서는 각 필요한 함수들이 존재해야하기에 자연스레 모듈화가 되어가는 장점도 있다. 물론 잘못하면 산으로 가는 경우도 있다. 여하튼 테스트 케이스는 여러 이점을 주지만 실질적인 코드의 품질도 향상된다.
7장 서론 느낌
7장 서론에서는 부족한 부분을 채워줄 것 같은 막연한 기대감에 차게한다.