고양이가 소스 코드를 삼켰어요!!
실용주의 프로그래머는 책임감이 있기때문에 프로젝트가 방치된 채로 끝장나는 것을 가만히 옆에 앉아서 지켜보고만 있지 않는다.
Topic 1 당신의 인생이다.
삶을 살면서 누구나 불만은 매우 다양하다. 소프트웨어 개발은 구직자에게 주도권이 있는 직업중 상위권에 자리잡을 것이다.
우리 기술은 수요가 많고, 지식은 지리적인 경계를 뛰어넘으며 원격으로 일할 수 있다. 보수도 후한편이다. 우리가 원하는 것은 거의 무엇이든 할 수 있다.
"왜 직접 바꾸지 않는것일까?"
기술에 뒤쳐지는 기분이 든다면 여가 시간을 쪼개서 재미있어 보이는것을 공부하라. 여러분 자신에게 투자하는 것이니 업무 외 시간에 하는것이 옳다.
Topic 2 고양이가 내 소스코드를 삼켰어요
약점을 보이는 것에 대한 두려움이 가장 큰 약점이다.
실용주의 철학의 초석중 하나는 '자신과 자신의 행동에 대해 책임을 지는 것이다.' 실용주의 프로그래머는 자신의 경력에 대해 책임을 지고, 자신의 무지나 실수를 주저없이 인정한다. 책임을 지는 일이 분명 프로그래밍에서 가장 즐거운 부분은 아니다.
무엇보다 팀이 우리를 믿고 의지할 수 있어야 한다. 그리고 우리도 팀을 믿고 편하게 의지해야한다. 창의성과 공동작업에는 팀내의 신뢰가 절대적으로 필요하다고 한다.
대용량 저장 장치가 망가지면서 그 안에 저장된 소스 코드가 날아가 버렸는데 백업이 없다면, 그것은 여러분의 잘못이다. "고양이가 내 소스코드를 삼켰어요." 라고 상사에게 말해봐야 별 도움이 안될것이다.
변명말고 대안을 제시해야한다. 안된다고 하지말고 상황을 개선하기위해 무엇을 할 수 있는지 설명해야한다. 어설픈 변명을 늘어놓기전에 그 변명거리를 없애도록 노력해보자. 그래도 꼭해야한다면... 고양이에게 해보자..
만약 자동차 수리공이나, 가게점원, 은행원이 우리앞에 어설픈 변명을 늘어놓는다면 어떻게 반응할까? 차라리 "잘모르겠어요" 라고 말한다면 , 바로 이어서 "하지만 알아볼게요" 라고 말하는것과 모르는 것은 인정하더라도 전문가답게 책임을 지는 방법이다.
Topic 3 소프트웨어 엔트로피
엔트로피는 시스템 '무질서'한 정도를 가리키는 물리학 용어이다. 소프트웨어도 무질서가 증가할때 이를 '소프트웨어 부패'라고 말한다.
막 완공된 건물은 깨끗하고 온전하다. 하지만 거주하던 사람이 떠나고 오랫동안 방치된다면 폐허로 변한다. 언제부터 이렇게 폐허가 되어가는 것일까 ?
'깨진 창문'을 고치지 않은 채로 내버려 두지 말아야한다. 아무것도 고치지않은 것은 아무것도 신경 쓰지 않는다는것, 망조가 들었다는 생각을 더 굳어지게 만든다.
소프트웨어도 마찬가지다. 발견하자마자 바로 고쳐야한다. 적절히 고칠 시간이없다면 임시방편이라도 취해야 한다고 말한다.
창문이 처음 깨졌을때 목소리를 낼 수있겠는가 ? 여러분의 반응은 무엇인가 ? 만약 그것이 누군가 다른사람의 결정 혹은 경영진의 명령에 따른 결과였다면 여러분은 무엇을 할 수 있을까?
Topic 4 돌멩이 수프와 삶은 개구리
시스템이 눈앞에 빤히 그려지고, 그 시스템이 옳다는 걸 안다. 하지만 일에 착수하려고 허락을 구하는 때부터 뭔가 지연되거나 사람들이 멍한 눈으로 바라본다. 위원회가 생기고, 예산승인이 필요하고 일들이 복잡해지기 시작한다. 모든 사람들이 각자 자신의 자원을 지키려고 할것이다. 이것이 '시작 피로' 라고 부른다.
'돌멩이'를 내놔야 한다. 큰 무리없이 요구할 수 있을만한것을 찾아라. 계속되는 성공에 합류하기란 쉽다. 미래를 살짝이라도 보여주면 사람들은 도와주기위해 모여들것이다.
'돌멩이'같은 변화의 촉매가 되어야한다.
당장 하고있는 일에만 정신을 쏟지말고, 주변에 무슨일이 벌어지는지 늘 살펴보아야 한다. '큰그림을 기억하라'
Topic 5 적당히 괜찮은 소프트웨어
버그없는 소프트웨어를 만들긴 매우 힘들다. 하지만 '적당히 괜찮은 소프트웨어'를 만들도록 자신을 단련할 수 있다. '적당히 괜찮은' 이라는 표현은 너절하거나 형편없는 코드를 의미하지않는다. 시스템이 성공하려면 사용자의 요구사항을 충족해야한다. 기본 성능이나 개인 정보보호, 보안 기준도 맞추어야한다. 사용자의 요구를 적당히 괜찮게 충족하는지의 결정하는 과정에 사용자가 참여할 기회를 가져야 한다는 것이다.
'프로그래밍'은 그림과 같다 전체 모양을 스케치하고 밑색을 칠한다음 세부내용을 채워넣는다. 거듭 뒤로 물러서서 비판적으로 자신이 만든 것을 살펴보기도한다. 때로는 캔버스를 버리고 완전히 새로 시작하기도 한다.
하지만 예술가들은 멈춰야 할 때를 놓치면 이 모든 고된작업을 망쳐버린다는것을 안다. 칠한 위에 덧칠하고 세부묘사위에 다시 세부묘사.. 곧 그림은 물감속으로 사라진다.
이처럼 훌륭한 프로그램을 과도하게 장식하거나 지나칠정도로 다듬느라 망치지 말아야한다.
우리는 종종 뭔가 나아지게 하려다 괜찮은 것 마저 망친다.
Topic 6 지식포트폴리오
새로운 것을 배우는 능력은 가장 중요한 전략 자산이다. 그런데 배우는 방법 자체는 어떻게 배워야할까? 무엇을 또 배워야 할지 어떻게 알 수 있을까 ?
프로그래머들이 컴퓨터, 애플리케이션 도메인에 알고있는 모든 사실과 경험을 '지식 포트폴리오'로 생각해 보길 좋아한다. 지식 포트폴리오 관리는 '투자 포트폴리오'관리와 매우 유사하다.
- 주기적인 투자
- 다각화
- 리스크관리
- 싸게사서 비싸게 팔기
- 검토 및 재조정
지식 포트폴리오에 무엇을 추가할지 알게되었다면, 앞으로 자산이될 종잣돈은 즉 지식자산은 어떻게 공급해줘야할까 ?
- 매년 새로운 언어 최소 하나를 배워라
- 기술서적을 한달에 한권씩 읽어라
- 기술서적이 아닌 책도 읽어라
- 수업을 들어라
- 지역 사용자 단체나 모임에 참여해라
- 다른 환경에서 실험해보라
- 요즘의 흐름을 놓치지 말라
마지막으로 중요한점은 앞으로 읽거나 듣는것에 대해 비판적으로 생각해야 하는것이다. 포트폴리오에 있는 지식을 정확히 유지할 수 있도록 하고 과대광고에 흔들리지 않도록 조심해야한다. 광범위한 포트폴리오를 갖추고, 넘쳐나는 기술을 다룬 글을 읽을때 비판적 분석을 적용함으로써 복잡한 해답을 이해할 수 있을 것이다.
Topic 7 소통하라!
우리가 뭘 가졌느냐만이 아니라 그걸 어떻게 포장하느냐도 중요하다. 최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다.
우리가 의사소통해야하는 언어는 또 다른 프로그래밍 언어일 뿐이라 여겨라. 사람을 위한 글 쓰는것도 코드를 쓰는것과 똑같다.
청중을 알아야한다.
그리고 피드백을 모아야한다. 그저 질문을 기다리지말고 먼저 물어봐야한다. 청중의 손짓 발짓 몸짓 표정들을 관찰해야한다. 의사소통의 의미는 우리가 청중에게 받는 반응이 결정한다.
말하고싶은게 무엇인지 정확히 알아야한다.
의사소통에서 가장 어려운 부분은 아마 우리가 말하고자 하는것이 정확히 무엇인지 생각해 내는 일일 것이다. 무엇을 말할지 미리 계획하고, 개요를 작성해라. 그리고 자문해라. '이렇게 하면 내가 표현하고 싶은 것을 듣는 사람에게 통하는 방법으로 잘 전달할 수 있나?' 그렇게 될때까지 다듬어라.
때를 골라야한다.
청중이 무엇을 듣기 원하는지 이해하려면 그들의 우선순위를 알아야한다. 그리고 시점도 중요한데 "~에 대해 이야기할 좋은 때일까?" 라는 간단한 질문을 해보는것만으로 충분하다.
스타일을 골라라.
전달하는 스타일을 청중에 어울리도록 조정해야한다. 어떤 사람은 격식있는 '사실' 만 전달 받는 브리핑을 원한다.
의사소통의 나머지 반은 바로 우리 몫이다. 누군가가 뭔가를 짤막하게 설명해 달라고 부탁하는데, 그 설명을 종이 대여섯장 이하로 줄일 방법이없다면 사실이 그렇다고 이야기해야한다. 이것 또한 의사소통의 한가지 형태이다.
멋져보이게 해야한다.
보기좋은 떡이 맛있어 보이는법이다. 청중들에게 멋지게 전달하기 위한 수단을 준비해야한다. 페이지 머릿말 꼬릿말, 그리고 페키지에 포함된 샘플 문서를 참고해서 스타일과 레이아웃에 대한 아이디어를 얻어라. 그리고 맞춤법을 확인해야한다.
청중을 참여하고, 경청해라
문서를 만드는 와중 독자가 문서 초안에 참여하도록 해라. 피드백을 받고 그들의 머릿속을 도용해라. 독자와 더 좋은관계를 형성하게 될것이고 그 과정에 더 나은 문서를 만들 수 있다.
또, 다른사람들이 우리의 말을 경청해 주길 바란다면 먼저 우리가 그들의 말을 경청 하는 것이다. 질문해서 사람들이 이야기를 복돋우거나 토론 내용을 그들자신의 표현으로 다시 말해달라고 요청해보자.
응답하라.
질문을 했는데 아무런 응답이없다면 무례하다고 느낄것이다. 하지만 하루하루 바쁜 삶속에서 잊어버리고 살기 쉬운법이다. 언제나 이메일과 음성메시지에 답을 해라. 심지어 응답이 단순히 "다음에 답해드리겠습니다." 이더라도 늘 사람들에게 응답해 주면 때때로 저지르는 실수에 대해 훨씬 더 관대해 질것이다. 그리고 그 사항을 아직 잊지않았다고 느끼게 할 것이다.
문서화
의사소통 문제다. 개발자는 문서화를 그리 대단하게 생각하지 않는다. 하지만 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다. 그리고 노력 중복으로 들이거나 시간을 낭비하지 않고 문서를 늘 손에 닿는 가까운 곳에 두면 된다. 바로 '코드안'에서 이다.
'API'가 아닌 코드에 주석을 쓸때는 왜 이렇게 되어있는지, 즉 코드의 용도와 목적을 논해야한다.
어떻게 동작하는지는 코드가 이미 보여주기때문에 이에 주석을 다는것은 사족이다. 게다가 이것은 DRY원칙 위반이다.
소스코드에 다는 주석은 프로젝트에서 쉽게 누락되는 다른곳에서 문서화 할 수 없는 부분을 문서화하기에 최적의 기회다.
총평
코드는 이렇게 짜야한다 는 것을 넘어, '실용주의 개발자'의 삶은 이런것이다. 라고 말해주는것 같다.
느낀점은 첫째, 주도적으로 바꿔나아가야 한다. 둘째, 남탓을 하거나 변명을 하지말것. 셋째, 꾸준한 유지보수와
리팩토링의 중요성. 넷째, 항상 큰 그림을 기억해야할것, 다섯쨰, 적당히 좋은 소프트웨어를 만들것
여섯째, 배움과 공부, 발전을 결코 게을리 하지말것, 마지막으로, 사용자와 소통해보는것이다.
마치 이번 화를 읽고나서 예전 책 '배우수업'을 읽었던 때가 기억이난다. 연기 수업보단 배우가 되기위한
'배우는 이렇다' 라는것을 대해 자세히 다룬 책이었다. 마치 이번화는 '프로그래머 수업'이지 않았을까?
앞으로 매우 기대된다.
