[책] 소프트웨어 장인

감상평

소프트웨어 엔지니어로서 뽕을 심어주는 책. 책에서 다루는 안티 패턴들이 대부분 내가 행하던 행위들이라고 느껴져 부끄러움과 한편으로 성장해나가야 할 것들이 많다는 것에서 나오는 즐거움이 교차하였다.
솔직히 개발을 어느 정도 하다보면 더 나은 소프트웨어 엔지니어링을 위한 개념들에 대해 어느정도 인지는 하고 있었다.
- 코드 레벨에서, 테스트 코드는 필수이며 주기적인 리팩토링을 통해 레거시 코드 + 잠재위험요소를 줄이는 일이 필요하다는 것.
- 또 개발자라는 한 명의 프로로서 오너십을 가지고 주어진 것만 해야 하는 것이 아닌, 본인이 주체적으로 의사결정에 참여해야 하고 거기서 나오는 모든 과정(문서화, 일정 산정, 일감 관리)도 책임을 저야 한다는 것
하지만 인지한다는 것고 행동한다는 것은 엄연히 다르다는 생각을 요새 들어 많이 느낀다. 나는 생각과 행동보다 입과 손가락이 먼저 움직이고 있었다는 것을.. 전문가이자 프로라고 하는 것에는 많은 책임감과 의식적 노력이 필요하다는 것을 깊게 느끼고 있다.
책에서 강조한 기술적 실행 관례를 잘 지키는 개발자를 실력 있는 개발자라고 부를 수 있을까?
TDD, CI, PP(Pair Programming)같은 관례는 결국 더 나은 제품을 개발하기 위한 하나의 테크닉이자 도구이다. 이걸 현재 환경에서 왜 적용해야 하는지 정확히 알고 있는 것이 중요하다. 또한 이론에 입각한 이상적 결과가 아닌 어떤 사이드 이펙트가 있는지, 관례의 과정 중 포기해야할 것과 지켜야할 것을 명확하게 하는 것도 중요하다고 생각이 들었다.
- 결국 이론을 잘 아는 것과 실천 + 문화로 자리매김시키는 것은 완전히 다르다는 것이라는 것. 입개발은 이제 그만하고 더 잘해지고 싶다....!!

책 정리

1-2. 21세기의 소프트웨어 개발 애자일

애자일 매니페스토

- 절차와 도구 보다는, 개성과 화합을
- 방대한 문서 작업보다는, 동작하는 소프트웨어를
- 계약 조건에 대한 협상보다는, 고객과의 협력을
- 계획을 따르는 것을 넘어서서, 변화에 대처하는 것을

20세기에는 사람들이 이해할 수 없는, 난해한 코드가 개발자 실력의 척도가 되었다(남들은 쉽게 이해할 수도 짤 수 없는 코드를 나는 짠다) 그러나 인터넷의 발전으로 지식과 오픈소스를 쉽게 접할 수 있었고 결과적으로 ‘나’만 알 수 있는 코드를 짜는 것의 가치는 떨어졌다.
애자일이 다루는 근본적인 문제는 소프트웨어 프로젝트는 변화 자체가 기본 속성 이라는 점이다. 그래서 이런 변화에 민첩하게 대응할 수 있도록 하는 방법론이자 테크닉들을 제시한다.
- 애자일은 문제를 드러나게 해준다
- 절차적 관점
  - 회의 방식
  - 구성원 각각의 역할
  - 요구사항 파악 방법
  - 작업 진척 속도 파악 법
  - 점진적/반복적으로 일할 때 취하는 방식
  - 진행 상황을 외부에 전달하는 방식
  - 비즈니스 피드백 방식
- 기술적 관점
  - 개발, 확장, 유지보수, 제품 출시에서 겪는 어려움에 대한 기술을 구체적으로 기술한다.
  - 이를 통해 소프트웨어의 품질에 집중해 결과물을 올바르게 인도하고 있는지, 목표한 것을 올바르게 실행하고 있는지 안심할 수 있게 한다.
