[Day 11] 소프트웨어 장인 - 03

1부 이념과 태도

1장 21세기의 소프트웨어 개발
2장 애자일
3장 소프트웨어 장인정신
4장 소프트웨어 장인의 태도
5장 영웅, 선의 그리고 프로페셔널리즘
6장 동작하는 소프트웨어
7장 기술적 실행 관례
8장 길고 긴 여정

2부 완전한 전환

9장 인재 채용

10장 소프트웨어 장인 면접하기

11장 잘못된 면접 방식
12장 낮은 사기의 대가
13장 배움의 문화
14장 기술적 변화의 실행
15장 실용주의 장인정신
16장 소프트웨어 장인으로서의 커리어
부록 소프트웨어 장인정신에 대한 오해와 설명

 

---

 

• 애자일 방법론은 변화와 싸우는 것이 아니라 변화 자체를 내재화 한다.
• 코드 베이스의 품질 상태가 비즈니스의 발목을 잡을 정도로 나쁘다는 사실을 깨달았을 때는 이미 많이 늦었을 가능성이 높다.
• 나쁜 코드는 암과도 같다. 처음에는 발견하기 어렵지만 문제로 드러난 이후에는 대응하기가 어렵다.
• 기계적으로 따르기만 하면 문제가 해결되는 단순한 처방전 같은 해결책을 찾는 회사들이 많다.
• 지속적인 통합과 단위 테스트에 많은 집중을 함으로써 프로젝트가 제 궤도를 벗어나지 않게 관리할 수 있었다.
• 중요한 것은 소프트웨어 장인 정신을 심는 것이다.
• 어떻게 하면 팀 또는 관리자 회사에 TDD 나 페어 프로그래밍 같은 것들을 도입하도록 설득할 수 있는가라는 질문을 자주 듣는다... 현재 일하는 방식과 비교해서 그것이 가져올 이익에 집중을 해야 한다.
• 프로젝트가 성공할 확률을 높이기 위해 우리가 할 수 있는 일은 없을까?
• 피드백이 빠르면 문제가 많은 코드 위에 계속해서 코드를 더해서 버그를 양산하고 그 뒷 수습에 드는 시간을 줄일 수 있다.
• 테스트 코드를 먼저 작성하면 코드 작성 완료 후 실제 환경에서 기대한 대로 동작할 것이라고 강하게 확신할 수 있다.
• 테스트 자체가 어려우면 설계를 재검토하고 코드를 더 단순하게 리팩터링하는 긍정적인 원인이 된다.
• 지속적인 통합은 TDD 와 함께 수행되어 이러한 피드백 루프를 단 몇 분으로 줄일 수 있다.
• 리뷰해야 할 코드량은 많고 의견을 말하고 싶은 개발자들도 많아서 몇 시간이 훌쩍 넘어간다.
• 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다.
• 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다.
• 프로젝트의 시작 단계부터 이러한 실행 관례를 받아들여 수행한다면 코드가 점진적으로 상태가 향상되어 리팩토링에 너무 많은 시간을 들이는 일이 없어진다.
• 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다.
• 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다. 이것이 리팩토링의 비즈니스적인 가치다.
• "이러한 가치와 최소한 동등한 수준의 가치를 만들어내기 위해 당신은 혹은 우리는 무엇을 하고 있습니까? 이러한 실행 관례보다 더 나은 방법이 있습니까?"
• 우리의 의사 결정에 책임감을 가져야 한다.
• 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다. 그 결론이 TDD 를 도입하는 것이라면 그렇게 해야 한다. 언제든지 TDD 보다 더 나은 가치와 더 빠른 피드백 루프를 줄 수 있는 다른 것이 있다면 그것을 TDD 대신 도입해야 한다.
• 무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다.
• 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.
• 소프트웨어 장인으로서 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론, 그리고 실행 관례를 선택할 수 있도록 개방적인 사고방식을 가져야 한다.
• 직접적으로 TDD 나 연속된 통합, 리팩토링, 페어 프로그래밍 같은 것을 도입하자고 이야기하는 대신 이렇게 이야기해 볼 수 있을 것이다.
• "만약 우리가 클릭 한 번으로 몇 초나 몇 분 만에 전체 애플리케이션이 정상 동작하는지 확인할 수 있다면 어떻겠는가? 수정사항이 있을 때마다 몇 분 만에 반영할 수 있고 하루에도 몇 번씩 가능하면 어떻겠는가? 만약 양산 배포된 애플리케이션에서 버그가 발견되더라도 버그를 수정하고 새로 배포하는 일이 얼마나 빨라질까?"
• 먼저 우리가 이루려는 것이 무엇인지 논의해야 한다. 소프트웨어 개발/납품 절차 중에서 어떤 부분을 얼마만큼 개선하길 원하는가? 이러한 것이 정의되고 나면 그것을 달성하기 위해 어떤 실행 관례를 도입할지 말할 수 있다.

항상 왜 해야 하는가, 원하는 것을 이루기 위해 무엇을 해야 하는가를 생각해보자.
언뜻 기술적인 이야기 같지만, 그렇지 않은 부분에서도 통용될 법한 이야기들인 것 같다.

오늘은 많이 읽지 못했지만 내일 이어 읽어야 겠다.