호기심 많은 제프 앳우드의 <코딩 호러의 이펙티브 프로그래밍>

코딩 호러의 이펙티브 프로그래밍 제프 앳우드 저/임백준 역

스택 오버플로우의 공동 창업자인 제프 앳우드는 코딩 호러라는 자신의 블로그를 운영하고 있다. 블로그에 가면 프로그래밍과 그와 관련된 다양한 주제의 흥미로운 글들을 만나볼 수 있다. 이 책은 그중에서 사람들의 관심을 끌었던 글들을 담고 있다. 서문에서 밝힌 대로 그는 소프트웨어 개발의 기술적인 측면뿐만 아니라 그 배후에 존재하는 사람에 대해 호기심이 많다. 프로그래머에게 '어떻게'를 설명하는 기술 서적도 중요하지만 그보다 더 중요한 건 제프 앳우드의 책과 같이 '왜'에 대해 고민하게 만드는 책이 아닐까 생각해 본다. 이 책을 읽지 않은 분 중에 코딩 호러 블로그의 호기심 가득한 글이 마음에 든다면 이 책을 읽고 새로운 발상을 할 수 있는 여유를 가져봐도 좋을 것 같다.

 

본문 중에서

컴퓨터는 놀라운 기계이지만 사실상 그것을 사용하는 사람을 단순히 반영하는 기계에 불과하다. 소프트웨어 개발의 기술적인 측면은 코드를 학습하는 것만으로는 충족되지 않는다. 소프트웨어의 배후에 존재하는 사람을 함께 연구해야 한다.

최선의 코드는 아무 코드도 없는 것이다

코드를 작성하는 것을 사랑한다면, 그러니까 진짜로 코딩을 사랑하다면 가급적 적은 분량의 코드를 작성하는 것조차 충분히 사랑할 수 있을 것이다.

아이디어가 아니라 팀을 가꿔라

 

몇 년이나 경험했는가, 라는 질문에 담긴 미신

어찌된 일인지 사람들은 소프트웨어 개발자가 가장 잘하는 일이 뭔가 새로운 것을 배우는 일이라는 사실을 종종 잊는다. 회사는 특정 언어에 상관없이 제대로 된 코드를 작성할 수 있는 사람을 채용하려고 노력해야 한다. 그런 사람을 채용해서 그들이 흥미를 가지고 일할 수 있는 프로젝트를 제공해주면 충분하기 때문이다.

뱀파이어 프로그래머 대 베어울프 시스템 관리자

내 경험에 의하면 프로그래머와 시스템 관리자가 싸우는 것은 그들이 심심하기 때문이다. 그들이 서로의 고유한 기술을 발휘하면서 힘을 합쳐야 할 만큼 어려운 일을 맡기지 않은 것이다.

회의: 일이 죽어러 가는 장소

1. 어떤 회의라도 한 시간을 넘기면 안 된다. 넘기면 사형이다.
2. 모든 회의에는 명확하게 정의된 목표가 있어야 한다.
3. 회의에 참석하기 전에 회의에서 필요한 일을 하라.
4. 회의에 참석하는 것을 선택사항으로 만들어라.
5. 회의를 마무리할 때 해야 할 일을 정리하라.

사용자를 염두에 두고 설계하기

당신의 애플리케이션은 결국, 작은 디테일의 모음이다.
사용자가 기쁘게 사용하는 것과 사용자가 그저 참을만하다고 느끼면서 사용하는 것의 차이는 바로 디테일을 얼마나 제대로 구현하는가에 달려있는 것이다.

코드를 테스트해서 그것이 필요 이상으로 엉망이 되지 않게 만들기

코드 리뷰에서 유일한 장애물은 당신이 존중할 만한 동료 개발자를 찾고, 함께 코드 리뷰를 수행할 만한 시간을 할애하는 것이다. 일단 코드 리뷰를 시작한다면 거기에 들어가는 시간이 열 배로 보상을 가져다준다는 사실을 금방 알게 될 것이다.

나는 단위 테스트를 작성하지 않는 바보들에게 동정을 보낸다

<단위 테스트를 먼저 작성하는 데 따르는 12가지 이익>

1. 단위 테스트는 당신의 코드가 실제로 동작한다는 것을 증명한다.
2. 낮은 수준에서 동작하는 회귀 테스트 한 벌을 가질 수 있다.
3. 설계를 망가뜨리지 않으면서 개선할 수 있다.
4. 단위 테스트와 함께 코드를 작성하는 것은 그렇지 않은 것보다 더 재미있다.
5. 구체적인 전진 과정을 보여준다.
6. 단위 테스트는 샘플 코드의 형태를 취한다.
7. 코딩을 사작하기 전에 일정한 계획을 세우게 해준다.
8. 버그에 따르는 비용을 줄여준다.
9. 코드 조사(code inspection)에 비해 훨씬 더 효과적이다.
10. 실질적으로 코더의 블록(프로그래머가 심리적으로 갑자기 아무 생각도 떠올릴 수 없는 상태)을 제거해준다.
11. 단위 테스트는 더 나은 설계를 가능하게 해준다.
12. 테스트 없는 코드를 작성하는 것보다 빠르다.

게임화

나는 스택 익스체인지라는 게임을 평판, 뱃지, 랭킹, 그리고 찬성표를 긁어모으면서 다른 사람들과 더불어 즐겁게 하고 있다. 이렇게 하는 과정에서 내가 지식을 쌓을 수 있고, 더 나은 의사소통 기술을 계발할 수 있고, 그와 동시에 다른 모든 사람들을 위한 웹의 질감을 향상시킬 수 있기 때문에 이러한 게임을 하는 것이 자랑스럽다. 당신도 나와 생각이 같기를 희망한다.

빠르게 살고, 일찍 죽고, 지친 육신을 남기고

스타트업닷컴과 코드 러쉬가 묘사하고 있는 있는 바와 같이, 이해하기 힘든 부분은 바로 우리가 왜 그토록 오랜 시간 동안 열심히 일을 하는가다. 당신의 경력이 그토록 많은, 실패한 닷컴 시대의 회사들의 운명을 닮지 않게 하고 싶다면 신중하게 생각하기 바란다. 그런 회사들의 삶은 빠르게 살고, 일찍 죽고, 그리하여 지친 육신을 남기는 것이었다.

 

참고

코딩 호러 블로그
https://blog.codinghorror.com/

해커 뉴스
https://news.ycombinator.com/news

제럴드 와인버그 <좋은 소프트웨어: 시스템 사고>
제럴드 와인버그 <테크니컬 리더: 혁신, 동기부여, 조직화를 통한 문제 해결 리더십>

Best Practices for Speeding Up Your Web Site
https://developer.yahoo.com/performance/rules.html

YSlow: Yahoo's Problems Are Not Your Problems
https://blog.codinghorror.com/yslow-yahoos-problems-are-not-your-problems/

Advice on Attracting Good Developers
http://samuelmullen.com/2012/02/advice-on-attracting-good-developers/

The Five Essential Phone-Screen Questions
https://sites.google.com/site/steveyegge2/five-essential-phone-screen-questions

Wiegers, Karl E. <Peer Reviews in Software: A Practical Guide: A Practical Guide>

단위 테스트를 먼저 작성하는 데 따르는 12가지 이익
http://sd.jtimothyking.com/2006/07/11/twelve-benefits-of-writing-unit-tests-first/

스티브 크룩 <상식이 통하는 웹사이트가 성공한다>

댄 길버트 <행복에 걸려 비틀거리다>

 

- James Song