소프트웨어 장인 : 요약

책을 고른 이유

개발 도서 추천을 받고 이것저것 뒤적거리던 중, 휘황찬란한 이론들 속 장인이라는 단어가 눈에 들어왔다.

오버 엔지니어링과 하드코딩 그 사이 어디쯤 서있어야 내실있는 개발자가 될 수 있을지 이 책이 알려줄 것만 같았다.

이 책을 통해 진짜 좋은 제품을 만드는 '장인'들은 어떻게 일하는지, 또 동료 장인을 행복하게 오래 일하게 하려면 어떻게 해야하는지 답을 찾고싶다.

 

챕터4. 소프트웨어 장인의 태도

페어 프로그래밍 : 장인이 되는 길

개발자들은 상당 수준의 지적 역량이 있기 때문에 혼자 배우고 싶다면 무엇이든 배울 수 있다. 문제는 시간이다. 더불어 스스로에게만 의존하면, 자신만의 좁고 편향된 생각에서 벗어날 방법이 없다.

• 페어 프로그래밍으로 얻을 수 있는 것
  • 코드 짜는 즉시 피드백이 들어오므로 새로운 지식을 빠르게 학습할 수 있다.
  • 훌륭한 개발자는 누가봐도 알 수 있는 코드를 작성한다. 페어가 못알아들으면 뭔가 잘못되고 있는 것이다.
  • 내가 아는 것을 구조화해서 가르쳐주고, 역으로 배워야하는 상황도 있다.
  • 전혀 모르는 사람과 하면 효과가 더 좋다고 한다. 독창적인 문제해결방식을 제시받을 수 있다.

 

무지를 아는 것이 중요하다.

• 무지를 모르는 것은 실무에서도 문제가 크다.
  • 무지에 대한 무지는 일정을 추산할 때 항상 걸림돌이 된다.
  • 한번 해본 프로젝트를 다시 만드는 것은 아마 시간이 반으로 줄어들 것이다.
  • 이 불확실성을 해결하기 위해 사용할 것으로 예상되는 기술을 체험해보는 '일정 추산의 일정'이 필요하기도 하다.
• 무지를 없애기 위한 가장 좋을 방법 → 사람
  • 동료 붙잡고 최신 기술 어떻게 따라가는지 물어보기
  • 사용자 그룹 이벤트에 참석하기
  • 내 코드 검토 부탁하기

 

챕터5.  영웅, 선의 그리고 프로페셔널리즘

• 문제 상황 : 무리한 개발을 요구하며 응원만 하는 PM. 매주 추가기능을 가져오면서 듀와 기능은 전혀 양보가 안된다고 말함
• 안좋은 예시 1
  • 야근해서 저품질 소프트웨어 배포하고 1시간만에 터트리고 욕먹기
  • 저자가 속한 팀이 이 전략을 택했다가 개발자들 전원퇴사 엔딩으로 끝남
• 안좋은 예시 2
  • 개발자 중간에 더 투입해서 카오스 만들기
• 좋은 예시 3
  • 마케팅 담당자에게 물어봐서 주요 기능 추산하고, 기능에 우선순위 매기기.
  • PM에게 SW의 안정성과 고객 만족도의 상관관계를 설명하며 설득하기
  • 기본적인 기능 테스트 , 부하 테스트 거치고 배포하기

 

챕터6.  동작하는 소프트웨어

내겐 없는 여유, 누군가에게는 있는 여유

 

애자일의 기본 원칙 : 동작하는 프로그램을 짧은 주기로 여러번 배포

그러나 ‘동작한다’의 기준이 더 엄격해야한다.

기능 구현만 간신히 되어있고, 기능 추가할 때 마다 수작업으로 다시 처음부터 검사해야한다면 이건 동작한다고 볼 수 없다

 

이런 프로그램의 특징 → 처음엔 기능개발 완전 빠르게 되다가 점점 작업속도 + 기능 퀄리티가 저하. 결국엔 버그 투성이 프로그램이 됨.

이는 천재 개발자의 설계 + 무수한 그저그런 프로그래머들 조합이 성공할 수 없는 이유이기도 하다.

 

아래 적혀있는 환경 자동화는 미래의 더 복잡해진 코드를 다룰 나와 동료들을 위한 필수 선택이다

• 단위 테스트 작성
• 별도 테스트 환경 마련 ex) 테스트용 새 도커 컨테이너 빌드
• 프로젝트 개발환경 셋팅 자동화 ex) asdf 등