코딩 호러의 진짜 소프트웨어 개발 이야기
제프 앳우드 지음, 임백준 옮김/위키북스
추천 대상 : 웬만한 모든 사람들은 다 읽으면 좋겠다고 생각한다. 내가 선정한 나의 올해의 책!
추천 정도 : ★ ★ ★ ★ ★
메모 : 남자친구의 책 중 표지 그림이 모로호시 다이지로 같은 책이 있어 읽은 것이 이 책이었다. 결과적으로는 매우 만족! 내가 선정한 나의 올해의 책이 되었다. stackoverflow 창업가인 제프 앳우드가 쓴 이 책은 솔직히 프로그래머가 아니라 제품 개발에 조금이라도 참여하는 사람이라면 무조건 얻을 것이 있을 것이다. 그리고 나는 제프 앳우드 식의 시선을 좋아하기 때문에 매우매우 재밌고 유익하게 읽었다. 읽으면서 거의 5분에 한 번 꼴로 와, 맞아 이건 맞는 말이야, 이렇게 해야 하지라고 생각했다.
디자인에 대한 그의 의견도 맘에 든다. 제품 디자인을 위해 리서치 하고 사용자를 만나야 하는 것은 디자이너 뿐만이 아니다 모든 사람, 특히 제품을 직접 만드는 사람에게 굉장히 중요한 일이라고 생각한다.
예전에 폴 그레이엄의 책인 <해커와 화가>도 재밌게 읽었는데 프로그래머 중에서도 글을 잘 쓰는 분들이 좀 있구나, 더 있으면 더 찾아서 보고 싶다라고 생각했다.
발췌
1부 쓸데 없는 일을 줄이는 법
내 삶에 큰 의미가 없는 사소한 일들은 내가 사용하던 할일목록 안에 끝없이 쌓여만 갔다. 그리고 이렇게 잔뜩 밀려있는 일들이 모여서 형성하는 총체적인 정신적 무게가 눈덩이처럼 크게 불어나서 매일 내 어깨를 짓눌렀다.
당신에게 중요한 일이 무엇이고, 무엇이 당신에게 동기를 부여하는지 알아내야 한다는 말이다. 지체되는 일이 있다면 그 일이 왜 당신의 관심을 끌지 못해서 당장 완료되지 못하는지 자문해보라. 그리고 일이 완료되지 못하게 가로 막고 있는 문제를 해결하라.
백일몽은 업무의 반대가 아니다. 역으로 뭔가 창의적인 해법에는 반드시 백일몽이 필요하다.
자유로운 시간을 사용해 수행한 퀴퀴한 냄새가 풍기는 시도들이 비참한 실패를 거두더라도 그것으로 인해 어떤 반대급부를 받거나 평가를 당하는 일이 없어야 한다
자기가 보기에 뭔가를 개선할 것처럼 보이는 그럴듯한 아이디어가 있으면 그것이 어떤 것이든 실제로 시도해보는 것이 단순히 묵과되는 것이 아니라 오히려 장려되기 시작한다면 그것은 일을 일처럼 느끼지 않게 만드는 데 큰도움이 된다
다른 사람에게 영향을 미치기를 조금이라도 희망한다면 그들을 설득할 수 있어야 한다
그의 아이디어는 전체적으로 봤을 때 상당히 괜찮다
그는 위에서 아래로가 아니라 아래에서 위로 올라가는 방식으로 일했다
그는 다른 사람들에게 권고를 하기 전에 자기 자신에 생각에 본을 보이는 방식으로 주변 사람들의 신뢰를 얻었다
그는 바퀴가 굴러가기 시작할 때까지 참을성 있게 기다렸다
과학과 데이터는 객관적인 설득력을 갖추기 위한 최선의 방법이다. 하지만 모든 것이 데이터 자체로 환원될 수 있는 것이 아니다.
2부 프로그래밍
당신이 매우 운이 좋은 개발자가 아니라면 아마도 지금까지 성공을 거둔 프로젝트보다는 실패한 프로젝트에 더 많이 참여했을 것이다. 우리 업계에서 실패는 지극히 정상적인 것이다. 어쩌면 당신은 지금도 실패를거둘 확률이 더 높은 프로젝트에 참여하고 있다고 봐도 무방하다
그는 성공을 거두기 위해 필요한 것은 기술이나 지능이라기보다 탐구하는 마음, 실패의 가능성과 결과에 대해 건전한 방식으로 집착하는 태도라고 결론내렸다.
진정으로 실패한 프로젝트란 그 안에서 아무것도 배우지 못한 프로젝트다.
강의에서 요구하는 최소한의 기준을 충족시킨다고 했을 때 정말 중요한 것은 수강생들이 전보다 더 많이 알도록 돕는 데 있다. 그들이 스스로 배워나가도록 도움을 주는 것이다. 어떤 방법을 동원해서라도 말이다.
전문가가 된다는 것은 다른 사람에게 자기가 아는 것을 말하는 것이 아니다. 그것은 바로 어떤 질문을 할지 아는 것, 자신의 지식을 주어진 특정한 상황에서 어떻게 적용할지 아는 것을 의미한다. 전문가가 된다는 것은 합리적이고 상황에 매우 적절한 방향을 제시할 수 있음을 의미한다.
전문가에 대한 발언
연습하라, 연습하라, 연습하라!
경험과 전문성을 혼동하지 말라.
민간풍습을 믿지 말라. 하지만 그것을 배우기는 해라.
아무것도 절대적으로 믿지 말라. 자신만의 방법론을 세워야 한다.
자가 학습을 주도하라. 아무도 대신 해주지 않는다
명성 = 돈. 스스로의 명성을 구축하고 보호하라
자신만의 기준과 도덕률을 확립하라
장인적 기술을 사소한 것으로 만드는 자격증을 피하라
항상 노력하는 동료를 곁에 둬라
쓰고, 말하고, 항상 자신이 보기에 진실인 것만을 발언하라
개발자들에게 자기가 해야 할 일을 모두 자세하게 나열해보도록 권장함으로써 그렇게 할 수 있다
반복의 속도가 반복의 질보다 우선한다
소프트웨어 공학의 원리
단위 테스트는 작고 빨라서 모든 빌드 과정에서 실행될 수 있어야 한다
사용성 테스트는 2주마다 자은 변화를 줘서 제대로 작동하지 않는 것을 바로바로 없앨 수 있을 때 가장 효과적이다
대부분의 애자일 방법론에서는 4주보다 길지 않은 반복주기를 권장한다
소프트웨어 테스트는 빨리 그리고 자주 실패하는 것이 핵심이다
기능에 대한 명세는 간결하고 차츰 진화하는 방식으로 작성되는 것이 가장 좋다
하룻밤 사이에 성공을 거둔다는 개념은 상당히 왜곡된 생각이며, 심지어 위험하기까지 하다. 뭔가 새로운 것을 시작한다면 멀고 긴 여행을 염두에 둬야 한다
진정으로 더 나은 프로그래머가 되고 싶다면 프로그래밍 주변에 있는 다른 모든 것들에 열정을 쏟아야 한다
내가 알고 있는 최고의 프로그래머들은 모두 자신이 하는 일에 대해 평생을 걸 정도의 열정을 품고 있는 사람들이다
진짜로 뭔가를 배우기 위해서는 스스로 실수를 저질러 봐야 한다는 것이다.
에릭슨에게 중요한 것은 경험 그 자체가 아니라 어떤 사람이 현재 가지고 있는 능력을 약간 뛰어넘는 수준의 도전이 끊임없이 부여되고 그에 대응하는 '노력이 담긴 학습'이라고 주장한다
혼자서 일하는 방식으로는 얼마 가지 못한다. 다른 영리한 프로그래머를 곁에 두도록 노력하라. 그들과 함께 일하라. 사무실 안에서 가장 멍청한 존재가 되려고 노력하라.
3부 웹디자인의 원칙
웹사이트의 첫페이지가 어마어마하게 매력적이어야 한다는 사실이다. 첫 페이지가 모든 것을 담을 수는 없다. 하지만 방문자에게 강렬한 첫 인상을 남길 수 있는 기회를 쉽게 포기하지 말아야 한다. 어쩌면 사용자가 보는 것은 바로 그 첫 페이지에 국한될 수도 있기 때문이다
첫페이지를 훌륭한 것으로 만드는 요소
페이지가 상당히 빠르게 로드돼야 한다
애플리케이션이 해결하고 있는 문제가 무엇인지 명확해야 한다
구체적인 예를 제시하라
장애물이 없는 명확한 동작이 가능하게 하라
일부 사용자를 포기하는 것을 의미할지라도 자신에게 진짜로 의미 있는 사용자를 놓치지 않도록 노력하라
먼저 단순한 것들을 디자인한 다음, 필요하면 더 큰 공간으로 옮겨가라. 복잡한 것을 먼저 만들고 작은 곳으로 옮겨가는 것은 잘못된 접근법이다
UI와 관련한 실험은 바람직한 정도가 아니라 꼭 필요한 것이기도 하다
현재의 관례에 대해 그것이 왜 그런 모습을 갖게 됐는지 철저히 이해하라
그러한 관례에서 거리를 두려면 합당한 이유가 있어야 한다
실험을 통한 데이터를 수집하라
실제 사용 데이터를 기반으로 판단을 내려라
4부 테스트
이걸 어떻게 테스트하지?
어떤 종류의 테스틑를 수행해야 하지?
공통적이고, 기대되는 결과는 무엇이지?
흔하지는 않지만 발생 가능한 결과는 무엇이지?
이 코드에는 외부 의존성이 얼마나 있지?
사용자는 제정신이 아니다. 자동화된 테스트 스위트는 실제 베타 테스터들이 현업에서 수행하는 베타 테스트에 미치지 못한다
사용자가 당신의 웹사이트나 애플리케이션에 있는 문제를 보고해주기를 기다린다면 실제로 벌어지고 있는 문제의 자그마한 일부만 보게 될 것이다. 즉, 빙산의 일각이라는 뜻이다. 그리고 실제로 그러하다면 이런 말을 하게 돼서 다소 유감이지만, 당신은 자신의 업무에 충실하지 못한 것이다. 당신의 업무는 애플리케이션의 건강 상태에 대해 사용자보다 더 많이 알아야 하는 것이기 때문이다.
문제는 코드 안에 얼마나 많은 버그가 있느냐가 아니다. 그런 버그를 얼마나 빠르게 수정할 수 있느냐다.
5부 당신의 사용자를 알라
나는 언제나 상아탑 개발을 피하라고 조언해왔다. 상아탑 개발이란 개발자들이 수년 동안 상아탑에 갇힌 채 기술적인 소프트웨어의 마법 자체를 목표로 일하는 것을 의미한다. 이러한 개발자들은 장차 자신이 만들어내는 소프트웨어에 사용자가 어떻게 반응할지에 대해 아무런 생각이 없다. 그들은 사용자와 마지막으로 만났던 게 언제인지 기억할 수도 없을 것이다! 다른 설득력 있는 증거가 없기 때문에 이런 사람들은 세상에 존재하는 다른 모든 사람들이 전부 자신과 같은 개발자라고 가정한다.
그냥 시도해보는 방법밖에 없습니다. 그리고 관찰이 필요합니다. 사용자들의 말도 듣고요. 그렇게 배우는 것입니다. 그다음에 배운 바를 통째로 자리로 돌아가서 필요한 부분을 수정합니다.
프로젝트의 전체 생명주기에 걸쳐 개발자들이 최종 사용자를 수시로 만날 수 있게 해야 한다.
진정한 친구 사이라면 결코 동료 개발자가 직접 디자인한 UI를 출시하도록 내버려 두지 않는다
내가 보기에는 우리에게 의미가 있는 사용자는 중간 단계의 사용자들 뿐이다
훔칠 수 있는 것을 손수 만들지 말라
하이디 애드키슨은 사람들이 어떤 기능을 보고 제품을 구입하지만 실제로는 그 제품에서 원했던 기능을 아예 사용하지 않는 경우가 많다고 지적했다. (중략) 이러한 차이는 사용자가 원하는 바를 단순히 듣기만 하는 것보다 사용자가 실제로 행동하는 것을 관찰하는 것이 왜 그렇게 중요한지를 설명해준다. (중략) 관찰은 중요한 기술이다
얼마나 많은 사용자가 실제로 당신이 만든 애플리케이션을 사용하는가? 그것이 바로 성공을 측정하는 궁극의 척도다
(중요한 것은) 묻지 않고 관찰하는 것이다
사회적인 소프트웨어를 만드는 데 따르는 모든 문제와 답의 출처가 바로 사람들 안에 있다는 점이다
6부 우리가 관심을 둬야 할 것들
발췌 없음
7부 게이밍
발췌 없음
읽어볼만한 내용 <- 실제 챕터명
작가로서, 분석가로서, 기술적인 엔지니어로서, 혹은 무엇이든. 기본 개념을 습득하고 연습하기를 즐기는 법을 배우고, 그 일을 할 때마다 전보다 나아지려고 노력하라. 시간이 지나면서 당신이 한 일의 품질을 자연스럽게 성공으로 연결될 것이다. 하지만 인내심을 가져야 한다. 아주 깊은 인내심을.
기억하라. 당신을 도와 줄 사람은 이 세상에 아무도 없다. 과학을 제외하면 말이다. 그렇기 때문에 자기 스스로 매일 조금씩이라도 각고의 노력을 기울이는 일을 마다하지 않을 준비가 돼 있어야만 한다