애자일을 따른다는 것이 문제를 해결한다는 행위는 아니다. 대신 .
애자일이 나타남에 따라 개인이 맡게 되는 롤은 자연스럽게 늘어났다. 코딩을 하는 것은 당연한 것이며, 이에 더불어 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요해졌다.
- 계획, 요구사항 분석, 아키텍처, 제품 릴리즈, 시연, 주기적 피드백 받기(이해관계자)
애자일의 도입이 절차적 개선에만 집중되면 안 된다.
- 많은 기업들이 표면적으로 애자일을 도입한다고 하지만 크게 변하지 않았다고 한다. 개발 절차를 바꾸는 데 집중하고 막상 더 높은 품질의 소프트웨어를 개발하는 것에 관심을 두지 않는다고 한다. 애자일에서는 모든 절차의 개선에 앞서 기술적 탁월함이 전제되어 있다.
- 완전한 애자일 전환을 위해선 결국 프로페셔널한 개발자가 필요하다. 이들은 기술적 실행 관례, 기술적 전문성 그리고 관련 도구들을 마스터하고 있어서 소프트웨어의 품질을 높일 수 있어야 한다.
피드백 시스템
- 피드백 시스템이 제대로 동작하기 위해선 뭔가 잘못됐을 때 혹은 개선할 방법이 있다고 목소리를 당당히 내는 프로들이 있을 때 가능하다.

3. 소프트웨어 장인정신

소프트웨어 장인정신 매니페스토

소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발 수준을 높인다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨있게 만들어진 작품을
변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

소프트웨어 장인정신은 소프트웨어 개발자가 스스로 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 자부심을 의미한다.

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨있게 만들어진 작품을
- 좋은 소프트웨어라면 그 애플리케이션이 얼마나 오래되었든 개발자가 쉽게 이해할 수 있어야 한다. 즉 소스코드는 예측가능하고 유지보수될 수 있어야 하며 제공하는 비즈니스와 잘 결합되어 도메인 파악이 용이해야 한다.
변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
- 소프트웨어가 나이를 먹으면서 덩치가 커진다면, 동시에 기업의 이익(비즈니스적 가치)도 늘게 해야 한다.
- 유지보수 비용이 높은 애플리케이션이 되지 않도록 한다(테스트, 리팩토링 etc)
개별적으로 협력하는 것뿐만 아니라 프로페셔널 커뮤니티를 조성하는 것을
- 상대에게 배우는 것은 더 나아지기 위한 최선의 방법
- 오픈소스 기여, 커뮤니티 참여, 페어 프로그래밍하기 등의 방법으로 업계의 발전에 기여한다
고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를
- 고용&피고용 계약 관계 위로 파트너쉽과 프로페셔널한 행동을 둔다.

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

내 커리어의 주인은 나다. 돈을 받고 정당한 가치를 제공해야 하는 계약 관계를 뛰어 넘어서 프로로서 내 시간을 투자한다고 생각하는 마음가짐이 중요하다
끊임 없는 자기개발
- 특정 주제나 기술을 이해할 때 책만한 것이 없다.
- 프로페셔널의 블로그를 잘 구독해두고 지속적으로 팔로우하자. 그리고 이들이 하는 이야기와 주장에서, 해당 배경을 이해하려고 노력하자.
- 끊임 없이 훈련해야 한다. 훈련의 경우 문제 해결 자체에 집중하기 보단, 문제 해결에 사용되는 테크닉에 집중하도록 한다. 코딩을 할 때는 최선의 코드를 만드는 데 집중하자.
  - 똑같은 문제를 다양한 각도에서 풀어보기
오픈 소스
페어 프로그래밍
- 물론 개발자들은 상당 수준의 지적 역량이 있기에 뭐든 배울 수 있다. 하지만 중요한 건 ‘시간’, 그리고 혼자에게만 의존하면 자신의 좁고 편향된 생각에 벗어날 방법이 없다.
무지의 단계
- 무지의 수준을 낮출수록 업무 생산성과 효율이 높아진다(한 번 진행한 프로젝트를 다시 해본다고 생각해보라)
- 모르고 있다는 것을 인지하지 못한 상태에서 벗어나기 위해선, 현재 처한 상황과 관련해서 지속적으로 새로운 사실을 익힐 수 있도록 스스로를 노출시킨다.
- 우리가 파악하지 못한 것을 찾아내기 위해 시간을 투자해야 한다.
시간 만들기
- 새로운 것들을 접할 수 있는 시간을 꼭 보유하라. 바쁘다는 건 핑계
- 뽀모도로 기법으로 중간중간 쉬는 텀에 기록할 수 있는 시간을 주는 것도 좋은 방법

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

