[IT/리뷰] 거꾸로 배우는 소프트웨어 개발 리뷰

책정보, 거꾸로 배우는 소프트웨어 개발 : 네이버 책 (naver.com)

거꾸로 배우는 소프트웨어 개발

 

오늘은 '거꾸로 배우는 소프트웨어 개발 - 소프트웨어 개발에 관한 인문학적 접근'에 대해 요약/정리를 해볼까 한다.

 

책은 제목과 같이 전반적으로 인문학적, 관리적 차원에서 소프트웨어 개발 조직이 어떻게 더 좋아질 수 있는지에 대한 내용을 다룬다. 개발 조직뿐만 아니라 그냥 개발자나 관리자 차원에서도 지금 업무와 관련해서 여러 점을 고려해볼 수 있는 좋은 내용이었다.

 

책은 코드나 예제 같은 것들은 없고, 조직이나 개발/유지보수 같은 업무를 할 때의 관리 방법과 같은 것을 재밌게 설명해주고 있다. 현재 회사 생활과 오버랩되어 공감되는 부분도 있었고, 처음 듣거나 관심을 안 가졌던 내용들에 대해 알아가면서 신기하고 흥미 있는 부분도 있었다.

 

책 전반적으로 가장 강조하는 것을 꼽으라면 아래의 내용이다.

• 리팩터링을 해보자.
• TDD와 단위 테스트는 중요하다.
• 다른 개발 모델보다는 SCRUM을 해보자.

 

BOB를 하면서 만났던 멘토님처럼 아키텍터 역할을 하고 싶고 리팩터링을 잘 해보고 싶었기 때문에 내용이 흥미가 있었다. 그러면서 TDD와 단위 테스트가 중요하다는 점이 놀랐었다. 멘토님도 BVT(빌드 검증 테스트)를 하기 때문에, 같은 맥락에서 리팩터링을 잘하려면 단위/통합 테스트가 중요하구나 싶었다.

멘토님한테 배우면서 옆에서 봤던 점들인데, 한동안 회사를 다니면서 잊고 살았다. 그래서 TDD와 단위 테스트는 CppUnit으로 익혀보려고 한다. 물론 책에서도 말했듯이 요즘 시간이 많이 여유 있지는 않아 당장 도입은 어려운 상황이다. 그래도 회사에서는 당분간 유지보수 업무를 할 예정이니, 새 프로젝트 들어가기 전에 익혀서 조금씩이라도 적용해볼 수 있도록 미리 준비해야겠다. 아마 여름 지나고 나서부터 볼 수 있을 것 같은데.. 그때까지 새 프로젝트는 안 하겠지...?

 

그리고 SCRUM도 신기했다. Agile까지는 많이 듣는 개발 모델이지만, SCRUM은 듣기만 해보고 제대로 찾아보지는 못했기 때문에 처음 제대로 봤다. 기간을 정하고 할 일을 정하고 멈추지 않고 Sprint 하는 점이 매력적이었다. 일정 관리도 제대로 될 수 있을 것 같고, 길게 끌지 않고 마일스톤마다 완료할 수 있으니 체력 관리에도 좋을 것 같다.

다만, SCRUM은 혼자 진행할 수 없기 때문에 아쉽다. 일개 1년차 개발자가 요청해서 '저만 그렇게 할 테니 QA나 다른 분들도 도와주세요' 할 수 없는 노릇이다. 다른 인원들과 많이 겹칠 수밖에 없는 일이기 때문에 어쩔 수 없는 것 같다..

사이드 프로젝트하면서 적용이 가능할지도 모르겠어서, 언젠가는 적용해볼 수 있지 않을까?라는 생각을 하고 말았다. 

---

요약 및 생각 정리

• 기존의 코드가 레거시 코드가 된다.
  > 레거시 코드가 된다.
  > 레거시 코드와 같은 목적의 신규 프로젝트(Zero code based new project)를 착수한다.
  > 레거시 코드는 버릴 것이기 때문에 최소한의 유지보수로 버틴다.
  > 신규 프로젝트는 많은 버그가 발생한다.
  > 신규 프로젝트에는 많은 기능 요구사항이 발생한다.
  > 점점 신규 프로젝트의 코드 복잡도가 높아지면서 무거워진다.
  > 점차 신규 프로젝트 역시 레거시 코드가 된다.
  > (반복)
  • 나쁜 방법은 아니라는 말도 공감이 되고, 코드가 죽는 환경이 있을 수밖에 없는 것도 공감이 된다.

 

