심플 소프트웨어 : 엔지니어링 팀에서 일하기

5부 엔지니어링 팀에서 일하기

[개발자 생산성 측정하기]

• 코드의 단순성과 관련된 부분부터 점검한다. 개발하자 하는 다른 일을 사사건건 측정하는 건 그다음이다.
• 소프트웨어 엔지니어링과 관련된 좋은 관행을 실천하는 문화를 조성하는 것만으로도 생선성이나 개발과 관련된 문제가 대부분 사라진다.
• 사실 생산성 측정은 엄청나게 큰 가치를 지닌다. 생산성을 측정하면 준제가 발생한 영역, 생산성이 개선된 영역을 정확히 가려내어 생산성이 좋아진 이들에게 보상을 할 수 있다. 그리고 개발자 생산성을 개선하기 위해 노력하면 이외에도 많은 소득이 따른다.
• 그러나 프로그래밍 분야는 다른 직군과 다르다. 생산성을 제조업 분야의 생산성을 측정하는 방식으로 측정할 수는 없다.
• LOC(lines of code)를 생산성의 기준으로 삼겠다는 시도가 꾸준히 존재했다. 그러나 잘못되었다. 컴퓨터 프로그래머는 목수처럼 직업이 아니라 기술이다. 기술 사용 빈도는 생산성을 측정하는 기준이 될 수 없다. 생산성을 확인하려면 그 기술로 생산한 제품을 측정해야한다.
• 가장 먼저 프로그램이 사용자에게 어떤 가치를 제공하는지부터 알아내야한다.
• 팀에 생산성 개선을 돕는 사람이 있다면 시간이 지나면서 팀원들이 체감하는 생산성 개선 정도를 측정하면 된다. 그게 어렵다면 팀의 생산성 지표가 개선된 비율을 측정하면 된다.
• 이외에도 직원, 팀, 회사의 생산량을 측정하는 방법에 대해 알아야 할 내용이 많다. 올바른 측정방법, 측정 결과 해석, 적절한 측정 기준 고르기에 대해서도 더 알아야 한다.

[소프트웨어 회사에서 코드 복잡성을 다루는 법]

• 코드 복잡성을 해결하려면 한사람 수준의 섬세한 작업이 요구된다.
• 관리자가 코드를 단순하게 만들어라 라고 말하는 것만으로는 아무 변화가 없다.
  • 관리자의 지시가 구체적이지 않다.
  • 코드의 각 부분에 대해 구체적인 지시를 내릴 정보의 지식이 관리자에게 없을 수 있다.
  • 문제를 해결하는 과정에서 문제에 대한 이해가 더 깊어지는 측면도 있다. 하지만 관리자는 문제를 직접 해결하지 않는다.
• 코드 복잡성 관련 문제 대부분은 각 프로그래머가 섬세하게 작업해야 하는 소규모 프로젝트로 해결해야 한다.
  
  
• 1단계 : 문제 목록
  • 각 팀원에게 코드에서 가장 답답하다고 느끼는 부분을 목록으로 정리하게 한다.
• 2단계 : 회의
  • 팀 회의를 열고 코드베이스에 접속할 수 있는 컴퓨터와 각자 만든 목록을 가져오게 한다. 회의의 규모는 6~7명 정도가 적당하다.
• 3단계 : 버그 리포트
  • 회의에서 수집한 정보를 바탕으로 언급된 디렉터리, 파일, 클래스 등에 대해 문제를 묘사하는 버그 리포트를 작성한다.
• 4단계 : 우선순위 선정
  • 우선 어떤 문제가 개발자를 많이 괴롭히는지 알아내라. 순위를 매기는 작업은 보통 관리자가 맡는데 회사나 팀에 속한 여러 개발자를 폭 넓게 볼 수 있는 사람이 하기 적한한 일이기 때문이다.
• 5단계 : 과제
  • 각 작업에게 버그를 할당한다. 단, 다른 팀이 담당하는 코드가 버그에 포함되는 경우라면 좀 까다롭다. 이 경우 문제 해결 책임을 분담해야할 팀을 찾아 적절히 협업해야 할 것이다. 너무 복잡한 문제가 아니라면 다른 팀의 영역이 일부 포함된 문제라고 해도 직접 수정할 권한을 주는 회사들도 있다.
• 6단계 : 계획
  • 모든 버그를 정리한 후 언제 고칠지 정해야 한다. 일반적으로 개발자 각자가 사진의 일반적인 업무를 하는 중간에 코드 품질 문제도 정기적으로 손보게 하는게 좋다.
    
    

[리팩토링 할때는 기능에 주목하라]

• 코드 정리는 제품을 개선하기 위해서 한다
• 리팩토링은 본질적으로 조직적인 절차다. 리팩토링을 위한 리팩토링을 한다면 리팩토링의 이름에 먹칠을 하는 것이나 다름없다.
• 리팩토링을 위한 리팩토링이란 현재 작업 중인 코드와 아무 상관없는 코드의 한 부분을 보다가 이 부분 설계가 마음에 들지 않는데? 라며 시스템 기능과 전혀 상관없는 코드 일부를 이리저리 옮겨보는 걸 말한다.
• 복잡한 코드베이스를 정리하는 핵심 원칙은 항상 기능을 위해 리팩토링 하라는 것이다.
• 일단 시간이 지날수록 시스템이 더 나빠지지 않도 더 나아지는 상태로 만드는걸 첫번째 목표로 삼아라.
• 리팩토링을 하면 시간이 절약된다.
  • 리팩토링을 한 뒤에 기능을 개발하면 더 많은 시간이 걸린다고 생각할 수도 있는데, 경험상 전체 작업 시간은 비슷하거나 오히려 줄었다. 여기서 전체 작업 시간이란 디버깅, 릴리즈 롤백, 버그픽스 제출, 복잡한 시스템을 위한 테스트 작성 등 작업에 드는 모든 시간을 포함한다.

[간략하게 살펴보는 오픈소스 커뮤니티]

• 오픈소스 커뮤니티를 키우고 유지하려면 다음 세가지 사항에 신경 써야한다.
  • 사람들이 기여에 관심을 갖도록 유도하기.
  • 프로젝트에 진입해서 기여하는데 방해되는 장벽 없애기
  • 꾸준히 기여할 수 있는 기여자 확보하기
• 기여자 유지하기
  • 이탈은 불가피 하다.
  • 기여에 즉시 반응하라
  • 아주 친절한 대도로 눈에 띄게 고마워하라.
  • 사적으로 부정적인 감정을 품지 마라
• 장벽 없애기
  • 쉽게 시작할 수 있는 프로젝트 목록을 만들어라.
  • 소통 채널을 만들고 기록하라.
  • 기여 방법을 환벽하고 정화하게 설명하는 간단한 문서를 만들어두어라.
  • 문서를 쉽게 찾을 수 있게 하라.
• 관심 유도하기
  • 아주 인기있는 제품이 되라.
  • 인기 있는 프로그래밍 언어로 만들어라.