주어진 것에 최선을 다하려는 행위는 프로페셔널의 충분조건일 뿐. 일을 할 때는 왜 그 일을 하는 스스로에게 물어야 한다. 내 일은 남이 아닌 내가 책임지고 한다는 자세가 필요
프로젝트의 성망 책임은 PM 뿐만 아니라 개발자에게도 동일하게 부여된다. 영웅이 될 수 있다는 망상에 잡히지 말고 ‘아니오’라고 이야기할 수 있는 프로다움도 필요하다.
‘아니오’라고 대답해야 하는 상황에서도 항상 ‘네’라고 이야기할 수 있는 방안을 탐색해야 한다. 상사가 어떤 백그라운드 없이 문제 해결 방법을 찾으려 할 때 문제 상황과 대안들을 잘 제시해줄 수 있어야 한다.
현명한 관리자
- 현명한 사람은 자신이 모든 것을 알 수 없다고 안다.
- 팀원 모두가 같은 배를 탔다는 공동체 의식을 줄 수 있도록 팀과 동고동락해야 한다.

6. 동작하는 소프트웨어

프로그래밍은 집을 짓는다기 보다는 정원을 돌보는 것에 더 가깝다

깨끗한 코드만으로 프로젝트를 성공시킬 수 없다. 그러나 소프트웨어 프로젝트에서 소스 코드 그 자체 만큼 중요한 것은 없다. 나머지는 부차적이다.
애자일에서 이야기하는 동작하는 소프트웨어는 짧은 주기로 릴리즈&피드백이 이뤄지고 진척도를 가늠하는 주된 기준이다. 그러나 시간이 지나면서 고품질 이라는 전제가 붙게 된다.
코드의 품질과 기능 구현 시간은 반비례다. 코드의 품질을 신경 쓸 시간이 없다는 사람은 보통 기능 구현을 하는데 더 오랜 시간을 들이고 있다는 점.
개발자들은 의도적으로 나쁜 코드를 작성하진 않지만, 왜 이렇게 됐는지 핑곗거리를 찾는다. 항상 시간에 쫓긴다고 생각하다 보니 실제 외부적인 상황보다 더 스스로를 쫓긴다고 판단한다(...난가...)
개발자의 대부분의 시간은 코드를 읽는 것 + 이슈&버그픽스에 포진되어 있다. 즉 이 시간을 줄이기 위해선 가독성이 높은 코드를 작성해야 하고 테스트를 통해 디버깅하는 상황을 만들지 않아야 한다.
- 테스트 코드를 작성하지 않는다는 것은 굉장히 이기적이라고 할 수도 있다. 자신의 작업 시간만 생각하고 전체 프로젝트에 관계된 다른 사람들이 시스템을 테스트하고 디버깅하느라 얼마나 많은 시간을 소모해야 하는지는 생각하지 않는다고 볼 수 있기 때문에
레거시 코드를 봤을 때, 마음에 들지 않는다면 리팩토링하자. 그걸 바꿀 수 없다면 이에 대한 생각을 바꾸자.
- 작은 부분씩 집중해서 점진적으로 개선해야 한다. 큰 덩어리로 보면 엄두가 나지 않는다.
- 덩어리를 작은 조각으로 나눠서 점진적으로 이를 진행하다 보면 코드에 대한 전체적인 그림을 보기 쉬워지며 업무 진척도 빨라진다.
- 재미있고 도전적인 관점에서 레거시 코드를 바라보는 것도 방법이다.

7. 기술적 실행 관례

애자일의 절차적 실행 관례는 애플리케이션의 품질을 알지 못한다는 점을 보완하기 위해 기술적 실행 관례에 집중할 필요가 있다.
익스트림 프로그래밍
- 켄트 백은 1980년대에 수백억 규모의 프로젝트를 진행하면서 XP의 기술적 실행 관례들을 적용했고 결과적으로 제품의 버그가 1/3로 줄어들고 디버깅시간을 줄이고 생산성을 10배까지 끌어올림
- 애자일로 전환에서 XP 실행 관례가 무시되면 실패로 이어질 확률이 높음
- 코어한 관례
  - TDD
  - 지속가능한 통합
  - 페어 프로그래밍
  - 리팩토링