• 기존 코드를 리팩터링을 적용해보자.
  
  • 필요성에 대해서는 공감이 되었으나, 많은 능력이 요구된다고 생각한다.
  • 구조를 설계하는 방법을 확실히 할 줄 알아야 가능하다고 생각해, 점점 관련 공부를 할 예정이다.

 

• 리팩터링을 위해서는 단위 테스트가 필수다.
  • 리팩터링 시, 코드의 상태와 내용이 계속 바뀌게 된다.
  • 바뀐 코드가 제대로 동작하는지 매 순간 계속 테스트하면서 확인하는 것은 어렵다.
  • TDD가 어렵다면, 단위 테스트라도 갖추자.
  • 단위 테스트를 갖춘다면 두려움 없이 리펙토링을 할 수 있다.
  • Wrap and Conquer 방법으로 리팩터링 후에도 코드가 정상 동작하는 것을 '입증'해라.
  • 단위 테스트 덕분에 점진적으로 리팩터링 할 수 있다.

 

• 개발 방법론은 말 그대로 '방법론'일 뿐이다.
  • 어떤 절차도, 문서 같은 것도 아니다.
  • 반드시 단계가 지정되고 단계별 산출물이 나올 필요가 없다.
  • 오히려 불필요한 문서로 함몰되지 않도록 주의해야 한다.
  • 방법론의 핵심은 결과나 산출물이 아닌, 사람과 조직이 처한 문제를 해결할 수 있는 방법인 것이다.
  • 집단에서 다 같이 잘 짜기 위해 필요한 것이며, 과거 천재들이 각자 개발할 때는 필요 없었다. 없어도 지금보다 버그가 없었다.

 

• 폭포수 방법론은 왜 욕을 먹는지 모르겠다.
  • 현실에서는 충분히 설계 단계로 폭포를 거슬러 오르는 경우가 많다. 현실에는 펌프가 많다.
  • 현실에서는 Iteration이 불가피하다.
  • 너무 완벽한 방법이라 어려운 것이며, 폭포수 방법을 욕하는 사람들 중 대부분은 폭포수 방법론을 제대로 따라 해보려 한 적이 없을 것이다.
  • 어떤 방법론이든, 자신에게 맞는 것이 있는 것이다. 아무리 좋은 약이라도 맞는 사람이 먹어야 한다.
  • 뭔가 묘하게 설득되는 말들이었다.

 

• 단기 속성 개발은 대부분의 경우에서는 좋지 않다.
  • 시장을 선점하거나 트렌드를 따라야 하는 경우에는 좋을 수 있다.
  • 다만, 기간 때문에 대충 개발하는 등의 문제 때문에 유지보수 양은 늘어나고 다른 신규 프로젝트는 하지 못할 것이다.
  • 불완전한 기능 100개보다 되는 기능 10개를 만들어라.
  • 반쪽자리 제품을 만드느니 제품을 반만 만들어라.
  • 결국에는 장기 지속 개발로 대체해야 한다.
  • 장기 지속 개발로 넘어가면서 어느 정도 코드의 복잡도가 커지게 되면 리팩터링을 진행하라.

 

• 비가시적 산출물도 중요하게 챙겨야 한다.
  1. 사람의 경험/기술
  2. 조직과 팀의 경험/프로세스(의사소통)
  3. 재사용 가능한 솔루션/컴포넌트

 

• 좋은 개발 관리자의 전문성
  • 관리자는 개발자보다 개발 방법론에 대해서 더 잘 알아야 한다.
  • 사실 개발자는 시키는 대로 개발만 잘해도 된다.
  • 관리자가 개발 방법론을 모르고 일을 시키면 아래에 있는 개발자는 뛰쳐나갈 거다.
  • 관리자는 스페셜리스트가 아닌 제네럴 리스트가 되어야 하기 때문에 알아야 한다.

 

