책 ‘소프트웨어 장인' 리뷰
by 공잠
출근 시간을 이용해서 읽었고 2주 정도 걸렸습니다. 자리잡고 느긋하게 봤다면 하루안에 볼 수 있을 정도로 술술 잘 읽히는 책입니다.
<소프트웨어 장인> (산드로 마쿠소 지음, 길벗)
‘장인'이라는 단어가 조금 거슬립니다. 책에서 말하는 요지는 ’장인'이라는 단어보다는 오히려 ‘프로페셔널 정신’에 가깝다고 느껴집니다. 장인은 왠지 ‘방망이 깍던 노인'이라는 수필이 생각나게 하거든요. 적당히 괜찮은 방망이 하나를 의뢰하고 언능 받아서 부인에게 가져다주고 싶은 퇴근길의 남자의 입장에서는 이 노인은 참 곤란합니다. 저렴하지도 않을 뿐더러 차시간 때문에 빨리 받아가려고 노인을 계속 재촉해도 노인의 고집을 꺽지 못합니다. 자신의 방식대로 만들어야 제대로 만드는 것인데 노인에게는 대충이란것이 허용되지 않거든요. 이 노인이 보여주는 것이 장인정신이 아닌가 싶어요.
산드로 마쿠소가 말하는 오버엔지니어링이 바로 이 노인의 ‘고집’ 즉 장인정신이 아닌가 싶어요. 장인의 정신은 예술가의 정신과 맞닿아 있습니다. 경지에 이르는 것이지요. 저자는 ‘프로그래밍은 예술이 아니’라고 강조하며 오버엔지니어링을 경계합니다. 게다가 재촉하기도 힘들고 가격도 비싼 장인의 작품은 소프트웨어의 세계에서는 어울리지 않지요. 아마도 이 책에서 말하는 ‘소프트웨어 장인'은 장인의 실력을 지향하면서도 실용주의적인 개발자를 말하는게 아닌가 싶습니다.
아무튼 ‘장인'이라는 단어가 거슬림에도 불구하고 숙련된, 시니어 개발자가 되고자하는 (시니어도 아니고 주니어도 아닌) 개발자들에게 많은 영감을 줍니다.
그리고 <실용주의 프로그래머>를 읽어야겠다고 생각했습니다.
후기는 여기까지, 아래 밑줄 친 문장들이 이 책에 대해 더 잘 말해줄 것 같네요.
47page
내가 지켜보았던 거의 대부분의 애자일 전환 프로젝트들은 부분적으로만 전환하는 문제를 안고 있었다. 기업들은 컨설턴트나 애자일 코치를 고용하여 개발 절차를 바꾸는 데는 도움을 받지만, 더 높은 품질의 소프트웨어를 작성하는데는 거의 도움이 안 되고 있다. 보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다.
49page
애자일 선언의 진정한 의미를 이해한 애자일 코치는 절차뿐만 아니라 기술적 탁월함도 강조한다. 대부분의 가이드가 절차에 집중되어 있을지라도 다른 영역의 프로페셔널과 함께 고객의 기술 훈련에도 주의를 기울인다.
159page
페어 프로그래밍 페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다(보통 \'4개의 눈\'으로 검증한다고 말한다). 개발자가 테스트를 작성하거나 변수 이름을 짓는 순간 다른 개발자가 즉시 "이 부분은 이해가 안 됩니다. 어떤 의미죠?...."라고 말하며 ...피드백을 한다. 같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다. 더불어 코딩 표준을 정의하고 유지하는 데도 도움이 된다.
162page
리펙토링 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. 이것은 '깨진 유리창 법칙'으로도 알려져 있다. 지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다. 지속적으로 코드를 리펙토링하면 이러한 위험이 줄어든다. 코드에 손을 댈 때마다 지속적으로 코드를 가다듬는다. ... 레거시 애플리케이션을 대상으로 일을 할 때, 전체 시스템을 한꺼번에 새로 작성하고 싶은 욕구를 조심해야 한다. 이럴 때는 수정되는 부분에 한정해서 리펙토링을 집중하는 것이 더 나은 접근 방법이다. ... 몇 년 동안 바뀐적이 없는 부분을 리펙토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리펙토링해야 할 이유도 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야한다. ... 유지보수가 쉬운 깨끗한 코드는 개발 속도를 높이고 버그가 만들어질 가능성을 낮춘다. 이것이 리펙토링의 비즈니스적인 가치다.
162page
실용주의 실용주의는 소프트웨어 장인이 가져야 하는 최선의 역량 중 하나다. 누군가가 이야기했기 때문에, 또는 그 실행 관례 도입을 위한 도입을 해서는 안된다. 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다. 그 결론이 TDD를 도입하는 것이라면 그렇게 해야 한다. 언제든지 TDD보다 더 나은 가치와 더 빠른 피드백 루프를 줄 수 있는 다른 것이 있다면 그것을 TDD대신 도입해야 한다. ... 특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다. 소프트웨어 장인으로서, 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.