<div id="readability-page-1" class="page"><div><p><code>소프트웨어 장인</code>이라는 책을 읽어보았다.</p>
<p><img src="http://sgc109.github.io/images/software-craftmanship/software-craftman.jpg" alt=""></p>
<p>저자가 경험한 일화를 소개하며 '소프트웨어 장인'은 평소에 어떤 태도를 가지며, 특정 상황에서 어떻게 행동하는 사람인지 정의한다.</p>
<p>우선 책 표지를 보면, 제목 오른쪽에 '프로페셔널리즘', '실용주의', '자부심' 이 세 단어가 적혀있다.<br>
이 세 단어가 책의 내용을 가장 잘 함축할 수 있기 때문이라 짐작한다.</p>
<ul>
<li>프로페셔널리즘
<ul>
<li>소프트웨어 장인은 성실하며 정직하다. 고객, 혹은 매니저 등이 불가능해 보이는 일을 부탁하는 경우에는 솔직하게 '아니오'라고 말 할 수 있다.</li>
<li>소프트웨어 장인은 고객을 만족시킬 수 있는 사람이다.</li>
</ul>
</li>
<li>실용주의
<ul>
<li>실행 관례, 디자인 패턴 등 그 무엇이 되었건, 버그 없는 소프트웨어를 일정 안에 개발하여 고객을 만족시키는 것보다 중요한 것은 없다</li>
</ul>
</li>
<li>자부심
<ul>
<li>소프트웨어 장인은 자신의 일에 자부심을 가지고 있다. 소프트웨어 분야와 커뮤니티가 성장하는 것에 기여한다.</li>
<li>자신의 지식을 나누고, 배우는 것에 거리낌이 없다.</li>
</ul>
</li>
</ul>
<p>그 외에도 소프트웨어 개발자로서 도움이 될 만한 소프트 스킬들에 대한 조언을 준다.</p>
<h2 id="저자가-주는-팁들">저자가 주는 팁들</h2>
<h3 id="좋은-팀원을-채용하기-위한-방법">좋은 팀원을 채용하기 위한 방법</h3>
<ul>
<li>채용 공고 작성법, 면접 방법</li>
</ul>
<h3 id="커리어를-만들기-위한-활동">커리어를 만들기 위한 활동</h3>
<ul>
<li>블로그, 오픈 소스 활동, 커뮤니티 참여 등</li>
</ul>
<h3 id="팀원-매니저를-설득하는-방법">팀원/매니저를 설득하는 방법</h3>
<ul>
<li>애자일, XP, TDD, 페어 프로그래밍 등의 실행 관례 적용을 위한 설득</li>
<li>고객이나 매니저의 요청에 '아니오'라고 말할 땐 항상 대안을 제시해야한다</li>
</ul>
<h2 id="저자가-강조하는-점들">저자가 강조하는 점들</h2>
<p>저자는 책 전반에 걸쳐 XP, TDD, 페어 프로그래밍, 지속적인 통합 등을 계속 강조한다.</p>
<h3 id="페어-프로그래밍">페어 프로그래밍</h3>
<ul>
<li>서로를 통해 새로운 지식을 얻을 수 있으며, 실시간으로 피드백을 받기 때문에 좋은 네이밍이 가능하고, 더 좋은 코드를 작성할 수 있게 된다.</li>
<li>주기적으로 짝을 바꾸어 실시하여 효율성을 극대화한다.</li>
</ul>
<h3 id="TDD">TDD</h3>
<ul>
<li>테스트를 통과할 만큼의 코드를 작성하게 되어 오버 엔지니어링을 막아준다.</li>
<li>확장성을 고려한답시고 미래를 과도하게 예측하면 코드의 복잡도가 올라간다. 필요할 때 수정하자. 디자인 패턴을 과도하게 적용하면 안된다.</li>
<li>레드-그린-리팩터 사이클을 통해 작은 리팩토링을 자주 적용할 수 있다.</li>
</ul>
<h3 id="지속적인-통합">지속적인 통합</h3>
<ul>
<li>항상 동작하는 소프트웨어를 자주 릴리즈하면 빠르게 시장이나 고객의 피드백을 받을 수 있다.</li>
<li>TDD 를 한다면 현재의 소프트웨어가 잘 동작하는 소프트웨어라는 것이 검증된다.</li>
<li>기획팀에서도 정확한 요구사항을 모를 때 빠른 배포 주기를 통해 오히려 개발팀이 가이드를 제시할 수도 있다.</li>
<li>기획자의 머리에서 기획이 수정되는 속도와 소스 코드가 수정되는 속도가 같아야한다.</li>
</ul>
<h3 id="유닛테스트">유닛테스트</h3>
<ul>
<li>개발과 테스트는 별개의 업무가 아니다. 테스트까지 끝내야 해당 개발이 완료되는 것이다.</li>
<li>과거에는 디버깅을 잘하면 실력있는 개발자로 보았지만, 시대가 변했다. 테스트 코드를 잘 작성하면 디버깅이 필요없다.</li>
</ul>
<h3 id="열정과-훈련">열정과 훈련</h3>
<ul>
<li>소프트웨어 장인은 소프트웨어 개발에 열정을 가지고 있으며, 끊임없는 훈련을 통해 계속 성장한다.</li>
</ul>
<h3 id="그-외">그 외</h3>
<ul>
<li>소프트웨어 개발에서 가장 중요한 것은 결국 고객을 만족시키는 것이다.</li>
<li>TDD와 같은 방식을 사용했을 때 시간이 더 오래걸리는 이유는, 이런 방식 자체의 문제가 아니라 새로운 방식에 익숙해지는데 걸리는 시간 때문이다.</li>
</ul>
<p>이 외에도 많은 조언과 경험담이 있다. 이 책은 소프트웨어 개발자로 살아가면서 피와 살이되는 이야기들이 많은것같다.</p>
<p>그러므로 언젠가는 다시 펼쳐볼 날이 있을것이라 생각한다.</p>
</div></div>