• 좋은 개발 관리자의 시간 관리
  • 개발자의 야근/특근/주말 출근과 같은 경우는 정말 비상시를 제외하고 없어야 한다.
  • 회의 시간을 줄여야 한다. 회의시간 * 회의자 수만큼의 비용이 발생한다.
  • 인터럽트를 줄여야 한다. 개발자들의 몰입을 깸으로써 예열 등에 낭비되는 시간을 줄여라.
  • 왜 회의만 많은 회사가 안 좋은 회사인지 바로 이해할 수 있었다.

 

• 좋은 개발 관리자의 몰입형 업무 환경 조성
  • 메신저/회의/대화 등은 인터럽트를 발생시킬 수 있다.
  • 최대한 업무 관련 내용은 이슈 트래커를 활용해서 처리해야 한다.
  • 이슈 트래커를 통해 개발자 본인이 자신의 일정을 관리할 수 있도록 해줘야 한다.
  • 개발자들에 대한 관리가 아닌 지원을 해줘야 한다.
  • 메신저 같은 업무나 문의사항 같은 것들이 왜 개발자들이 민감해하는지 회사를 다니면서 많이 느낄 수 있었다. 자신의 흐름이 끊기게 되는데, 무시하지도 못하는 상황이다.

 

• SCRUM
  • Agile 계열로, 개발 조직과 개발 절차에 대해 정리한 방법론으로, 전통적인 개발 방법론과 차이가 있다.
  • 구성 : 역할(Roles) + 절차(Process) + 시각화 도구(Tools)
  • 돼지와 닭 : 이해관계와 책임 및 경중과 관련해서 구분된다. 닭은 헌신하지 않기 때문에 발언권이 없으며, 돼지가 SCRUM을 구성하는 역할이 된다.
  • 돼지가 맡을 수 있는 역할은 (스크럼 팀/제품 책임자/스크럼 마스터)로 구분된다.
    • 제품 관리자
      • 제품 기능 목록(Backlog)을 관리한다.
      • 기능 목록에서 우선순위/중요도를 산정한다.
      • 단, 진행 중인 스프린트의 우선순위는 변경이 불가능하다.
    • 스크럼 팀
      • 일정을 추정하며, Backlog에서 스프린트 기간만큼의 기능을 가져온 것(스프린트 구현 목록; Sprint Backlog)을 개발한다.
      • 실제 개발자(+디자이너 등)로 이루어져 있다.
      • 스프린트 기간 내의 몰입을 제공받아야 한다.
      • 스프린트 기간 동안 설계/구현/테스트된 기능은 제품 증가분으로 추가된다.
    • 스크럼 마스터
      • 스크럼 팀과 제품 관리자 사이에서 중재해주는 역할로 보면 된다.
      • 스크럼 팀을 지원하면서, 제품 관리자를 도와 좋은 제품이 되게 돕는다.
  • 역할을 나누는 이유는 요구사항의 변덕을 최소화시킬 수 있기 때문이다.
  • SCRUM에서 하나의 반복 주기(Sprint) 동안에는 요구사항이 동결된다.
  • 초기 요구사항은 뜬 그룸일 수 있다. 이 부분에서 Agile 계열인 것을 알 수 있다.

 

• SCRUM 공식 회의는 불필요한 과정을 최소화한다.
  • 계획 회의
  • 일일 회의 : 어제 한 일/오늘 할 일/장애 요소 관련해서 간단하게 진척도 공유
  • 리뷰 회의
  • 회고 회의

 

• 지속적 통합 Continuous Integration
  • 사내 표준을 만들어서 적용해야 한다.
  • 귀찮음은 그냥 싫은 거고, 불편함은 표준이 습관이 될 것이기 때문에 문제가 되지 않는다.
  • 외부 라이브러리 사용하는 것조차도 표준으로 채택된 것만 사용해야 한다.
  • CI 원칙
    1. 잘 돌아가는 코드는 건드리지 말아라
    2. 신규 프로젝트는 적용해라
    3. 진행 중인 프로젝트에서 일관성 있는 스타일이 있다면, 그 스타일을 유지해라
    4. 진행 중인 프로젝트에서 일관성 없다면, 점진적으로 적용해나가라.
    5. 외부 라이브러리는 제외한다.
    6. 신규 프로젝트에서 기존의 것들을 사용한다면 제외해라.

 

