이번 명절에 스택 오버플로우 공동 창립자(제프 엣우드)가 2012년도에 지은 코딩 호러의 이펙티브 프로그래밍이라는 책을 보았다. 웹 개발에 특화된 내용이 있지만 전반적으로 소프트웨어 개발자들이 한번쯤은 봤으면 좋을 법한 책이다. 특히 개인적으로 소프트웨어 경험이 없는 관리자들에게는 더욱 추천한다.
이 책에서는 이 두 사이트를 탄생시킨 저자의 소프트웨어 개발과 관련된 지혜와 조언이 가감 없이 담겨 있다. 저자가 전해주는 소프트웨어 개발에 관한 깊이 있는 연구 내용과 조언들은 비단 프로그래머뿐 아니라 소프트웨어 개발을 둘러싼 이해관계자에게 모두 도움될 것이다. 그동안 코딩 호러에 실린 글 중에서 엄선한 글만 실린 이 책은 소프트웨어 개발에 관한 저자의 통찰력과 실질적인 조언을 통해 여러분의 소프트웨어 개발 프로젝트가 성공하기 위한 밑거름이 되어 줄 것이다. (출판사 책 소개에 담긴 글)
이제 필자가 책을 읽으면서 공유하고 싶은 내용에 대해 적어보고자 한다.
1부. 들어가며
쓰지 않으면서 쓰기 모두가 아주 많이 글을 써야 한다. 블로그든, 책이든, 스택 오버 플로우의 답글이든, 이메일이든 상관 없다. 글을 쓰고, 그 글에 대해 잠시 생각을 하는 것이다. (필자도 블로그에 글을 좀 더 자주 생각하면서 써야겠다는 생각이 들었다.)
2부. 엉터리 같은 일을 마무리하는 기술
거대하고 끝없는 바다, 동기 부여 관련된 동영상: http://bit.ly/MVUDI5
톱날 갈기, 코딩을 하는 데 너무 바빠서 토론,복습,학습 등을 할 시간이 없다면 당신은 앞으로 나아가고 있지 않은 것이다. 프로그래밍 관련된 좋은 링크 모아놓은 웹사이트 (해커 뉴스, 프로그래밍 레딧)
저 길로 가라. 총알처럼, 어지러운 전투에서 승리를 거두는 것이 관찰하고, 방향을 잡고, 계획을 세우고, 더 낫게 행동하는 것에 달린 것이 아니라, 더 빠르게 움직이는 것이다. 결국 더 빨리 반복하는 것이 반복의 집을 압도한다. (빠르고 좋은 결정은 있지만, 느리고 좋은 결정은 없다.)
멀티태스킹이라는 미신, 특히 프로그래머를 관리할 때는 업무 전환하는 데 따르는 비용이 정말로, 대단히, 아주 긴 시간을 요구한다는 사실을 깨달을 필요가 있다. (필자도 여러 업무를 동시에 처리하지만, 상당히 비효율적인 것 같다. 하지만 현실은 이상과 다르다)
3부. 좋은 프로그래밍의 원리
그것은 언제나 당신의 잘못이다., 심지어 자기가 작성한 코드 때문에 야기되는 문제가 아닌 경우에도 일단 문제가 자기 코드에 있다고 간주하고 그에 합당한 조치를 취하는 태도를 의미한다.
주석 없이 코딩하기, 주석을 다는 것은 코드가 동작하는 방식을 설명하기 위함이 아니라, 그것이 왜 그렇게 동작하는지를 설명하기 위해서이다.
루크, 소스를 읽는 법을 배우게, 필자도 개발하고 있는 소스 코드의 전부를 알지 못하지만, 상당히 이해하려고 노력한다. 심지어 그 오픈 소스 코드에 기여를 하기 위해 노력하고 있다.
아이디어가 아니라 팀을 가꿔라, 성공이 아이디어의 질에 의해 결정되는 경우는 거의 없다. 그것은 대부분 실행의 질에 의해 결정된다.
당신의 팀은 엘리베이터 테스트를 통과할 수 있는가?, 우연히 마주친 사람에게 자신의 일을 의미 있는 방식으로 전달하지 못한다면 스스로 어떻게 생각하고 있는지 여부와 상관없이 뭔가 문제가 있는 것이다.
5부. 팀이 함께 일하도록 만들기
예를 통해 리드하기, 기술적인 리더십의 가장 효과적인 모습은 예를 통해 리드하는 것이다.
회의: 일이 죽으러 가는 장소, 가능한 회의는 안하고, 할 때는 정말 정말 필요할 때만 해야하는 것이다.
썩은 사과: 그룹 전체의 독, 썩은 사과를 포함하고 있음에도 매우 좋은 성과를 거둔 그룹이 있었다. 그 그룹에는 특별히 훌륭한 리더가 존재 했다.
7부. 사용자를 염두에 두고 설계하기
애플리케이션은 결국, 작은 디테일의 모음이다., 어렵지만, 작은 디테일은 정말 중요하다. 필자는 애플이 이 말을 가장 잘 적용한 제품을 내고 있다고 생각한다. 하지만 iOS도 버전이 올라가면서 버그들이 많아졌다.
사용자 인터페이스가 애플리케이션이다, 사용자의 진지한 관심을 유도하고 싶으면 인상적인 UI를 구축해야 한다.
테스트 관련한 부분은 필자가 제외했다. 하지만 테스트 역시 중요하다. 코드 리뷰, 단위 테스트, 값싼 사용성등의 테스트는 해야 한다. 커뮤니티 관련 부분도 마지막 부분에 있다. 요약하자면
1. 커뮤니티에서 나오는 10%의 가치있는 내용을 파악하기 위해 관심을 가지고 유지한다.
2. 사용자의 피드백만 듣고 행동을 결정하지 말고 실제 행동할 수 있는 데이터를 가지고 결정해야 한다.
필자의 의견
의견 필자가 중요하다고 생각되는 부분 외에도 중요한 많은 내용이 기술되어 있다. 한번쯤 가볍게 읽어 볼만한 책인 것 같다. 이 책을 읽고 개발적인 부분, 관리적인 부분에서 어떻게 하면 좋을지에 대한 생각을 다시하게 되었다. 이책의 내용이 꼭 정석은 아니다. 독자가 자기의 상황에 맞게 잘 적용하면 많은 도움이 될 것 같다.
'Book' 카테고리의 다른 글
[도서] 신규 Yocto 책 2권 리뷰 (읽기 전) (0) | 2023.04.20 |
---|---|
[도서] 성공으로 이끄는 팀 개발 실천 기술 (0) | 2023.04.20 |
책 집필(번역) 시 올바른 표현들 (0) | 2023.04.20 |
[번역서 출간] BeagleBone Black을 사용한 Yocto 프로젝트 (0) | 2023.04.20 |
(도서) 소셜 코딩으로 이끄는 GitHub 실천 기술 (0) | 2023.04.19 |