-
실용주의 프로그래머 - 1장 실용주의 철학Study 2023. 6. 6. 03:00
서문
무엇이 실용주의 프로그래머를 만드는가?
- 얼리 어댑터 또는 새로운 것에 빨리 적응하는 사람
- 호기심 많은 사람
- 비판적인 사고의 소유자
- 현실주의자
- 다방면에 능숙한 사람
Tip 1. 자신의 기예(craft)에 관심을 가져라
Tip 2. 자기 일에 대해 생각하라
- 모든 개발 과정에서, 매일, 우리가 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다.
- 절대 기계적으로 일하지 말라
- 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라.
- '생각하라!'가 실용주의 프로그래머의 계명(mantra)이다.
실용주의 프로그래머와 규모가 큰 팀
- "우리가 단지 돌을 자를지라도 언제나 대성당을 마음속에 그려야 한다."
끊임없는 과정
- 완벽한 잔디밭을 만드는 법
- 매일 아침 이슬을 털어 주고, 이틀에 한 번 잔디를 깎아 주고, 일주일에 한 번 잔디밭을 골라주면 된다.
- 그렇게 500년만 하면 완벽한 잔디밭을 만들 수 있다.
- 카이젠; 꾸준히 조금씩 자주 개량한다.
- 매일같이 지금 있는 기술들을 다음고, 기술 목록에 새로운 도구들을 추가하라.
1장 실용주의 철학
- 실용주의 프로그래머는 무엇이 다른가?
- 문제와 해법에 접근하는 태도와 방식, 철학에 차이가 있다고 생각한다.
- 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다.
- 자신이 하는 모든 일에 책임을 진다.
Topic 1. 당신의 인생이다.
나는 당신의 기대대로 살기 위해 이 세상에 있는 게 아니고, 당신도 내 기대대로 살기 위해 이 세상에 있는 게 아니다.
- 브루스 리(Bruce Lee)- "왜 직접 바꾸지 않습니까?"
Tip3 당신에게는 Agency가 있다.
- "당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다." - 마틴 파울러
Topic 2. 고양이가 내 소스 코드를 삼켰어요
약점을 보이는 것에 대한 두려움이 가장 큰 약점이다.
- J. B 보쉬에- 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다.
- 우리는 자신의 능력에 자부심을 가질 수 있지만, 실수나 무지 같은 단점도 인정해야만 한다.
- 정직하고 솔직해져야 한다.
팀 내 신뢰
책임지기
- 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라.
- 해결책을 찾아내야 하는 사람은 나이다.
Tip 4. 어설픈 변명 말고 대안을 제시하라.
- 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
- 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해 보라.
Topic 3. 소프트웨어 엔트로피
- 소프트웨어의 무질서도가 증가할 때 우리는 이를 '소프트웨어의 부패'라고 일컫는다. 이를 보다 긍정적으로 '기술 부채'라고 부르기도 한다.
Tip 5. 깨진 창문을 내버려 두지 말라.
- 나쁜 설계, 잘못된 결정, 형편없는 코드 등이 모두 깨진 창문이다.
- 발견하자마자 바로 고쳐라.
- 어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라.
Topic 4. 돌멩이 수프와 삶은 개구리
- 큰 무리 없이 요구할 수 있을 만한 것을 찾아라. 그리고 그걸 잘 개발하라. 일단 무언가 생기면 사람들에게 보여 주고 그들이 경탄하게 하라.
- 물러나 앉아 우리가 애초에 원했던 그 기능을 추가해 달라고 사람들이 부탁하기 시작할 때까지 기다려라.
- 계속되는 성공에 합류하기란 쉽다.
- 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다.
Tip 6. 변화의 촉매가 되라.
Tip 7. 큰 그림을 기억하라.
- 큰 그림에 늘 주의를 기울여라.
- 당장하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라.
Topic 5. 적당히 괜찮은 소프트웨어
우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.
- 셰익스피어- 실세계에서는 진정 완벽한 것을 만들어 내기란 불가능하다.
- 사용자나 미래의 유지 보수 담당 아니면 자기 자신의 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다.
우리는 더 생산적이 되고 사용자는 한층 더 행복해할 것이다. - '적당히 괜찮은'이라는 표현은 너절하거나 형편없는 코드를 의미하지 않는다.
사용자의 요구 사항을 충족해야 한다.
타협 과정에 사용자를 참여시켜라
Tip 8. 품질을 요구 사항으로 만들어라.
- 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
- 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.
멈춰야 할 때를 알라
- 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라.
Topic 6. 지식 포트폴리오
지식에 대한 투자가 언제나 최고의 이윤을 낸다.
- 벤저민 프랭클린- 지식은 '기한이 있는 자산'이다.
- 새로운 것을 배우는 능력은 우리의 가장 중요한 전략 자산이다.
지식 포트폴리오
- 주기적인 투자
- 다각화
- 리스크 관리
- 싸게 사서 비싸게 팔기
- 검토 및 재조정
Tip 9. 지식 포트폴리오에 주기적으로 투자하라.
목표
- 매년 새로운 언어를 최소 하나는 배워라.
- 기술 서적을 한 달에 한 권씩 읽어라.
- 기술 서적이 아닌 책도 읽어라.
- 수업을 들어라.
- 지역 사용자 단체나 모임에 참여하라.
- 다른 환경에서 실험해 보라.
- 요즘 흐름을 놓치지 말라.
- 학습 과정에서 사고가 확장된다.
- 사고 간의 교접이 중요하다.
- 새로 배운 교훈을 현재 프로젝트에 적용하도록 노력하라.
학습의 기회
- 누군가의 질문에 답이 무엇인지 전혀 알지 못한다면 거리낌 없이 그걸 인정하고 답을 찾기 위한 도전을 하라.
비판적 사고
- 우리가 읽거나 듣는 것에 대해 비판적으로 생각하라.
- 자신의 도그마(dogma)가 유일한 답이라고 주장하는 광신도를 조심하라.
Tip 10. 읽고 듣는 것을 비판적으로 분석하라.
- 왜냐고 다섯 번 묻기
- 누구에게 이득이 되나?
- 어떤 맥락인가?
- 언제 혹은 어디서 효과가 있을까?
- 왜 이것이 문제인가?
Topic 7. 소통하라!
나는 무시당하느니 차라리 샅샅이 훑어보는 시선이 낫다고 봐요.
- 메이 웨스트- 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다.
Tip 11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.
청중을 알라
- 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.
- 청중의 요구와 관심, 능력을 이해할 필요가 있다.
말하고 싶은 게 무언지 알라
- 무엇을 말할지 미리 계획하라.
- 의사소통하고 싶은 아이디어들을 적은 다음 제대로 전달하는 데 필요한 전략을 몇 개 세워라.
- 상대가 무엇을 원하는지 알았다면 원하는 것을 이루어 주자.
때를 골라라
- 말하는 내용뿐 아니라 말하는 시점도 적절하게 하라.
스타일을 골라라
- 전달하는 스타일을 청중에 어울리도록 조정하라.
멋져 보이게 하라
- 아이디어는 중요하다. 그러니 마땅히 청중에게 멋지게 전달하기 위한 수단을 준비해야 한다.
청중을 참여시켜라
- 피드백을 받고 적용하라.
경청하라
- 다른 사람들이 우리가 하는 말을 경청해 주길 바란다면 그들의 말을 경청하라.
응답하라
- 언제나 이메일과 음성 메시지에 답을 하라.
Tip 12. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
문서화
- 문서화는 전체 개발 프로세스의 필요 불가결한 부분이다.
- 코드 안에 문서를 두어라.
소스 코드의 주석으로 보기 좋은 문서를 쉽게 생성할 수 있다.
Tip 13. 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
반응형