실행 관례가 효율적이기 위해선 모든 팀 구성원들에 의해 그 가치가 납득되어야 한다.
- 모든 팀 구성원은 원활한 정보 소통, 빠른 피드백, 빠른 결과물 생성, 실수 예방, 고객 만족, 배우지 못하는 것에 대한 부끄러움 느끼기 같은 부분에 가치를 둘 수 있어야 한다.
기술적 실행 관례를 도입할 때 현재 일하는 방식과 비교해 이것이 가져올 이익에 집중해야 한다.
- 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 자동화와 릴리즈가 빨라짐 같은 이점이 있음.
- 결과적으로 기술적 실행관례를 도입하면 큰 비즈니스적 가치를 가진다.
도입
- 개발자도 의사결정에 책임감을 가져야 한다. 특정 실행 관례를 따르지 못하도록 할 때 이에 대한 책임감이 있다.
- 누군가가 이야기했기 때문에, 또는 그 실행 관례 도입을 위한 도입을 해서는 안 됨. 즉 절대적인 진리로 바라보면 안 됨
- 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 다른 걸 시도해볼 시점인가? 같은 질문들을 던져봐야 함
- 실행 관례를 비교할 때 가장 좋은 방법은, 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해보는 것이다.
- 항상 특정 실행 관례가 가치를 주고 있는지 점검해야 하며, 가치가 없다면 버려야 한다.
- 설득
  - 직접적으로 관례를 도입하자고 하기보단, 비즈니스 적 가치(빠른 기능 배포, QA 인건비 절감, 버그 탐지/개선 )에서 접근하는 게 좋다.

13. 배움의 문화

개발자들의 동기부여와 열정을 주입하기 위한 좋은 촉진제 중 하나는 배움의 문화
관리자들은 개발자들에게 명령이 아닌, 권한을 위임하고 스스로 배움의 문화를 만들어갈 수 있도록 복돋워야함.
북 클럽 진행하기
- 책을 하나 선택해서 관심있어 하는 사람들과 모여서 책의 내용 공유하고 대화하기
- 일과시간에만 하기보단 점심시간이나 일과시간 일부를 포함해서 하는 게 나아보임.
그룹 코드 리뷰하기
- 코드 리뷰를 그룹 차원에서 하면 모두가 리뷰에 이뤄진 결정에 책임감을 느끼고 더 좋은 품질을 만들어낸다. 즉 하나의 컨센서스(합의)를 이뤄내는 것
- 올바르게 수행한다는 것
  - 비난이 아닌, 미래를 변화시키는 것에 집중하기
  - 주석은 객관적이고 생산적이어야 함.
  - 큰 진전을 이룬다고 기대하기 보단, 조그마한 변화들이 점점 쌓여 합의가 된다고 바라보기
아무도 참여하려고 하지 않는다면?
- 먼저 모범을 보이기. 스스로 하지 않으면서 다른 사람을 설득하려고 하지 마라. 먼저 모범을 보이자.
- 관심을 보이는 사람들에게 집중하기. 모두를 변화하려고 하기 보단 소수에게 집중하면, 그 소수가 더 나은 변화를 만들어 갈 수 있다.
- 허락을 구하지 말아야 할 때를 알기. 다들 컨센서스가 어느정도 있는 상황에서 하나하나 물어보기보단 하겠다고 공표하는 게 맞을 수도 있음.

15. 실용주의 장인정신

애플리케이션을 수작업으로 테스트하는 것은 비용과 시간이 점점 커지고 지속적 통합도 불가능해짐.
처한 상황과 맥락을 고려해서 실행 관례를 선택해야 한다. TDD도 항상 필요하지 않을 수 있음(테스트가 필요없는 상황 혹은 비용이 엄청 비싼 상황)
특별한 이유 없이 코드를 열어 리팩토링을 하는 것은 비실용적임
개발자들은 비즈니스 담당자들과 직접 대화하면서 질문하고 솔루션을 제안하면서 한 팀처럼 움직여야 한다.
비범한 개발자와 평범한 개발자의 차이
- 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들고 다른 개발자도 쉽게 이해할 수 있도록 만듬.
- 비범한 개발자는 코드 한 줄 짜지 않고 문제를 해결할 수 있는 방법을 찾는다. 잘 작성된 코드는 단순하고 작고 테스트 가능하고 이해하기 쉽다(명료)
단순한 설계를 위한 4가지 원칙
1. 모든 테스트의 통과
2. 중복의 최소화
3. 명료성의 최대화
4. 구성요소의 최소화
- 중복 제거보단 명료함을 우선시 함
패턴을 위한 리팩토링
- 테스트 코드는 비즈니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것이 아님.
- 패턴이 먼저가 아님. 좋아하는 패턴에 문제를 맞추기 전에, 문제에 적합한 리팩토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 함. 그다음 리팩토링으로 만들어진 솔루션이 디자인 패턴과 거의 동일하다면 그 패턴을 지향하도록 리팩토링하기
- 범용 커드는 확장성은 좋을지라도 복잡성이 높아짐. 무조건적인 범용 코드 추구보단, 주어진 문제에 특정된 코드로 솔루션을 찾고 나중에 필요한 상황이 생겼을 때 범용화하는 게 좋다.
실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족(품질, 시간, 비용은 고객 만족을 위한 구성요소에 불과함)