Sungho's Blog

Sungho Hwang

소프트웨어 장인이라는 책을 읽어보았다.
저자가 경험한 일화를 소개하며 '소프트웨어 장인'은 평소에 어떤 태도를 가지며, 특정 상황에서 어떻게 행동하는 사람인지 정의한다.
우선 책 표지를 보면, 제목 오른쪽에 '프로페셔널리즘', '실용주의', '자부심' 이 세 단어가 적혀있다.
이 세 단어가 책의 내용을 가장 잘 함축할 수 있기 때문이라 짐작한다.
프로페셔널리즘
소프트웨어 장인은 성실하며 정직하다. 고객, 혹은 매니저 등이 불가능해 보이는 일을 부탁하는 경우에는 솔직하게 '아니오'라고 말 할 수 있다.
소프트웨어 장인은 고객을 만족시킬 수 있는 사람이다.
실용주의
실행 관례, 디자인 패턴 등 그 무엇이 되었건, 버그 없는 소프트웨어를 일정 안에 개발하여 고객을 만족시키는 것보다 중요한 것은 없다
자부심
소프트웨어 장인은 자신의 일에 자부심을 가지고 있다. 소프트웨어 분야와 커뮤니티가 성장하는 것에 기여한다.
자신의 지식을 나누고, 배우는 것에 거리낌이 없다.
그 외에도 소프트웨어 개발자로서 도움이 될 만한 소프트 스킬들에 대한 조언을 준다.
저자가 주는 팁들
좋은 팀원을 채용하기 위한 방법
채용 공고 작성법, 면접 방법
커리어를 만들기 위한 활동
블로그, 오픈 소스 활동, 커뮤니티 참여 등
팀원/매니저를 설득하는 방법
애자일, XP, TDD, 페어 프로그래밍 등의 실행 관례 적용을 위한 설득
고객이나 매니저의 요청에 '아니오'라고 말할 땐 항상 대안을 제시해야한다
저자가 강조하는 점들
저자는 책 전반에 걸쳐 XP, TDD, 페어 프로그래밍, 지속적인 통합 등을 계속 강조한다.
페어 프로그래밍
서로를 통해 새로운 지식을 얻을 수 있으며, 실시간으로 피드백을 받기 때문에 좋은 네이밍이 가능하고, 더 좋은 코드를 작성할 수 있게 된다.
주기적으로 짝을 바꾸어 실시하여 효율성을 극대화한다.
TDD
테스트를 통과할 만큼의 코드를 작성하게 되어 오버 엔지니어링을 막아준다.
확장성을 고려한답시고 미래를 과도하게 예측하면 코드의 복잡도가 올라간다. 필요할 때 수정하자. 디자인 패턴을 과도하게 적용하면 안된다.
레드-그린-리팩터 사이클을 통해 작은 리팩토링을 자주 적용할 수 있다.
지속적인 통합
항상 동작하는 소프트웨어를 자주 릴리즈하면 빠르게 시장이나 고객의 피드백을 받을 수 있다.
TDD 를 한다면 현재의 소프트웨어가 잘 동작하는 소프트웨어라는 것이 검증된다.
기획팀에서도 정확한 요구사항을 모를 때 빠른 배포 주기를 통해 오히려 개발팀이 가이드를 제시할 수도 있다.
기획자의 머리에서 기획이 수정되는 속도와 소스 코드가 수정되는 속도가 같아야한다.
유닛테스트
개발과 테스트는 별개의 업무가 아니다. 테스트까지 끝내야 해당 개발이 완료되는 것이다.
과거에는 디버깅을 잘하면 실력있는 개발자로 보았지만, 시대가 변했다. 테스트 코드를 잘 작성하면 디버깅이 필요없다.
열정과 훈련
소프트웨어 장인은 소프트웨어 개발에 열정을 가지고 있으며, 끊임없는 훈련을 통해 계속 성장한다.
그 외
소프트웨어 개발에서 가장 중요한 것은 결국 고객을 만족시키는 것이다.
TDD와 같은 방식을 사용했을 때 시간이 더 오래걸리는 이유는, 이런 방식 자체의 문제가 아니라 새로운 방식에 익숙해지는데 걸리는 시간 때문이다.
이 외에도 많은 조언과 경험담이 있다. 이 책은 소프트웨어 개발자로 살아가면서 피와 살이되는 이야기들이 많은것같다.
그러므로 언젠가는 다시 펼쳐볼 날이 있을것이라 생각한다.

[책 리뷰] 소프트웨어 장인

댓글