실용주의 프로그래머 9장 < 실용주의 프로젝트 >
Today reading range
- 오늘 읽은 범위
실용주의 프로그래머 9장 < 실용주의 프로젝트 >
Impressive content
- 인상 깊었던 내용
Topic 49. 실용주의 팀
소프트웨어 개발 방법론의 목표는 사람들이 함께 일하는 것을 돕는 것이다. -377p.
우리가 말하는 팀은 작고 보통은 그 자체로 안정적인 존재다. 50명은 팀이 아니다.큰 무리다. ... 실용주의 팀은 작다. ... 모두가 서로 잘 알고, 신뢰하며, 의존해야한다.
품질은 팀의 문제다. - 379p.
팀 전체가 깨진 창문을 용납하지 않아야한다. 사소한 결점을 아무도 고치지 않고 놔두어서는 안되고, 반드시 제품의 품질에 책임을 져야 한다.
품질은 팀원 모두가 제각기 기여할 때만 보장되기 때문이다. 품질은 애초에 제품에 포함된 것이지 나중에 덧붙이는 것이 아니다.
"시간이 나면 그때" 히겠디는 것은 "영원히 하지 않겠다"는 것이다.
- 구형 시스템 유지 보수
- 프로세스 회고와 개선
- 새로운 기술 탐험
30분 정도 투자해서 괴짜스러운 로고를 만들어서 사용하라. -383p.
좋은 의사소통이 이런 문제를 피하는 핵심이다. 여기서 "좋은" 이란 즉각적이고 매끄러운것을 말한다. - 383p.
DRY를 지키려면 서로 관심을 유지하라
< 항목 12. 예광탄 >을 사용하여, 처음에는 작고 제한적일지라도 시스템의 끝에서 끝까지 전체에 걸쳐 있는 단일 기능을 개발할 것을 추천한다. -384p.
자동화는 모든 프로젝트 팀에게 필수 불가결한 요소다.
팀은 개인으로 이루어진다는 사실을 명심하라. 각 팀원이 자신의 방식대로 빛나게 하라. -385p.
Topic 50. 코코넛만으로는 부족하다
속아 넘어가지 말라. 특정한 결과물, 피상적인 구조나 정책, 프로세스, 방법론만으로는 부족하다. -388p.
Tip 87 유행하는 것이 아니라 실제로 잘 맞는 것을 사용하라.
"잘 맞는 것"을 어떻게 알 수 있을까? 가장 근본적인 실용주의 기법을 적용하면 된다.
한번 해 보라.
사업방향이 선회하고 계속 번성함에 따라 이들 역시 또 다른 방식을 사용하고 있을 것이다. 이것이 이 회사들이 성공한 진짜 비결이다. -389p.
진짜 목표는 작동하는 소프트웨어를 제공 함으로써 사용자가 즉각적으로 새로운 일을 할 수 있게 되는 것이다.
...
모든 목표가 그렇듯 계속 올바른 방향을 바라보는 것이 중요하다.
Tip 88 사용자에게 필요할 때 제공하라.
한 가지 방식이 너무 굳어져 버리면 더 이상 빠르게 적응할 수 없게 된다.
코코넛을 사용하고 있는지도 모른다.
Topic 51. 실용주의 시작 도구
생각 없이 행할 수 있는 중요한 작업의 수가 늘어남에 따라 문명은 발전한다.
- 엘리프리드 노스 화이트헤드
일상적인 작업은 모두 자동화해야 한다.
수작업은 일관성을 운에 맡긴다. 반복 가능성도 보장받지 못한다. 특히 그 작업절차를 여러 사람이 서로 다르게 해석할 여지가 있다면 더 그렇다.
이 셋은 모든 프로젝트를 지탱하는 기둥이다.
Tip 89 버전 관리 시스템으로 빌드, 테스트, 릴리스를 운용하라.
우리는 지금 당장 버그를 찾아 나서도록 자신을 몰아세우지만, 덕분에 나중에 다른 사람이 자기 버그를 발견하게 되는 딱한 상황은 피할 수 있다. -394P.
코드를 작성하자마자 테스트를 해야한다.
즉, 테스트 환경은 실제 환경과 최대한 비슷해야 한다. 두 환경의 차이에서 버그가 번식한다. -395p.
버그가 없는 시스템일지언정 잘못된 문제를 푼다면 별 쓸모가 없다.
어떤 버그를 감지해 내는 테스트를 작성한 후에, 그 버그가 의도적으로 생기도록 한 다음 테스트가 경보를 울리는지 확인하라. -396p.
우연히 코드의 모든 줄이 실행될지라도 그게 전부가 아니다. 정말로 중요한 것은 프로그램이 갖는 상태state의 개수다. -398p.
한번 인간 테스터가 버그를 찾았다면 더는 인간 테스터가 그 버그를 만나서는 안된다. -399p.
Tip 95 수작업 절차를 사용하지 말라.
사람들은 컴퓨터처럼 같은 일을 반복할 수 없을 뿐더러 그런 것을 기대해서도 안 된다. -400p.
Topic 52. 사용자를 기쁘게 하라.
당신이 사람들을 황홀하게 만들 때, 당신의 목표는 그들로부터 돈을 벌거나, 당신이 원하는 일을 시키는 것이 아닙니다. 사람들을 커다란 기쁨으로 충만하게 하는 것입니다.
- 가이 가와사키
개발자로써 우리의 목표는 사용자를 기쁘게 하는 것이다. -402p.
여러분의 사용자가 진짜로 원하는 것은 코드가 아니다.
"이 프로젝트가 끝나고 한달(혹은 일 년이라든지) 후에 우리가 성공했는지 어떻게 알 수 있을 까요?"
여러분의 직함이 명목상으로는 "소프트웨어 개발자"나 "소프트웨어 엔지니어" 비슷한 이름일지 몰라도 진정한 여러분의 직함은 "문제 해결사"다. 이것이 우리가 하는 일이고, 실용주의 프로그래머의 본질이다. -404p.
Topic 53. 오만과 편견.
실용주의 프로그래머는 책임을 회피하지 않는다.
Tip 97 자신의 작품의 서명하라.
같은 맥락에서, 다른 사람의 코드를 존중해야한다. -405p.
우리는 소유권에 대한 긍지를 보고싶다. "이걸 내가 만들었고, 내 작품의 품질을 보증합니다."
Thoughts I had while reading the book
- 오늘 책을 읽으면서...
처음 1장을 읽기 시작하면서 한참 남았구나 생각했는데 벌써 9장을 다 읽다니 놀랐다. 실용주의 프로그래머는 내가 바라던 개발환경과 개발법에 대한 이야기였다. 정말 이런 개발을 할 수 있다면 너무 좋을것같고 그렇게 하기위해 노력할거다. 이번 장에 자동화 부분에서는 정말 많이 공감했다. 전에 일하던 환경에서 나는 업무의 자동화를 원했다. 하지만 이루어지기 어려운 환경이였고 그래서 개발자가 되고싶었다.(개발자가되면 뭐든 되겠지)
도전해볼것
- 프레덕스 브룩스의 <<맨머스 머신>>을 읽어라. 추가 점수 항목이 있다. 두 권을 사서 두 배로 빨리 읽어라.
- 혹시 여러분의 일일 빌드나 지속적 빌드는 자동으로 수행되는데 서비스 배포는 자동이 아닌가? 왜인가? 서비스 서버에 특별한 무엇이라도 있는가?
