1. 실용주의 철학
29 May 2023 | Progmatic Programmer
1장. 실용주의 철학
Topic 1. 당신의 인생이다
나는 당신의 기대대로 살기위해 이 세상에 있는게 아니고, 당신도 내 기대대로 살기 위해 이 세상에 있는게 아니다
- 브루스 리 (Bruce Lee)
- 개발자들은 여러 불만이 있다.
- 기술의 변화를 쫓아가지 못한다
- 자신의 성과를 몰라준다
- 월급이 너무 적다
- 팀 분위기가 별로다
- 미국이나 유럽으로 가고싶다
- 재택근무가 하고싶다
- …
- Answer: 왜 직접 바꾸지 않는가?
- 소프트웨어 개발은 가장 주도권이 있는 직업 중 하나이다
- 하지만 개발자들은 변화를 피하는 것 같음, 따라서 다음 팁이 가장 중요하다
Tip3 : 당신에게는 Agency* 가 있다
*Agency : the ability to take action or to choose what action to take
Martin Fowler : 당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.
- 이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라
관련 항목
- 항목 4. 돌멩이 수프와 삶은 개구리
- 항목 6. 지식 포트폴리오
Topic 2. 고양이가 내 소스 코드를 삼켰어요
약점이 보이는 것에대한 두려움이 가장 큰 약점이다.
- J.B.보쉬에
- 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것
- 자신의 경령 개발
- 자신의 학습 및 교육
- 자신의 프로젝트
- 자신의 일상 업무
- 책임을 지는 일이 분명 프로그래밍에서 가장 즐거운 부분은 아니지만, 반드시 일어난다
팀 내 신뢰
- 여러분의 팀이 여러분을 믿고 의지할 수 있어야 한다. 여러분도 또한 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다.
- 연구에 따르면 창의성과 공동 작업에는 팀 내의 신뢰가 절대적으로 필요로 함
- 신뢰에 바탕을 둔 건강한 환경에서는 안전하게 여러분의 생각을 말하거나 아이디어를 제안 할 수도 있음
책임지기
- 책임은 여러분이 적극적으로 동의하는 것
- 뭔가 제대로 처리하겠다고 약속을 하더라도 모든 면을 반드시 직접 통제하지는 못함
- 개인적으로 최선을 다하는 것이 전부가 아님
- 여러분이 통제할 수 없는 위험 요소가 있지 않은지 분석해야 함
- 여러분에겐 불가능하거나 위험 요소가 너무 큰 상황, 또는 결과가 윤리적으로 심각하게 우려되는 상황에서는 책임을 맡지 않을 권리가 있다
- 결과에 대한 책임을 지기로 했다면 나중에 그 결과를 감당해야 함
- 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력해야 함
- 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 마라
- 해결책을 찾아내야 하는 사람은 여러분이다.
Tip4 : 어설픈 변명할고 대안을 제시하라
- 변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.
- 작업을 완료하려면 자원이 더 필요할 수도 있다
- 혹은 사용자와 더 시간을 보내야 할 수도 있을 것이다
- 여러분 자신에게 도움이 필요할 수도 있다
- 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
- 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해보라. 그래도 꼭 해야겠다면 여러분의 고양이에게 먼저 해 보라.
관련 항목
- 항목 49. 실용주의 팀
도전해 볼 것
- 다른 직업군이 변명하는 걸 상상해보자, 그 사람이나 회사에 무슨 생각이 드는가? (변명하지 말자)
- “잘 모르겠어요” 다음에는 “하지만 알아볼게요”가 붙어야 한다. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.
Topic 3. 소프트웨어 엔트로피
- 엔트로피의 증가는 소프트웨어 개발에 많은 영향을 끼친다
- 엔트로피 : 시스템 내의 무질서한 정도
- 열역학 법칙에 따르면 우주의 엔트로피는 점점 증가한다.
- 소프트웨어의 무질서도가 증가할 때 우리는 이를 소프트웨어의 부패라고 한다 또는 기술 부채 (Technical Debt)라고 한다.
- 무엇이 소프트웨어를 부패하게 만들까?
- 도심에서 어떤 건물은 아름답고 깨끗한 반면, 어떤 건물은 형편없다, 무엇이 그렇게 만들까? -> 깨진 창문
Tip5 : 깨진 창문을 내버려 두지 말라
- “깨진 창문”을 고치지 않은 채로 내버려 두지 말라.
- 나쁜 설계
- 잘못된 결정
- 형편없는 코드
- 발견하자마자 바로 고쳐라
- 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라 -> 주석 처리 및 TODO 처리
- 깨끗하고 잘 기능하던 시스템이 일단 창문이 깨지기 시작하면 급속도로 악화되는 경우를 많이 보았음
- 방치는 다른 어떤 요인보다도 부패를 더 가속화 시킴
- 엔트로피가 우리를 지배하도록 내버려 두지 말라
우선 망가트리지 말라
- 깨진 창문 하나는 내리막길로 가는 첫걸음이다.
- 깨진 창문이 꽤 있는 프로젝트에서 일할 때는 ‘나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐’ 라는 사고에 빠지기 쉽다
- 여러분이 속한 프로젝트의 코드가 깨끗하고 아름답다면, 즉 깔끔하고 잘 설계되었으며 우아하다면, 특별히 주의를 더 많이 기울여서 엉망으로 만들지 않으려 할 것임
- 명심하라 “깨진 창문은 없어야 한다”
관련 항목
- 항목 10. 직교성
- 항목 40. 리팩터링
- 항목 44. 이름 짓기
Topic 4. 돌멩이 수프와 삶은 개구리
- “시작 피로 Start-up fatigue”를 이겨내야 할 필요가 있다.
- 큰 무리 없이 요구할 수 있을 만한 것을 찾아라
- 그걸 잘 개발하라
- 일단 무언가 생기면 사람들에게 보여 주고 그들이 경탄하게 하라
- 그러고는 “물론 ……를 추가하기만 하면 더 나아질 수도 있겠죠” 라고 말하면서 그다지 중요하지 않은 척 가장하라
- 물러나 앉아 여러분이 애초에 원했던 그 기능을 추가해 달라고 사람들이 부탁하기 시작할 때까지 기다려라
- 계속되는 성공에 합류하기란 쉽다
- 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다. (허락은 얻는 것보다 용서를 구하는 것이 더 쉽다)
Tip6 : 변화의 촉매가 되라.
마을 사람의 경우
- 프로젝트는 서서히, 하지만 가차없이 구제불능인 상태가 되어 버린다.
- 소프트웨어 참사는 대부분 너무 작아 알아채기 힘들 정도의 문제에서 시작됨
- 프로젝트는 대부분 어느날 갑자기 폭주한다.
- 시스템은 애초의 명세와는 조금씩 조금씩 기능이 달라짐
Tip 7 : 큰 그림을 기억하라
- 냄비안의 개구리처럼 서서히 온도가 바뀐다면 알아차리기 힘들것이다
- 개구리처럼 되자 말라. 큰 그림에 늘 주의를 기울여라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨일이 벌어지는지 늘 살펴보라.
관련 항목
- 항목 1. 당신의 인생이다
- 항목 38. 우연에 맡기는 프로그래밍
도전해 볼 것
- 변화를 촉진하려고 할 때 여러분이 좋은 영향을 끼칠 것인지 아닌지는 어떻게 알 수 있을까?
- 주변을 살피고 의식하는 습관을 들이고 여러분의 프로젝트에 적용하라
Topic 5. 적당히 괜찮은 소프트웨어
우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.
- 셰익스페어, «리어왕» 1막 4장
- 실세계엥서는 진정 완벽한 것을 만들어 내기란 불가능 함
- 특히 버그 없는 소프트웨어는 더더욱. 시간, 기술, 기질 같은 것이 모두 힘을 합쳐 우리를 방해한다.
- 적당히 괜찮은 소프트웨어를 만들도록 자신을 단련할 수 있다.
- 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 됨
- “적당히 괜찮은” != 너절하거나 형편없는 코드
- 중요한 것은, 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에 사용자가 참여할 기회를 가져야 한다는 것
타협 과정에 사용자를 참여시켜라
- 소프트웨어가 얼마나 종아야 하는지 사용자에게 물어본 적이 한 번이라도 있는가?
- 새로운 상품을 만들고 있다면 제약 조건이 좀 다를 것
- 여러분이 만드는 시스템의 범위와 품질은 해당 시스템의 요구 사항 중 하나로 논의되어야 함
Tip8 : 품질을 요구 사항으로 만들어라
- 놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당잠 좀 불편한 소프트웨어를 사용하고 싶어 함
- 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
- 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것 (Lean Start-up, Agile?)
멈춰야 할 때를 알라
- 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라
- 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다.
- 그래도 괜찮다. 완벽해지기란 불가능하다.
관련 항목
- 항목 45. 요구 사항의 구렁텅이
- 항목 46. 불가능한 퍼즐 풀기
도전해 볼 것
- 여러분이 일상적으로 사용하는 소프트웨어 도구나 운영체제를 보라. 이를 개발하는 조직이나 개발자들이 완벽하지 않다고 여겨지는 소프트 웨어를 거리낌 없이 출시한다는 증거를 찾을 수 있는가?
- 사용자로써 (1) 그들이 모든 버그를 제거할 때까지 기다리겠는가?
- (2) 복잡한 소프트웨어를 사용하면서 어느 정도의 버그는 감내하겠는가?
- (3) 결함이 더 적은 간단한 소프트웨어를 선택하겠는가?
- 모듈화가 소프트웨어 출시에 미치는 영향을 생각해보라
- 모놀리식 소프트웨어 블록을 필요한 품질 수준으로 만드느 것
- 마이크로서비스들로 설계된 시스템을 만드는 것 중 어느게 오래 걸릴까? 장단점은?
- 기능 블로트 (feature bloat) 현상에 빠진 유명한 소프트웨어를 떠올릴 수 있는가?
Topic 6. 지식 포트폴리오
지식에 대한 투자가 언제나 최고의 이윤을 낸다.
- 벤저민 프랭클린
- 여러분의 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다.
- 하지만 불행히도 이 자산은 기한이 있는 자산이다.
- 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다.
- 여러분의 지식 가치가 점점 떨어짐에 따라 회사나 클라이언트가 보는 여러분의 가치 역시 떨어짐
- 새로운 것을 배우는 능력은 여러분의 가장 중요한 전략 자산임
지식 포트폴리오
- 지식 포트폴리오 관리는 투자 포트폴리오 관리와 매우 유사하다.
- 진지한 투자자는 주기적으로 투자하는 습관이 있다.
- 장기적인 성공의 열쇠는 다각화다
- 똑똑한 투자자는 보수적인 투자와 위험이 크지만 보상이 높은 투자 사이에서 포트폴리오의 균형을 잘 맞춘다.
- 투자자는 최대 수익을 위해 사게 사서 비싸게 팔려고 한다.
- 포트폴리오는 주기적으로 재검토하고 재조정해야 한다.
- 성공적인 경혁을 위해서는 이와 동일한 지침을 사용해서 지식 포트폴리오에 투자해야 한다.
포트폴리오 만들기
주기적인 투자
- 여러분의 지식 포트폴리오에 소량으로라도 주기적으로 투자해야 함
- 습관 자체가 금액의 합계만큼이나 중요하다
다각화
- 더 여러 가지를 알수록 자신의 가치는 더욱 높아진다.
- 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 한다.
- 하지만 거기서 멈추지 말라. 컴퓨터 분야의 지형은 빠르게 변한다.
- 기술외의 분야도 포함하여 여러분에게 필요한 다른 역량도 잊지 말라
리스크 관리
- 기술은 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 다양한 스펙트럼 위에 존재함
- 여러분의 기술 달걀을 모두 한 바구니에 담지 말라
싸게 사서 비싸게 팔기
- 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가 된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.
- 예시 : JAVA
검토 및 재조정
- 이 산업은 매우 동적이다.
- 한동안 사용하지 않던 데이터베이스 기술을 복습해야 할 필요
- 다른 언어를 시도해 본 덕에 새로운 일자리를 구할 때 더 유리할 수 있음
- 이 모든 지침 중에 제일 중요한 것은 가장 간단하게 실행할 수 있는 것이다.
Tip9 : 지식 포트폴리오에 주기적으로 투자하라
목표
매년 새로운 언어를 최소 하나는 배워라
- 다른 언어는 동일한 문제를 다르게 푼다.
- 몇 가지 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에 도움이 된다.
기술 서적을 한 달에 한 권씩 읽어라
- 깊이 있는 지식을 원하다면 긴 글 형식의 책을 읽어야 한다
- 현재 프로젝트와 관련 있는 흥미로운 주제의 기술 서적을 서점에서 찾아보라
- 습관이 들면 한달에 한 권씩 일어라
- 현재 사용하는 기술을 일단 완전히 익혔다면, 가지를 쳐서 지금 하는 프로젝트와 관련 없는 분야까지 공부 범위를 넓혀라
기술 서적이 아닌 책도 읽어라
수업을 들어라
지역 사용자 단체나 모임에 참여하라
다른환경에서 실험해 보라
요즘 흐름을 놓치지 말라
- 투자를 지속하는 것이 중요하다. 한 기술의 새로운 용어나 기능에 익숙해지면 다음으로 넘어가 새로운 것을 배워라
- 이런 기술들을 프로젝트에서 영영 사용하지 않거나 심지어 자신의 이력서에 올려좋지 않아도 상관없다.
- 학습 과정에서 사고가 확장될 것이다. 이로 인해 새로운 가능성이 열리고 문제를 해결하는 새로운 방법이 떠오를 것이다.
- 사고 간의 교접(cross-pollination)이 중요하다.
- 새로이 배운 교훈을 현재 프로젝트에 적용하도록 노력하라.
학습의 기회
- 누군가 질문을 했을 때 그걸 모르는 경우
- 답을 찾기 위한 개인적인 도전으로 생각하자
- 주위에 물어보자
- 웹을 검색해보자
- 사용자용 문서뿐 아니라 학술 자료도 찾아보자
- 스스로 답을 찾지 못하면 답을 찾아줄 수 있는 사람을 찾자
- 다른 사람과 이야기함으로써 개인 네트워크를 구축하는 데 도움이 되기도한다
- 언제나 무엇을 읽을 수 있는 준비를 하자
비판적 사고
- 마지막으로 중요한 점은 여러분이 읽거나 듣는 것에 비판적으로 생각하는 것
Tip10 : 읽고 듣는 것을 비판적으로 분석하라.
- 비판적 사고는 그 자체만으로 하나의 학문을 이룬다.
왜냐고 다섯번 묻기 Five Whys
누구에게 이익이 되나?
어떤 맥락인가?
- 모든 일에는 각각의 맥락이 있기에, ‘만병통치약’인 해결책은 대게 통하지 않는다.
언제 혹은 어디서 효과가 있을까?
왜 이것이 문제인가?
관련 항목
- 항목 1. 당신의 인생이다
- 항목 22. 엔지니어링 일지
도전해 볼 것
- 이번 주부터 새오운 언어를 배우기 시작하라
- 새 책을 하나 읽기 시작하라
- 매우 상세한 구현과 코딩을 하고 있다면 설계와 아키텍처에 대한 책을 한 권 읽어라
- 고차원의 설계를 하고 있다면 코딩 테크닉을 다루는 책을 한 권 읽어라
- 밖으로 나가서 지금 수행하고 있는 프로젝트에 관여하지 않는 사람 혹은 같은 회사에 근무하지 않는 사람과 기술에 관한 대화를 하라
Topic 7. 소통하라!
나는 무시당하느니 차라리 샅샅이 훑어보는 시선이 낫다고 봐요
- 메이 웨스트
- 최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다.
- 효과적인 소통 없이는 아무리 훌륭한 아이디어라고 고립되고 만다.
Tip11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.
청중을 알라
- 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.
- 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다
- 다른 모든 형태의 의사소통과 마찬가지로 여기서도 비결은 피드백을 모으는 것
- 소통하면서 청중에 대한 지식을 쌓아 나가라
말하고 싶은게 무언지 알라
- 무엇을 말할지 미리 계획하라. 개요를 작성하라. 그리고 자문하라
- 이렇게 하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나? 그렇게 될 때까지 다듬어라
- 문서를 작성할 때만 그런게 아니다. 중요한 회의, 주요 클라이언트와의 대화 때도 제대로 전달하는데 필요한 전략을 몇 개 세워라
때를 골라라
- 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
- 소스 코드 일부가 사라진 일로 상사에게 막 꾸지람을 들은 관리자를 붙잡고 소스 코드 저장소에 대한 아이디어를 이야기해 주면 경청할 것이다.
스타일을 골라라
- 전달하는 스타일을 청중에 어울리도록 조정하라
- 어떤 스타일을 원하는지 청자에게 물어보라
- 하지만 누군가가 뭔가를 짤막하게 설명해 달라고 부탁하는데, 그 설명을 종이 대여섯 장 이하로 줄일 방법이 없다는 생각이 들면, 사실이 그렇다고 말하라.
멋져 보이게 하라
- 멋진게 아닌 것보다 훨씬 낫다
- 최신 기술을 활용하라
청중을 참여시켜라
- 청중을 통해 피드백을 받고 그들의 머릿속을 도용하라
경청하라
- 여러분이 다른 사람들의 말을 귀 기울여 듣지 않는다면 그들 역시 여러분의 말을 듣지 않을 것이다
- 질문을 해서 사람들이 이야기를 하도록 북돋우거나, 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라
응답하라
- 언제나 이메일과 음성 메시지에 답을하라.
- 심지어 단순히 “다음에 답해 드리겠습니다” 이더라도
- 늘 사람들에게 응답해 주면 때때로 저지르는 실수에 대해 훨씬 더 관대해질 것이고, 여러분이 그 사항을 아직 잊지 않았다고 느끼게 할 것이다.
Tip12 : 무엇을 말하는가와 어떻게 말하는가 모두 중요하다
문서화
- 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다
Tip13 : 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
- 소스코드의 주석으로 보기 좋은 문서를 쉽게 생성할 수 있다
- 모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다
요약
- 청중을 알라.
- 말하고 싶은게 무언지 알라.
- 때를 골라라.
- 스타일을 골라라.
- 멋져 보이게 하라.
- 청중을 참여시켜라.
- 경청하라.
- 응답하라.
- 코드와 문서를 함께 둬라.
관련 항목
- 항목 15. 추정
- 항목 18. 파워 에디팅
- 항목 45. 요구 사항의 구렁텅이
- 항목 49. 실용주의 팀
도전해 볼 것
- 맨먼스 미신과 피플웨어를 비롯하여 팀 내의 의사소통에 관한 내용이 실려 이씨는 훌륭한 책이 몇 권 읽다. 앞으로 18개월 이내에 이 책들을 반드시 읽을 수 있도록 노력하라
- 다음번 pt때 이 토픽의 내용을 적용해보라 그리고 피드백을 들어라
온라인 의사소통
- ‘보내기’ 버튼을 누르기 전에 검토를 하라
- 맞춤법에 맞는지, 자동 교정이 엉뚱하게 바꾸지는 않았는지 확인
- 형식을 간단하고 명확하게
- 답장할 때 원본 메시지의 인용은 최소한으로
- 다른 사람의 이메일을 인용한다면 누구의 것인지 밝히고 본문 속에서 인용
- 화내고 욕하거나 논란을 부추기는 글을 보내지 말라
- 보내기 전에 받는 사람 목록을 확인하라
1장. 실용주의 철학
Topic 1. 당신의 인생이다
나는 당신의 기대대로 살기위해 이 세상에 있는게 아니고, 당신도 내 기대대로 살기 위해 이 세상에 있는게 아니다
- 브루스 리 (Bruce Lee)
- 개발자들은 여러 불만이 있다.
- 기술의 변화를 쫓아가지 못한다
- 자신의 성과를 몰라준다
- 월급이 너무 적다
- 팀 분위기가 별로다
- 미국이나 유럽으로 가고싶다
- 재택근무가 하고싶다
- …
- Answer: 왜 직접 바꾸지 않는가?
- 소프트웨어 개발은 가장 주도권이 있는 직업 중 하나이다
- 하지만 개발자들은 변화를 피하는 것 같음, 따라서 다음 팁이 가장 중요하다
Tip3 : 당신에게는 Agency* 가 있다
*Agency : the ability to take action or to choose what action to take
Martin Fowler : 당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.
- 이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라
관련 항목
- 항목 4. 돌멩이 수프와 삶은 개구리
- 항목 6. 지식 포트폴리오
Topic 2. 고양이가 내 소스 코드를 삼켰어요
약점이 보이는 것에대한 두려움이 가장 큰 약점이다.
- J.B.보쉬에
- 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것
- 자신의 경령 개발
- 자신의 학습 및 교육
- 자신의 프로젝트
- 자신의 일상 업무
- 책임을 지는 일이 분명 프로그래밍에서 가장 즐거운 부분은 아니지만, 반드시 일어난다
팀 내 신뢰
- 여러분의 팀이 여러분을 믿고 의지할 수 있어야 한다. 여러분도 또한 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다.
- 연구에 따르면 창의성과 공동 작업에는 팀 내의 신뢰가 절대적으로 필요로 함
- 신뢰에 바탕을 둔 건강한 환경에서는 안전하게 여러분의 생각을 말하거나 아이디어를 제안 할 수도 있음
책임지기
- 책임은 여러분이 적극적으로 동의하는 것
- 뭔가 제대로 처리하겠다고 약속을 하더라도 모든 면을 반드시 직접 통제하지는 못함
- 개인적으로 최선을 다하는 것이 전부가 아님
- 여러분이 통제할 수 없는 위험 요소가 있지 않은지 분석해야 함
- 여러분에겐 불가능하거나 위험 요소가 너무 큰 상황, 또는 결과가 윤리적으로 심각하게 우려되는 상황에서는 책임을 맡지 않을 권리가 있다
- 결과에 대한 책임을 지기로 했다면 나중에 그 결과를 감당해야 함
- 실수를 저지르거나 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방안을 제안하도록 노력해야 함
- 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 마라
- 해결책을 찾아내야 하는 사람은 여러분이다.
Tip4 : 어설픈 변명할고 대안을 제시하라
- 변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.
- 작업을 완료하려면 자원이 더 필요할 수도 있다
- 혹은 사용자와 더 시간을 보내야 할 수도 있을 것이다
- 여러분 자신에게 도움이 필요할 수도 있다
- 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
- 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해보라. 그래도 꼭 해야겠다면 여러분의 고양이에게 먼저 해 보라.
관련 항목
- 항목 49. 실용주의 팀
도전해 볼 것
- 다른 직업군이 변명하는 걸 상상해보자, 그 사람이나 회사에 무슨 생각이 드는가? (변명하지 말자)
- “잘 모르겠어요” 다음에는 “하지만 알아볼게요”가 붙어야 한다. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.
Topic 3. 소프트웨어 엔트로피
- 엔트로피의 증가는 소프트웨어 개발에 많은 영향을 끼친다
- 엔트로피 : 시스템 내의 무질서한 정도
- 열역학 법칙에 따르면 우주의 엔트로피는 점점 증가한다.
- 소프트웨어의 무질서도가 증가할 때 우리는 이를 소프트웨어의 부패라고 한다 또는 기술 부채 (Technical Debt)라고 한다.
- 무엇이 소프트웨어를 부패하게 만들까?
- 도심에서 어떤 건물은 아름답고 깨끗한 반면, 어떤 건물은 형편없다, 무엇이 그렇게 만들까? -> 깨진 창문
Tip5 : 깨진 창문을 내버려 두지 말라
- “깨진 창문”을 고치지 않은 채로 내버려 두지 말라.
- 나쁜 설계
- 잘못된 결정
- 형편없는 코드
- 발견하자마자 바로 고쳐라
- 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라 -> 주석 처리 및 TODO 처리
- 깨끗하고 잘 기능하던 시스템이 일단 창문이 깨지기 시작하면 급속도로 악화되는 경우를 많이 보았음
- 방치는 다른 어떤 요인보다도 부패를 더 가속화 시킴
- 엔트로피가 우리를 지배하도록 내버려 두지 말라
우선 망가트리지 말라
- 깨진 창문 하나는 내리막길로 가는 첫걸음이다.
- 깨진 창문이 꽤 있는 프로젝트에서 일할 때는 ‘나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐’ 라는 사고에 빠지기 쉽다
- 여러분이 속한 프로젝트의 코드가 깨끗하고 아름답다면, 즉 깔끔하고 잘 설계되었으며 우아하다면, 특별히 주의를 더 많이 기울여서 엉망으로 만들지 않으려 할 것임
- 명심하라 “깨진 창문은 없어야 한다”
관련 항목
- 항목 10. 직교성
- 항목 40. 리팩터링
- 항목 44. 이름 짓기
Topic 4. 돌멩이 수프와 삶은 개구리
- “시작 피로 Start-up fatigue”를 이겨내야 할 필요가 있다.
- 큰 무리 없이 요구할 수 있을 만한 것을 찾아라
- 그걸 잘 개발하라
- 일단 무언가 생기면 사람들에게 보여 주고 그들이 경탄하게 하라
- 그러고는 “물론 ……를 추가하기만 하면 더 나아질 수도 있겠죠” 라고 말하면서 그다지 중요하지 않은 척 가장하라
- 물러나 앉아 여러분이 애초에 원했던 그 기능을 추가해 달라고 사람들이 부탁하기 시작할 때까지 기다려라
- 계속되는 성공에 합류하기란 쉽다
- 미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다. (허락은 얻는 것보다 용서를 구하는 것이 더 쉽다)
Tip6 : 변화의 촉매가 되라.
마을 사람의 경우
- 프로젝트는 서서히, 하지만 가차없이 구제불능인 상태가 되어 버린다.
- 소프트웨어 참사는 대부분 너무 작아 알아채기 힘들 정도의 문제에서 시작됨
- 프로젝트는 대부분 어느날 갑자기 폭주한다.
- 시스템은 애초의 명세와는 조금씩 조금씩 기능이 달라짐
Tip 7 : 큰 그림을 기억하라
- 냄비안의 개구리처럼 서서히 온도가 바뀐다면 알아차리기 힘들것이다
- 개구리처럼 되자 말라. 큰 그림에 늘 주의를 기울여라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨일이 벌어지는지 늘 살펴보라.
관련 항목
- 항목 1. 당신의 인생이다
- 항목 38. 우연에 맡기는 프로그래밍
도전해 볼 것
- 변화를 촉진하려고 할 때 여러분이 좋은 영향을 끼칠 것인지 아닌지는 어떻게 알 수 있을까?
- 주변을 살피고 의식하는 습관을 들이고 여러분의 프로젝트에 적용하라
Topic 5. 적당히 괜찮은 소프트웨어
우리는 종종 뭔가 나아지게 하려다가 괜찮은 것마저 망친다.
- 셰익스페어, «리어왕» 1막 4장
- 실세계엥서는 진정 완벽한 것을 만들어 내기란 불가능 함
- 특히 버그 없는 소프트웨어는 더더욱. 시간, 기술, 기질 같은 것이 모두 힘을 합쳐 우리를 방해한다.
- 적당히 괜찮은 소프트웨어를 만들도록 자신을 단련할 수 있다.
- 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 됨
- “적당히 괜찮은” != 너절하거나 형편없는 코드
- 중요한 것은, 생산해 낸 것이 적당히 괜찮게 사용자의 요구를 충족하는지 결정하는 과정에 사용자가 참여할 기회를 가져야 한다는 것
타협 과정에 사용자를 참여시켜라
- 소프트웨어가 얼마나 종아야 하는지 사용자에게 물어본 적이 한 번이라도 있는가?
- 새로운 상품을 만들고 있다면 제약 조건이 좀 다를 것
- 여러분이 만드는 시스템의 범위와 품질은 해당 시스템의 요구 사항 중 하나로 논의되어야 함
Tip8 : 품질을 요구 사항으로 만들어라
- 놀랍게도 많은 사용자가 멋지고 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당잠 좀 불편한 소프트웨어를 사용하고 싶어 함
- 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다.
- 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것 (Lean Start-up, Agile?)
멈춰야 할 때를 알라
- 완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라
- 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다.
- 그래도 괜찮다. 완벽해지기란 불가능하다.
관련 항목
- 항목 45. 요구 사항의 구렁텅이
- 항목 46. 불가능한 퍼즐 풀기
도전해 볼 것
- 여러분이 일상적으로 사용하는 소프트웨어 도구나 운영체제를 보라. 이를 개발하는 조직이나 개발자들이 완벽하지 않다고 여겨지는 소프트 웨어를 거리낌 없이 출시한다는 증거를 찾을 수 있는가?
- 사용자로써 (1) 그들이 모든 버그를 제거할 때까지 기다리겠는가?
- (2) 복잡한 소프트웨어를 사용하면서 어느 정도의 버그는 감내하겠는가?
- (3) 결함이 더 적은 간단한 소프트웨어를 선택하겠는가?
- 모듈화가 소프트웨어 출시에 미치는 영향을 생각해보라
- 모놀리식 소프트웨어 블록을 필요한 품질 수준으로 만드느 것
- 마이크로서비스들로 설계된 시스템을 만드는 것 중 어느게 오래 걸릴까? 장단점은?
- 기능 블로트 (feature bloat) 현상에 빠진 유명한 소프트웨어를 떠올릴 수 있는가?
Topic 6. 지식 포트폴리오
지식에 대한 투자가 언제나 최고의 이윤을 낸다.
- 벤저민 프랭클린
- 여러분의 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다.
- 하지만 불행히도 이 자산은 기한이 있는 자산이다.
- 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다.
- 여러분의 지식 가치가 점점 떨어짐에 따라 회사나 클라이언트가 보는 여러분의 가치 역시 떨어짐
- 새로운 것을 배우는 능력은 여러분의 가장 중요한 전략 자산임
지식 포트폴리오
- 지식 포트폴리오 관리는 투자 포트폴리오 관리와 매우 유사하다.
- 진지한 투자자는 주기적으로 투자하는 습관이 있다.
- 장기적인 성공의 열쇠는 다각화다
- 똑똑한 투자자는 보수적인 투자와 위험이 크지만 보상이 높은 투자 사이에서 포트폴리오의 균형을 잘 맞춘다.
- 투자자는 최대 수익을 위해 사게 사서 비싸게 팔려고 한다.
- 포트폴리오는 주기적으로 재검토하고 재조정해야 한다.
- 성공적인 경혁을 위해서는 이와 동일한 지침을 사용해서 지식 포트폴리오에 투자해야 한다.
포트폴리오 만들기
주기적인 투자
- 여러분의 지식 포트폴리오에 소량으로라도 주기적으로 투자해야 함
- 습관 자체가 금액의 합계만큼이나 중요하다
다각화
- 더 여러 가지를 알수록 자신의 가치는 더욱 높아진다.
- 기본적으로 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 한다.
- 하지만 거기서 멈추지 말라. 컴퓨터 분야의 지형은 빠르게 변한다.
- 기술외의 분야도 포함하여 여러분에게 필요한 다른 역량도 잊지 말라
리스크 관리
- 기술은 위험하지만 잠재적으로 보상이 높은 것에서 리스크가 낮고 보상도 낮은 것에 이르기까지 다양한 스펙트럼 위에 존재함
- 여러분의 기술 달걀을 모두 한 바구니에 담지 말라
싸게 사서 비싸게 팔기
- 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가 된 주식을 찾아내는 것만큼이나 어려울 수 있지만, 이익 또한 그만큼 클 수 있다.
- 예시 : JAVA
검토 및 재조정
- 이 산업은 매우 동적이다.
- 한동안 사용하지 않던 데이터베이스 기술을 복습해야 할 필요
- 다른 언어를 시도해 본 덕에 새로운 일자리를 구할 때 더 유리할 수 있음
- 이 모든 지침 중에 제일 중요한 것은 가장 간단하게 실행할 수 있는 것이다.
Tip9 : 지식 포트폴리오에 주기적으로 투자하라
목표
매년 새로운 언어를 최소 하나는 배워라
- 다른 언어는 동일한 문제를 다르게 푼다.
- 몇 가지 서로 다른 접근법을 알면 사고를 확장하고 판에 박힌 사고에 갇히는 걸 예방하는 데에 도움이 된다.
기술 서적을 한 달에 한 권씩 읽어라
- 깊이 있는 지식을 원하다면 긴 글 형식의 책을 읽어야 한다
- 현재 프로젝트와 관련 있는 흥미로운 주제의 기술 서적을 서점에서 찾아보라
- 습관이 들면 한달에 한 권씩 일어라
- 현재 사용하는 기술을 일단 완전히 익혔다면, 가지를 쳐서 지금 하는 프로젝트와 관련 없는 분야까지 공부 범위를 넓혀라
기술 서적이 아닌 책도 읽어라
수업을 들어라
지역 사용자 단체나 모임에 참여하라
다른환경에서 실험해 보라
요즘 흐름을 놓치지 말라
- 투자를 지속하는 것이 중요하다. 한 기술의 새로운 용어나 기능에 익숙해지면 다음으로 넘어가 새로운 것을 배워라
- 이런 기술들을 프로젝트에서 영영 사용하지 않거나 심지어 자신의 이력서에 올려좋지 않아도 상관없다.
- 학습 과정에서 사고가 확장될 것이다. 이로 인해 새로운 가능성이 열리고 문제를 해결하는 새로운 방법이 떠오를 것이다.
- 사고 간의 교접(cross-pollination)이 중요하다.
- 새로이 배운 교훈을 현재 프로젝트에 적용하도록 노력하라.
학습의 기회
- 누군가 질문을 했을 때 그걸 모르는 경우
- 답을 찾기 위한 개인적인 도전으로 생각하자
- 주위에 물어보자
- 웹을 검색해보자
- 사용자용 문서뿐 아니라 학술 자료도 찾아보자
- 스스로 답을 찾지 못하면 답을 찾아줄 수 있는 사람을 찾자
- 다른 사람과 이야기함으로써 개인 네트워크를 구축하는 데 도움이 되기도한다
- 언제나 무엇을 읽을 수 있는 준비를 하자
비판적 사고
- 마지막으로 중요한 점은 여러분이 읽거나 듣는 것에 비판적으로 생각하는 것
Tip10 : 읽고 듣는 것을 비판적으로 분석하라.
- 비판적 사고는 그 자체만으로 하나의 학문을 이룬다.
왜냐고 다섯번 묻기 Five Whys
누구에게 이익이 되나?
어떤 맥락인가?
- 모든 일에는 각각의 맥락이 있기에, ‘만병통치약’인 해결책은 대게 통하지 않는다.
언제 혹은 어디서 효과가 있을까?
왜 이것이 문제인가?
관련 항목
- 항목 1. 당신의 인생이다
- 항목 22. 엔지니어링 일지
도전해 볼 것
- 이번 주부터 새오운 언어를 배우기 시작하라
- 새 책을 하나 읽기 시작하라
- 매우 상세한 구현과 코딩을 하고 있다면 설계와 아키텍처에 대한 책을 한 권 읽어라
- 고차원의 설계를 하고 있다면 코딩 테크닉을 다루는 책을 한 권 읽어라
- 밖으로 나가서 지금 수행하고 있는 프로젝트에 관여하지 않는 사람 혹은 같은 회사에 근무하지 않는 사람과 기술에 관한 대화를 하라
Topic 7. 소통하라!
나는 무시당하느니 차라리 샅샅이 훑어보는 시선이 낫다고 봐요
- 메이 웨스트
- 최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다.
- 효과적인 소통 없이는 아무리 훌륭한 아이디어라고 고립되고 만다.
Tip11. 한국어든 영어든 하나의 프로그래밍 언어일 뿐이다.
청중을 알라
- 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.
- 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다
- 다른 모든 형태의 의사소통과 마찬가지로 여기서도 비결은 피드백을 모으는 것
- 소통하면서 청중에 대한 지식을 쌓아 나가라
말하고 싶은게 무언지 알라
- 무엇을 말할지 미리 계획하라. 개요를 작성하라. 그리고 자문하라
- 이렇게 하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나? 그렇게 될 때까지 다듬어라
- 문서를 작성할 때만 그런게 아니다. 중요한 회의, 주요 클라이언트와의 대화 때도 제대로 전달하는데 필요한 전략을 몇 개 세워라
때를 골라라
- 청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야 한다.
- 소스 코드 일부가 사라진 일로 상사에게 막 꾸지람을 들은 관리자를 붙잡고 소스 코드 저장소에 대한 아이디어를 이야기해 주면 경청할 것이다.
스타일을 골라라
- 전달하는 스타일을 청중에 어울리도록 조정하라
- 어떤 스타일을 원하는지 청자에게 물어보라
- 하지만 누군가가 뭔가를 짤막하게 설명해 달라고 부탁하는데, 그 설명을 종이 대여섯 장 이하로 줄일 방법이 없다는 생각이 들면, 사실이 그렇다고 말하라.
멋져 보이게 하라
- 멋진게 아닌 것보다 훨씬 낫다
- 최신 기술을 활용하라
청중을 참여시켜라
- 청중을 통해 피드백을 받고 그들의 머릿속을 도용하라
경청하라
- 여러분이 다른 사람들의 말을 귀 기울여 듣지 않는다면 그들 역시 여러분의 말을 듣지 않을 것이다
- 질문을 해서 사람들이 이야기를 하도록 북돋우거나, 토론의 내용을 그들 자신의 표현으로 다시 말해 달라고 요청하라
응답하라
- 언제나 이메일과 음성 메시지에 답을하라.
- 심지어 단순히 “다음에 답해 드리겠습니다” 이더라도
- 늘 사람들에게 응답해 주면 때때로 저지르는 실수에 대해 훨씬 더 관대해질 것이고, 여러분이 그 사항을 아직 잊지 않았다고 느끼게 할 것이다.
Tip12 : 무엇을 말하는가와 어떻게 말하는가 모두 중요하다
문서화
- 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다
Tip13 : 문서를 애초부터 포함하고, 나중에 집어넣으려고 하지 말라.
- 소스코드의 주석으로 보기 좋은 문서를 쉽게 생성할 수 있다
- 모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다
요약
- 청중을 알라.
- 말하고 싶은게 무언지 알라.
- 때를 골라라.
- 스타일을 골라라.
- 멋져 보이게 하라.
- 청중을 참여시켜라.
- 경청하라.
- 응답하라.
- 코드와 문서를 함께 둬라.
관련 항목
- 항목 15. 추정
- 항목 18. 파워 에디팅
- 항목 45. 요구 사항의 구렁텅이
- 항목 49. 실용주의 팀
도전해 볼 것
- 맨먼스 미신과 피플웨어를 비롯하여 팀 내의 의사소통에 관한 내용이 실려 이씨는 훌륭한 책이 몇 권 읽다. 앞으로 18개월 이내에 이 책들을 반드시 읽을 수 있도록 노력하라
- 다음번 pt때 이 토픽의 내용을 적용해보라 그리고 피드백을 들어라
온라인 의사소통
- ‘보내기’ 버튼을 누르기 전에 검토를 하라
- 맞춤법에 맞는지, 자동 교정이 엉뚱하게 바꾸지는 않았는지 확인
- 형식을 간단하고 명확하게
- 답장할 때 원본 메시지의 인용은 최소한으로
- 다른 사람의 이메일을 인용한다면 누구의 것인지 밝히고 본문 속에서 인용
- 화내고 욕하거나 논란을 부추기는 글을 보내지 말라
- 보내기 전에 받는 사람 목록을 확인하라
Comments