소프트웨어 공학의 사실과 오해 7 – 검토와 검사
http://www.yes24.com/24/goods/1418676
검토와 검사
비약에 가까운 기법이 하나 있는데, 아이러니하게도 이 기법은 소프트웨어 오류 제거 활동에서 제외되어 한 구석에 처박혀 있다. 엄격한 검사가 그것으로, 소프트웨어에 포함된 오류를 찾기 위해 노력을 쏟는 이 기법은 거의 비약이라 할 수 있다. 연구 조사를 거듭한 결과 검사는 테스트 케이스를 실행시키기도 전에 소프트웨어 제품에 포함된 오류의 90%를 발견할 수 있다는 것이 밝혀졌다.
p.191
그런데도 불구하고 검토와 검사가 CASE 도구나 여러 방법론과 같은 더 못한 것들도 받던 찬사를 받지 못하는 이유는 아래의 4가지.
- 검사로 돈을 버는 메이저 벤더는 거의 없다.
- 검사에는 새로운 것도 없고 따라서 시장성도 없다.
- 검사는 소프트웨어 생명주기의 뒤쪽 단계에 있는 보이지 않는 부분으로 간주된다.
- 검사는 효율적이긴 하지만, 녹초가 될 정도로 정신을 집중해야 하는 고된 작업이다.
대부분의 방법론이나 프랙티스의 유행의 배경에는 해당 제품으로 돈을 버는 메이저 벤더가 있어왔다는 것이 이책의 일관된 주장이다. 실제로 은 탄환Silver Bullet이란 없기 때문에 애초에 유행할 것이 없지만, 과대선전자들에 의해 근거없는 유행이 생겨난다는 것.
제품의 출시후에 어떤 일이 있었는지 숙고하거나 앞으로 어떻게 개선할 수 있을지에 대해 기록하는 회고를 시행하는 조직이 거의 없다는 얘기에 이어서 아래의 내용이 나온다.
그 결과 소프트웨어 프로젝트에서 배운 모든 교훈은 버려지거나, 프로젝트가 끝날 때 바람과 함께 날아가 버린다. 왜 그럴까? 소프트웨어 분야의 광폭한 일정으로 인해, 어제 프로젝트에서 일하던 프로그래머들이 이미 내일 프로젝트로 흩어져 배치돼 버리기 때문이다. 그리고 거기서는 새로운 일정에 묶여 몇 달 전에 어떤 일이 있었는지 생각할 겨를도 없다.
p.200
결국 소프트웨어 분야는 한 자리에 처박혀 매 프로젝트마다 같은 실수를 반복하고 있고. 소프트웨어 분야의 지혜Wisdom는 증가하지 않는다는 얘기.
어떤 문제에 대한 올바른, 최적의 솔루션이 딱 하나만 있는 경우는 거의 없다고 했던 것을 상기하기 바란다. 솔루션을 검토할 때 다른 개발자가 선택한 방법의 관점에서 검토하는 것은 자신의 방법 관점에서 검토하는 것보다 어렵다. 다른 사람의 신발을 신고 먼 길을 걷는 것은 쉬운 일이 아니다.
p.205
동료 검토Peer Review에는 기술적 측면과 사회적 측면을 모두 중시해야 하는데, 위와 같이 기술적 검토 작업을 훌륭히 하는데 필요한 ‘집중’으로 인해 검토의 사회적 측면에 대한 주의가 감소한다고 한다.
엄격함을 달성하기 위한 집중 때문에 사회적 문제를 해결하기 위해 남겨둔 에너지까지 모두 소모돼 버린다. 따라서 검토기간 동안의 사회적 문제는 심각해질 수 있다. 비자아적 프로그래밍(egoless programming)을 부르짖지만, 우리는 대부분 자신이 작업하는 제품에 이성과 감정을 투영하게 되고, 이로 인해 다른 사람이 우리의 작업을 검토하면 쉽게 상처받는다. -중략- 모든 자아가 위태로워지고 사회적 방어 메커니즘이 감소한 상태에서, 사회학적 폭발을 초래하는 것은 그리 오래 걸리지 않는다.
p.206
동료 검토 하면서 얼굴 붉히는 경험은 다들 있을 것 같다. 잘 먹히는 해결책을 제시할 수 있으면 좋겠지만, 기술적 측면과 사회적 측면에 모두 주의를 기울여야 한다는 사실이라도 업계에 널리 퍼졌으면 좋겠다. 문제가 인식되면 해결책이 도출되는 것은 시간문제가 아닐까.
개인적으로는 저자 워크숍 방식을 코드 리뷰에 사용해보고 싶은 바램이 있다. (해보신 분 있으실지도)
IBM developerWorks – 저자 워크샵 (김창준님)http://www.ibm.com/developerworks/kr/library/dwclm/20081230/
재미있는 책 읽고있네.^^ 한번 읽어보고 싶다. 참 그리고 아래 링크의 글대로 진행해 봐도 좋을 것 같네. 함 해봐야지.
히댕
14 Jan 10 at 1:06 am
해보시고 어떤지 꼭 알려주세요~~
muscly
15 Jan 10 at 9:36 am