최근 품질 관리 업무도 0.5 정도 함께 맡게 되면서, 소프트웨어 품질 관리에 대한 고민으로 책을 읽게 되었다. 내가 아니라 조직 내 시니어 개발자나 어플리케이션 아키텍처가 맡아야 될 역할 같은데, 어쨌든 내가 할 수 있는 역할과 키워야할 능력에 대해서 생각을 해볼 수 있었다. 관련 문서와 서적을 보면서 생각과 기술을 확장해내가야 하겠다.
시스템을 새로 오픈하고 거의 1년이 다되어 가고 있고, 이젠 소프트웨어 품질과 개발 프로세스에 대한 관심이 높아지고 있다. 동시에 조직이 개편되고 개발 인력이 점차 줄어들고, 조직간 인력 이동도 좀 더 자유롭게 될 것으로 예상된다. 그래서 이러한 변화에 유연하게 대응하기 위해서는 조직 내 지식 공유라든지, 소프트웨어 품질 관리가 더 중요해졌다.
코드 표준을 준수하고, 소스의 복잡도에 신경을 써야하며, 필수적으로 작성해야 하는 문서 작업도 필요하다. 하지만 책에서 언급되었듯이, 이 모든 것은 개발 조직의 생산성을 측정하고 품질을 감사하기 위한 것보다는 현 아키텍처와 개발 프로세스 상에서 개발자가 힘들어 하는 부분에 대해 도움을 주는 활동에 좀 더 초점을 맞춰서 진행되어야 한다.
Software Life Cycle 상에서 정말 크리티컬한 오류를 미리 감지하고 방어할 수 있는 방법과 생산성에 도움이 되는 활동을 위한 프로세스를 수립하고, 필요한 Tool을 검토 및 개발하는 활동을 우선해야할 것이다.
하위 호환성이 가치를 잃는 시점은 언제인가?
- 유용하고 중요한 새 기능을 추가하고자 할 때 하위 호환성이 길을 막으려 한다면 그때만큼은 하위 호환성을 무시해도 된다.
버그의 원인
- 버그는 보통 복잡성을 줄일지 못할 때 발생한다. 또 그보다는 드물지만 간단한 대상을 잘못 이해했을 때도 발생한다.
재발을 방지하라
- 자동 테스트를 추가해서... 정상적으로 작동하는지 확인하게 하면 해결된다... 테스트가 유지 보수하기 쉬운지 확인해야 한다. 테스트의 유지보수가 어려우면 개발자가 코드를 변경할 때 테스트도 너무 많이 달라져서 테스트 코드 자체가 수수께끼처럼 복잡해진다.
디버깅의 기본 철학
- 디버깅은 크게 다음 4단계로 볼 수 있다.
1. 정상 시스템이 어떻게 작동하는지 알아낸다.
2. 문제의 원인을 아직 모른다는 사실을 인정한다.
3. 문제를 일으키는 원인이 무엇인지 알아낼 때까지 데이터를 살펴본다.
4. 증상이 아닌 원인을 고친다.
- 내가 겪은 프로그래머 대부분은 버그가 생기면 자리를 잡고 앉아서 버그에 관해 생각해보거나 원인이 무엇일지 이야기하고 싶어한다. 둘 다 결국은 추측이다.
엔지니어링 생산성을 효과적으로 개선하기
- 가장 먼저, 개발자가 생각하는 문제가 무엇인지 알아내라. 스스로 판단하지 마라. 사람들의 의견을 물어라. 관리자나 중역의 의견만 물어서는 안 된다. 임원은 실무를 하는 소프트웨어 엔지니어와는 완전히 다른 의견을 제시하는 경우가 많기 때문이다. 코드 베이스를 직접 다루는 사람과 이야기를 나눠라... "바이너리 파일의 빌드가 느리다." 등의 구체적인 주제를 찾아야 한다. 주제는 하나가 아니라 여러개가 나올 수도 있다.
- 생산성 담당자가 쌓은 개인적인 신뢰가 엔지니어링 생산성 업무에서 가장 중요하다.
- 개발자가 문제로 여길 거라 추측하는 문제 말고 (a) 존재한다는 걸 확실히 증명할 수 있는 문제, (b) 존재한다는 사실을 개발자들도 인정하는 문제를 해결하라.
리팩토링할 떄는 기능에 주목하라
- 리팩토링을 위한 리팩토링을 한다면 리팩토링의 이름에 먹칠을 하는 것이나 다름없다. 이를 두고 사람들은 시간 낭비한다고 생각할 것이다. 본인의 신용이 떨어지고, 관리자나 동료들은 그 작업을 계속하지 못하게 막을 것이다.
- 현재 제품이나 시스템의 기능적 목표와 관련이 없는 리팩토링은 아무도 관심을 보이지 않는 쓸모 없는 물건을 정리하는 행위처럼 아무것도 성취하지 못한다.
- 보통은 구현하고 싶은 기능을 고르고, 그 기능을 더 쉽게 구현하기 위해 어떻게 리팩토링하면 좋을지 알아내면 된다. 아니면 작업할 때마다 자주 정비해야 하는 부분을 찾아도 된다. 그러면 사람들이 여러분이 한 일을 고마워할 것이다... 다른 사람이 여러분이 하는 일에 관심을 갖고 그 덕에 회사 전체에 좋은 개발 관행까지 형성된다면 금상첨화다.
단순성과 보안
- 시스템을 단순하게 설계하는 것만이 보안을 보장하는 유일한 방법이다. 시스템의 각 '입구'를 최대한 단순하게 만들고 꼭 필요하지 않은 '입구'는 절대 추가하지 마라.
'아니요'의 힘
- 소프트웨어 설계자가 있다면 전체 세스템에 대한 최종 책임은 설계자에게 있다.... "아니요"라고 말할 권한을 가진 소프트웨어 설계자가 반드시 있어야 하고 그 설계자는 필요에 따라 그 권한을 실제로 행사해야 한다. "아니요"라고 말해야 하는 아이디어에 "아니요"라고 말하는 것만으로도 제품의 완성도가 놀라울 정도로 높아진다.
- 나쁜 아이디어 알아내기
- 너무 복잡하다거나 유지보수가 불가능하다거나 쉽게 수정할 수 없다거나 등등의 핑계로 소프트웨어 설계 법칙을 어기며 구현해야 하는 기능이라면 나쁜 아이디어다.
- 사용자에게 도움이 되지 않는 기능은 나쁜 아이디어다.
- 누가 봐도 바보 같은 제안도 나쁜 아이디어다.
- 입증된 문제를 해결하지 못하는 수정 사항은 나쁜 아이디어다.
- 좋은 아이디어인지 확신할 수 없으면 나쁜 아이디어다.
빠른 프로그래밍의 비결: 생각하지 않기
- 진짜 똑똑한 사람들은 배우고, 관찰하고, 결정하고, 행동한다. 지식을 얻으면 그 지식을 당면 과제를 해결하는 데 사용한다. 만약 진짜 똑똒해지고 싶다면 자신의 지식을 혼자 훌륭한 생각을 하는 데 쓰지 말고 물리적 세계를 변화시키는 데 써라.
 | 심플 소프트웨어 -  맥스 카넷-알렉산더 지음, 이미령 옮김/길벗 |
댓글