2014년 2월 21일 금요일

코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기


코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기 : 엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라! 제프 앳우드 저/임백준 역 | 위키북스 | 원제 : How to Stop Sucking and Be Awesome Instead (Hyperink)

이전 코딩 호러의 이펙티브 프로그래밍(http://imhallower.blog.me/90178246899)을 읽고
재미있는 충고들이 많아서 다음 책도 보게 되었음.
비록 오래된 블로그글들을 모아서 책으로 정리한 것이겠지만 나같이 귀찮은 사람들에게는 한꺼번에 몰아서 보기에 도움이 된다.

주요 chapter는 다음과 같다. 
1부 쓸데없는 일을 줄이는 법
2부 프로그래밍
3부 웹 디자인의 원칙
4부 테스트
5부 당신의 사용자를 알라

6부 우리가 관심을 둬야 할 것들
7부 게이밍

8불 읽어볼 만한 내용

보시다시피 책의 부제는 "엉터리 개발자에서 벗어나 진정한 개발자로 거듭나라" 이고 관련된 내용을 정리하였지만
전 책에 비해 각 챕터별 주제와 글들이 좀 탄탄하지 못하고 걸러낸 글들을 모아서 주제를 이래저래 맞춘것 같다.
내용면에서는 좀 실망이다. 3,4,5 챕터는 그냥 감흥없이 읽어 버렸다. 다만 마지막 챕터는 흥미를 끌었음.
아래에서 관심 글들을 정리하니 reference하는 책들이나 article이 어마어마하다....

아래는 읽으면서 개인적으로 해당되거나 동감이 가는 충고들을 정리한 내용과 개인 의견이다.

1부 쓸데없는 일을 줄이는 법

당신이 매일 아침 일어날 때, 신이 제작한 완벽하게 독창적인 장치인 유기적인 두뇌를 이용해 그날 해야 할 가장 중요한 일 세 가지를 떠올릴 수 없다면 그 상황을 진지하게 개선할 필요가 있다.
당신에게 중요한 일이 무엇이고, 무엇이 당신에게 동기를 부여하는지 알아내야 한다는 말이다.
=> 회사에서 뭘 할지 몰라 그냥 무의미하게 흘려 버리는 시간이 있다. 나도 회사도 손해이다....

나는 해마다 '버밍험 감옥으로부터의 편지(Letter from a Birmingham Jail)를 다시 읽는다. 그것이 가장 설득력 있는 에세이라고 생각하기 때문이다.... 당장 읽어보라.
(TODO) => 한번 읽어보자.
때로는 프로젝트 자체가 성공을 거두더라도 당신은 실패하게 되는 경우가 있다. ... 여기에 참여했던 엔지니어들이 모두 궁극적으로 실패를 넘어 생존했을뿐더러 이후에 더 엄청난 성공을 향해 나아가기도 했다는 점이다.... 실패는 놀라운 선생님이다.

당신보다 재능이 있는 개발자가 수천 명 있다는 사실에 기죽지 말라. 당신에게 열정이 있는 데 재능이 무슨 필요란 말인가?
=> 감사하게도 희망을 주는 말이다. 하지만 열정이 그냥 열심은 아니겠지..

- 연습하라, 연습하라, 연습하라!
- 경험과 전문성을 혼동하지 말라.
- 민간풍습을 믿지 말라. 하지만 그것을 배우기는 해라.
- 아무것도 절대적으로 믿지 말라. 자신만의 방법론을 세워야 한다.
- 자가 학습을 주도하라. 아무도 대신 해주지 않는다.
- 명성 = 돈. 스스로의 명성을 구축하고 보호하라.
- 자원, 자료, 도구를 끊임없이 확보하라.
- 자신민의 기준과 도덕률을 확립하라.
- 장인적 기술을 사소한 것으로 만드는 자격증을 피하라.
- 항상 노력하는 동료를 곁에 둬라.
- 쓰고, 말하고, 항상 자신이 보기에 진실인 것만을 발언하라.

(TODO) => 꼭 기억하자.
(TODO) => 읽어보자. 자격증 관련

"실천가를 위한 실용주의 프로젝트 관리: 위대한 관리의 비밀(Behind Closed Doors: Secrets of Great Management)"
(TODO) => 읽어보기, 현재 절판임.

이 소프트웨어 개발자는 자기가 해야 하는 일의 전체 목록을 가지고 있지 않다. 즉, 당당하게 99퍼센트의 일이 완성됐다고 주장하고 있기는 하지만 앞으로 남은 일에 얼마나 더 많은 시간을 쏟아 부어야 할지에 대해서는 전혀 모르고 있다!

=> 저자는 할일을 자세히 나열해 보라라고 말하고 있음.. 하긴 나도 개발 결과를 말할때 대충 다 끝나다고 말을 하지만 이것저것 손볼게 남아 있는게 사실이다. 대략적으로 생각해서 결과를 말하곤 하는데 정량적인 방법을 쓰던 다른 방법을 쓰던 자세히 따져 볼 수 있는 방법을 터득하는게 맞겠다.

Roger Session의 "엔터프라이즈 아키텍처를 향한 더 나은 길(A Better Path to Enterprise Architecture)"




2부 프로그래밍
프로그래밍: 사랑하지 않으면 떠나라.
지난 20여 년 동안 나는 돈을 받으면서 프로그래밍할 자격이 없는 것처럼 보이는 사람들과 일한 경험이 아주 많다. 나는 평균적인 수준의 프로그래머를 말하고 있는 것이다. 우리는 모두 인간이고, 그래서 많은 실수를 범한다.
=> 연차가 좀 되니 자존심을 내려 놓고 끊임없이 배우는 자세가 필요하다..... 하지만 자존심을 내려 놓는 것은 어려운 건 사실이다.

많은 사람들이 자기가 쓴 글에 '낙타는 혹이 두개다 The camel has two humps"라는 학술 논문에 대한 링크를 달고 있다.
(TODO) => 읽어 보자.

최근에 스티븐 예그 Steve Yegge의 방대한 글들을 뒤적이다가, 2005년에 작성된 프로그래밍 훈련하기 Practicing programming라는 글을 읽게 됐다.
(TODO) => 읽어 보자.

코드카타(노력이 담긴 학습을 실천하고 프로그래밍 기술을 연마하는 방법에 해당되는)의 예를 보고 싶다면 스티브가 쓴 글은 탁월한 출발점을 제공한다. 스티브는 그것을 실전 훈련 practice drills 이라고 불렀다.
(TODO) => 위 링크에서 항목들을 반복 읽기

칼 위거스 Karl Wiegers가 쓴 탁월한 책인 "소프트웨어에서의 동료 간 검토: 실전가이드 Peer Review in Software: A Practical Guide"는 2002년 이래로 훌륭한 가이드 역할을 수행해 왔다.
(TODO) => 읽고 정리하기


3부 웹 디자인의 원칙
소프트웨어 프로젝트의 사용성과 관련해서 입문자들을 위한 '물을 끓이는 방법' 수준의 쉬운 글을 읽고 싶다면 이 책을 읽는 것을 중단하고 지금 당장 "스티브 크룩의 사용성 평가, 이렇게 하라! Rocket Surgery Made Easy: The Do-It-Yourself Guide to Finding and Fixing Usability Proglems"를 구입해서 읽어보기 바란다.
(TODO) => 빌려서 읽어라.

조엘 스폴스키는 자신의 탁월한 책인 "프로그래머를 위한 사용자 인터페이스 디자인 User Interface Design from Programming"에서 사용성과 학습용이성의 차이를 설명했다.
(TODO) => 읽기

. 그냥 '아니오'라고 말하라.
이런 식의 경험을 하고 나서 많은 소프트웨어 개발자들이 그냥 '아니오'라고 말하라는 원칙을 내면화하게 된다는 생각을 하게 됐다. 양극단의 생각은 모두 위험하다. 하지만 나는 모든 것에 '예'라고 말하라는 원칙이 프로젝트 전체를 실패하게 하는 데 더 큰 위험성을 안고 있다고 생각한다. 둘중에서 어느 한 쪽을 선택해야 한다면 단순함을 추구하는 쪽에 서는 것이 좋다.

5부 사용자를 이해하라

. 개발자에게 UI를 만들게 했을 때 일어나는 일
모든 소프트웨어 개발자의 내면 깊숙한 곳에는 커밍아웃을 기다리는 그래픽 디자이너가 한 명씩 살고 있다. 그 디자이너가 바깥세상으로 나오게 한다면 심각한 문제가 발생한다.
=> 동감이다.. ㅜㅜ , UX, UI, GUI는 디자이너들에게..

게임화 gamification라고도 할 수 있는 이런 방법, 즉 동료를 통한 자극은 정말로 효과가 있다. 하지만 이러한 시스템은 총기류와 같다. 너무나 강력한 힘을 지니고 있어서 그것을 다루는 사람이 방법을 제대로 알고 있지 않으면 위험할 수 있는 것이다.
=> Gamification은 부가적인 기능으로는 매력적이다. 이 책 참고 (http://charlie0301.blogspot.kr/2014/02/gamification.html)

. 반사회적인 사람들을 위한 사회적 소프트웨어 만들기
열 개의 '무시무시한 아이디어', 우리는 이러한 아이디어를 스택 오버플로우를 만들 때 기본요소로 활용했다.
1. 참여를 가로막는 잣대의 수준을 혁신적으로 낮춰라.
2. 사용자들을 (적어도 일부는) 신뢰하라.
3. 우리의 인생 자체가 세계에서 가장 규모가 큰 MMORPG 게임이다.
4. 나쁜 일들은 일어나기 마련이다.
5. 사랑은 금전적 동기보다 우선한다.
6. 규칙은 재미있고 사회적일 수 있다.
7. 현대의 웹사이트 디자인은 모두 게임 디자인이다.
8. 사려 깊은 게임 디자인은 지속 가능한 커뮤니티를 형성한다.
9. 커뮤니티가 항상 옳은 것은 아니다.
10. 약간의 중재는 필요하다.
=> 재미있는 아이디어들 조직에 적용하면 유연하게 만들 수 있지 않을까?


6부 우리가 관심을 둬야 할 것들

.망중립성의 중요성
망중립성은 파일 공유보다 훨씬 더 많은 것을 의미한다. 그런 면에서 팀 우 Tim Wu의 책인 "마스터 스위치: 정보 제국의 흥망과 성쇠 The Master Switch: The Rise and Fall of Information Empires"는 천재적이다.
(TODO) => 읽어 보자.


7부 게이밍

게임 프로그래밍이 이러한 초창기 시절로부터 얼마나 많이 변화했는지에 알고 싶다면 제임스 헤이그의 1997년판 전자책인 "할키온 시절: 고전 컴퓨터와 비디오 게임 프로그래머와의 인터뷰 "Halcyon Days: Interviews with Classic Computer and Video Game Programmers"를 읽어보길 바란다.
(TODO) => 읽어 보자.


8불 읽어볼 만한 내용

. 프로그래머는 책을 읽지 않지만 당신은 읽어야 한다.
=> 몹쓸 기술 서적으로 인해 책을 읽는 것을 피하게 되었지만 좋은 책들을 읽을 때는 경험이 되고 더 깊은 통찰력을 준다고 말함.. 나도 동의하는 바이다. 다만 최신 기술을 습득하기에는 부적합 하지만 단시간에 자신의 경험으로 만들고 다른 방법을 배우는 것에는 효과적이라고 생각한다. 오픈 소스 공부가 최고지만..
(TODO) => 아래 책 읽기
. 코드 컴플리트 2 
. 상식이 통하는 웹 사이트가 성공한다. Don't Make Me Think
. 피플웨어 Peopleware http://charlie0301.blogspot.kr/2014/02/blog-post.html
. 실용주의 프로그래머 Pragmatic Programmer
. 소프트웨어 공학의 사실과 오해 Facts and Fallacies of Software Engineering

앞에서 인용했던 그 사람도 자기계발서 가운데 놀랍게도 5퍼센트에 해당하는 책은 쓰레기가 아니라는 결론을 내릴 수 있었다.
권장하는 책은 "59초: 순식간에 원하는 결과를 끌어 내는 결정적 행동의 비밀"59 Seconds: Think a Little, Change a Lot"
(TODO) => 읽자.

.컴퓨터 범죄, 그 과거와 현재
개과천선한 해커 중 한 명인 케빈 폴슨 Kevin Poulson이 쓴 '킹핀'은 대단히 흥미진진한 독서 경험을 제공한다.
(TODO) => 읽자.

. 사람에게 말을 하는 방법
내가 단지 10페이지 정도만 읽고도 충격을 받을 정도로 도움되는 책이 있음을 깨닫게 된 책이 있다. 당신이 나이가 2세에서 99세 사이에 있는 아이를 다뤄야 하는 입장이라면 지금 당장 가서 "어떤 아이라도 부모의 말 한마디로 훌륭하게 키울 수 있다. How to Talk So kids Will Listen So Kids Will Talk"를 구입하기 바란다. 우리는 이미 이 책을 세 권 가지고 있다. 당신도 읽어야 한다.
(TODO) => 읽자.


. 기본기 다지기: 새루운 튜링 승합차
우리의 CEO인 스콧 스탠필드 Scott Standfield는 고전적인 컴퓨터 공학 퍼즐을 연구하다가 나를 "새로운 튜링 승합차: 66일간의 컴퓨터 공학 여행 The New Turing Omnibus: 66 Excursions in Computer Science"으로 인도 했다. 정말로 믿을 수 없을 정도로 흥미로운 책이다.
(TODO) => 재미 있겠지, 읽자.

댓글 없음:

댓글 쓰기