• 문서화의 3원칙
  1. 현재 작업과 미래 작업에 도움이 되어야 한다.
  2. 항상 최신 버전으로 업데이트 가능해야 한다.
  3. 위 2원칙을 만족하지 못하면 만들지 말 것.
     • 정말 공감되었다. 우리 회사는 문서가 낭비되는 경우가 많지 않은가 싶다. 제대로 만들고 제대로 활용하는 문서들이 많아져야 된다. 공수만 낭비되는 문서는 쓸모없다.

 

• 디버깅 시간이 테스팅 시간보다 길다면, 그건 나쁜 개발자라는 증거다.
  • 디버깅은 테스팅으로 대체되어야 한다.

 

• 개발자의 평가 기준은 개발 속도가 아닌 품질(제품 신뢰성)이 되어야 한다.

 

• TDD/단위 테스트가 부담스럽더라도, 유지보수 기간을 줄이고 신뢰성을 높이는 것이 오히려 생산성이 증가되는 것이다.

 

• XP 개발 방법론 적용을 위해선, TDD와 유닛 테스트만이 용기를 줄 수 있다.

 

• UI 없이도 테스팅이 가능하다.
  • 컴포넌트/클래스/함수 단위 또는 클래스 간 통합 테스팅도 가능하다.

 

• 테스트 관련 문서는 TDD로 대체 가능하다.
  • DB/아키텍처/설계 문서 못지않게, 테스트 관련 문서는 입력 상태별 결과를 알 수 있어 유지보수 시 요긴하게 사용될 수 있다.
  • 시나리오별 TCL 문서는 어차피 개발자가 일일이 입력을 통해서 재확인해야 해서 비효율적이다.
  • TDD/단위 테스트는 테스트 결과를 이용해서 테스트 관련 문서를 쉽게 만들 수 있다.

 

• TDD는 테스트 코드를 대상 코드보다 먼저 작성하는 방법이다.
  • 테스트 코드를 통과하는 대상 코드를 작성해야 한다.
  • 통과 시 다음 테스트/대상 코드를 반복해서 작성해나간다.
  • 점차적으로 테스트 코드가 촘촘해지게 된다.

 

• 소켓 통신 프로그램에서의 TDD
  • 외부 자원에 대한 테스트이기 때문에 어려울 수밖에 없다.
  • 그런, 외부 자원의 예외 동작까지 시나리오에 추가해야 한다.
  • 모의 객체(Mock)를 대부분의 단위 테스트(ex. CppUnit)에서 제공하기 때문에 직접 연결을 하지 않고도 테스트가 가능하다.

 

• DB TDD
  • DbUnit/Fixture은 DB를 TDD로 가져올 수 있도록 도와준다.

 

• UI TDD
  • MVC(Model-View-Controller) 패턴에 따라 잘 분리된 경우에는 Model과 Controller에 대해 TDD를 적용할 수 있다.
  • View는 TDD보다 육안 검사가 더 꼼꼼할 수 있다.
  • MVC 패턴이 아니라면, TDD보다는 테스트 자동화에 대해 더 집중하는 것이 맞다.

---

추천 서적

※ 책 안에서 항목별 추천하는 책이다.

• 리팩터링
  • Refactoring 리팩터링 : 나쁜 디자인의 코드를 좋은 디자인으로 바꾸는 방법 (원서: Refactoring)
  • 패턴을 활용한 리팩터링 (원서: REFACTORING TO PATTERNS)
• TDD
  • 테스트 주도 개발:Test-Driven Development
  • 고품질 쾌속 개발을 위한 테스트 주도 개발
• 서브버전(SVN)
  • 서브버전을 이용한 실용적인 버전 관리
  • Subversion 사용 HOWTO (http://www.pyrasis.com/main/Subversion-HOWTO)
• 관리자
  • SI Project 전문가로 가는 길 (필독)
  • 익스트림 프로그래밍 2판 (필독)
  • 글로벌 소프트웨어를 꿈꾸다 (필독)
  • 조엘 온 소프트웨어 : 유쾌한 오프라인 블로그 (필독/완독)
  • More Joel on Software 조엘 온 소프트웨어를 넘어서 (참고)
  • 겸손한 개발자가 만든 거만한 소프트웨어 (참고)
  • 소프트웨어 개발의 모든 것 (필독/완독)
• SCRUM
  • 스크럼과 XP: 애자일 최전선에서 일군 성공 무용담
  • 스크럼 Scrum : 팀의 생산성을 극대화시키는 애자일 방법론
• 다른 책들은 생략!