소프트웨어 장인 - 글 메모 (작성중)

<소프트웨어 장인> - 산드로 만쿠소 지음, 권오인 옮김

• 애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다.
  - 관리자들이나 역량이 부족한 애자일 코치들은 기술적 수준이 개선되어야 함을 자주 무시 한다. 애자일 전환은  주로 절차 , 동기부여와 권한 이양 관료주의와 낭비의 제거, 우선순위, 업무의 가시화, 그리고 정보의 흐름에 집중한다.
  - 이러한 것들은 실재하는 매우 중요한  문제들로 제대로 개선된다면 기업의 역량이 한 층 높아질 수 있다. 이러한 문제들을 그대로 두면 소프트웨어 프로젝트를 성공시키는 것은 불가능하다.
    -  2장 애자일 > 애자일 행오버 > 부분적인 전환 중

 

• 보이스카웃에는 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라는 규율이 있다. 이는 소프트웨어 에도 똑같이 적용할 수 있다. 코드도 처음 발견했을 때보다 더 깨끗하게 관리해야 한다.
  - 3장 소프트웨어 장인정신 > 소프트웨어 매니페스토 > ‘변화에 대응하는 것뿐 아니라, 계속해서 가치를 더하는 것을’

 

• 우리는 고용자-피고용자 형태의 관계를 믿지 않는다. 계약서에 뭐라고 되어 있든 형식적인 문서일 뿐이다. 파트너십과 프로페셔널한 행동을 계약의 위계보다 상위에 둔다. 당신이 정규직이라면 고용주를 고객처럼 대해야 한다. 계약직이나 컨설턴트여도 마찬가지다.
  - 소프트웨어 장인정신 > 소프트웨어 매니페스토 > ‘고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를’

 

• 오늘날 우리는 계속해서 늘어만 가는 정보 속에, 계속해서 줄어만 가는 의미를 목도하는 세상에서 살고 있다.
  - 장 보드리아르 Jean Baudrillard

 

• 코딩 카타 웹 사이트
  - codingkata.org
  - codekata.pragprog.com
  - kate.softwarecraftsmanship.org

 

• 개발자 대다수는 긍정적이고 낙관적이다. 일의 작업량을 예측할 때 얼마나 많이 틀리는지를 보면 알 수 있다. 실제로 소요된 작업량과 원래 예측했던 작업량을 비교해보면 거의 대부분 예측보다 훨씬 긴 시간이 걸렸다.
  
  계획대로 안 될 가능 성이 매우 높다는 것을 인정해야 한다. 무언가 예상하지 못한, 예상할 수가 없는 문제가 항상 발생한다. …
  이러한 문제를 완벽하게 해결할 수는 없지만 영향을 최소화하도록 노력할 수는 있다. 한 가지 방법은 현재 처한 상황과 관련해 새로운 사실들을 계속 익히도록 스스로를 노출시키는 것이다.
  무지는 상수다. … 무지를 낮출수록 업무 생산성과 효율이 매우 높아진다.
  - 소프트웨어 장인의 태도 > 의도한 발견

 

• 한 주에 하루 정도는 출근 전에 카페에서 한 두 시간 동안 자기계발을 해보자. 코드를 작성하거나 기술 문서를 읽거나 블로그에 글을 올리는 등 새로운 것을 배우고 커리어에 도움이 된다고 생각하는 일들을 하자.
  회사에서는 자꾸 일에 신경을 쓰거나 동료의 방해를 받기 쉽다.
  - 소프트웨어 장인의 태도 > 시간 만들기

 

• 요구받은 거의 모든 것들을 힘겹게 완료했지만 그 누구로부터의 설명도 없이 그냥 일정이 늦춰져버렸다. 우리가 노예처럼 일할 때 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다. 우리는 영어팀과 비즈니스 팀을 위해 헌신한다고 생각했지만 당사자들은 실상 아무런 생각도 없었다. … 
  
  그 당시에는 그런 것들을 몰랐다. 오히려 그 부담이 좋았다. 우리 팀에는 실력있는 동료들이 가득했고 그들과 함게 일할 수 있다는 것이 기뻤다.
  
  우리는 일을 잘못하고 있었다.
  
  - 소프트웨어 장인> 영웅, 선의 그리고 프로페셔널리즘

 

• 우리가 ‘아니오’라고 하지 않고 우리의 관리자들에게 투명하지 않았다면 어떻게 되었을까? 아마도 영웅이 되기 위해 모든 개인 시간을 쏟아붓고도 요구사항 몇 가지는 충족시키지 못해 회사에 큰 손실을 입혔을 것이다. 
  ‘아니오’라고 말함으로써 우리의 생각을 자유롭게하고 
  다른 방법들에 집중할 기회를 만들어 대안을 찾아서 적용할 수 있게 되었다.
  - 소프트웨어 장인> 영웅, 선의 그리고 프로페셔널리즘 > 뜻밖의 실용적인 대안
  
  
• 레거시 코드를 다룰 때는 끙끙 앓으면서 상스런 말을 내뱉는 대신 그것을 이해하고 개선하려 노력해야 한다. 보이스카웃 규칙 ‘ 처음 발견했을 때보다 더 깨끗하게’를 지속적으로 적용해야 한다.
  - 동작하는 소프트웨어>레거시 코드 > 태도의 변화
  
  
  
• 레거시 코드로 일하는 것은 거대한 직소 퍼즐을 푸는 것과 비슷하다. … 각 조각을 그룹으로나누고 모서리나 경계선부터 시작해야 한다.조각들을 색상이나 패턴을 기준으로 분리해서 모아두어도 도움이 된다. … 
  
  즉, 점진적으로 기존 코드에 대한 테스트 코드를 작성하면서 코드에 대한 이해도를 높이고 리펙토링을 해나간다.
  - 동작하는 소프트웨어>레거시 코드 > 태도의 변화
  
  
  
• 지속적인 통합은 TDD와 함께 수행되어 이러한 피드백 루프를 단 몇 분으로 줄일 수 있다. 개발자가 코드를 올릴 때마다 전체 테스트 슈트가 실행되고 테스트가 실패하면 이메일이 모든 팀에 전달된다.
  
   이러한 실행 관례는 ‘일단 멈추고 버그부터 수정한다’는 태도가 필요하다. (...) 
  
  시스템이 항상 배포 가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다는 장점이 있다. 
  - 7장 기술적 실행 관례 > 지속적인 통합
  
  
• TDD는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다. 
  또한 살아움직이는 문서 역할을 한다. 
  더불어 긍정적인 부가 효과로 회귀 테스트 역할도 해준다. 
  이러한 것들이 TDD가 주는 비즈니스적인 가치다.
  - 7장 기술적 실행 관례> 테스트 주도 개발
  
  
•  엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. (...) 
  지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로인해 비즈니스도 느려진다.
   레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 이럴 때는 수정되는 부분에 한정해서 리팩토링을 집중하는 것이 더 나은 접근 방법이다.
   
  실용주의적 관점 없이 리팩토링하는 것은 대단히 위험하다. 프로페셔널로서 행동한다는 것은 트레이드오프를 이해한다는 것이다. (...) 몇 년 동안 바뀐 적이 없는  부분을 리펙토링하는 것은 의미가 없다.
   유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다. 이것이 리펙토링의 비즈니스적인 가치다.
  - 7장 기술적 실행 관례 > 리팩토링
  
  
  -161p까지 읽음