-
[실용주의 프로그래머] 1장. 실용주의 철학Development/개발 관련 도서 2018. 5. 28. 14:09
실용주의 프로그래머(The Pragmatic Programmer)
1. 실용주의 철학(A Pragmatic Philosophy)
이 장에서는 문제에 어떻게 접근해야 하는지에 대한 철학을 알려준다.
1. 고양이가 내 소스코드를 삼켰어요
내가 한 일에 대해선 책임을 져라. 프로그램이 안 돌아가면 변명하지 말고 대안을 찾아야 한다.
본인의 실력에 대해 자부심을 가질 필요가 있다. 그런만큼 실수를 인정할 필요도 있다.
Tip 3. 어설픈 변명을 할 바엔 대안을 제시해라.
코드를 버려야하나? 리팩토링 가능 여부를 분석
뭘 구현해야하지? 프로토타입 구현으로 먼저 구조를 살펴봄
테스팅, 자동화도 도입해야할 요소
SE시간에 배웠던 것들을 다시금 강조한다.
그리고 나도 충분히 못할 수 있다. 그러면 부탁하고 묻고 하는 것에 두려움이 없어야 한다. 질문 없이 혼자 끙끙 앓으면 나만 아프다.
2. 소프트웨어 엔트로피
프로그램을 짜면 필연적으로 누더기 코드가 생긴다.
'깨진창문 이론'을 생각하자! 잘 안되거나 건성으로 짠 코드는 다른 코드도 대충짜게 만든다.
Tip 4. 깨진창문을 내버려두지 마라!
오작동 하거나 안돌아가는 코드는 주석처리를 하든, 더미 데이터를 넣어놔서 돌아가게 하든 임시조치라도 취해놓야한다.
시간이 촉박하거나 데모를 줄 필요가 있을 땐 급하게 돌아가게는 만들어야한다. 하지만 반드시 수정해야한다. 멍청한 코드는 프로젝트를 망가뜨리는 지름길이기 때문이다.
3. 돌멩이 수프와 삶은 개구리
https://en.wikipedia.org/wiki/Stone_Soup 일화를 말한다.
킥스타팅은 별게 아니라 걍 쉬운걸 구현하는데서 시작한다는 말이다.
나도 1인 프로젝트를 해보면서도 실컷 틀을 다 짜놓고는 퍼졌던 적이 있다. '그래 이정도는 했지 ㅋㅋㅋ' 하고 자만하고 끝이었는데, 사실은 그때부터 시작이었던 것이다. 사실은 나부터 '변화의 촉매가 되'어야 한다.
Tip 5. 변화의 촉매가 되어라!
그렇지만, 기능을 잡아넣기만 하면 프로젝트가 뒤틀린다. 세세한거에 집중하다보니 원했던 구현이 되지 않는다. 책의 내용을 그대로 인용하자면 다음과 같다.
(중략) 프로젝트 폭주는 대부분 어느날 갑자기 일어난다. 코드에 패치가 하나 둘 적용되다가 원본이 하나도 남지 않을 때 까지, 시스템은 명세에서부터 기능 하나하나씩 정처 없이 떠다닌다. (후략)
그러니까 항상 '큰 그림을 기억해야' 한다. 프로젝트가 어떻게 만들어질지 생각했으면 그거대로 만들어야한다 이말이다.
Tip 6. 큰 그림을 기억하라!
개구리는 서서히 끓는 냄비속에서 '어 따뜻해지네?' 하다가 죽는다.
그렇다면 여기서 정말 중요한 질문이 있다. stone soup story에서의 변화와 개구리를 점진적으로 속이는 변화의 차이는 뭘까? 내가 일으킨 변화는 팀에있어 스톤수프 변화일까, 개구리수프 변화일까? 이 판단은 주관적일까, 객관적일까?
4. 적당히 괜찮은 소프트웨어
'적당히 괜찮은' 이란 말은 구린 코드를 말하는게 아니다. 이건 책을 그대로 인용해서 이해하는 것이 좋겠다.
(중략) 시스템이 성공하려면 사용자의 요구사항을 충족해야 한다. 단지 우리는 여러분이 생산해낸 것이 어느 정도면 적당히 괜찮은지를 결정하는 과정에 사용자가 참가할 기회를 가져야 한다는 걸 말하고 있는 것이다.
피드백을 얻을 필요가 있다 이말. '얼마나 좋아야'되는가? 에 대한 질문은 유저가 대답해줄 것이다. 회사의 입장으로 생각하자면 얼마만큼 개발해야하는지 감이 나오나? 요구사항에 얼마까지 개발해야 '적당해'지나? 하는걸 감 잡아야 한단 말.
Tip 7. 품질을 요구사항으로 만들어라.
프로그래밍은 애초부터 완벽하게 만들어낼 수가 없다. 불-완벽한(완벽에 최대한 수렴하는) 프로그램을 짤 생각을 해야한다.
만약 나라면...
버그가 단 하나도 없는 프로그램을 기다릴거냐? (진심?)
복잡한 SW를 쓰면서 어느정도까지 버그는 감내할 수 있냐?
아니면, 결함이 더 적은 간단한 SW를 쓸거냐?
5. 지식 포트폴리오
내가 가지고 있는 지식은 결국 '소진하는 자산(expiring assets)' 이다. 내 지식은 옛날의 것이 되고, 그 변하는 속도는 말 그대로 '미쳤'다. 웹은 더 미친듯이 바뀐다. 오늘 다르고 내일 다르다.
그래서 책은 내가 알고있는 사실, 경험을 '지식 포트폴리오'로 생각하기를 권장한다. 실제 투자하고 밀접한 연관이 있는데 이는 다음과 같다.
진지한 투자자들은 주기적으로 투자하는 습관을 가지고 있다.
장투로 성공하기 위한 답은 다각화다.
똑똑한 투자자들은 자신의 포트폴리오를 보수적인 투자, 위험성이 큰 투자, 보상이 높은 투자 사이에서 균형을 잘 맞춘다.
최대 수익을 위해 싸게 사서 비싸게 판다.
포트폴리오는 주기적으로 재검토, 재조정해야 한다.
이걸 프로그래머 영역으로 바꾸면 아래와 같이 볼 수 있을 것이다.
주기적인 투자: 꾸준히 신기술을 배워야함.
다각화: 어느 분야의 특정 기술이 언제 생기고 언제 사라지는지 파악해야함. 많은 기술에 익숙하면 변화에 잘 적응할 수 있을 것이다.
리스크 관리: 어느 기술이 어떻게 흥하고 망할지는 아무도 모른다. 한 기술에 몰빵하지 마라.
싸게 사서 비싸게 팔기: 신기술이 생기면 적극적으로 들이대보라. 분명 리스크가 있는데, 장안의 화제가 된 언어같으면 내가 그 언어를 '잘 안다' 할 수 있다. 그건 분명 좋은 점이다.
검토 및 재조정: 작년까지 잘쓰던 기술이 올해는 안쓰이는 기술이 될 수도 있다. 한동안 안쓰던 기술을 이제와서보니 다시 쓰더라 하기 쉽다. 그래서 많이 다뤄봐야 한다는 말.
Tip 8. 지식 포트폴리오에 주기적으로 투자하라.
본 책에서는 다음과 같은 방법을 제안한다.
매년 새 언어를 하나씩 배워라.
기술 서적을 분기마다 하나씩 읽어라.
비기술 서적을 읽어라. 심리학, 문화인류학, 건축학, 경영학 이런 것들 조차도..
수업을 들어라. 각종 세미나, 컨퍼런스에 가보라는 말 같다.
지역 사용자 모임에 참여하라. 고립되면 안된다. 개발자 모임에 가서 새로운 피를 계속 수혈받아야 한다.
다른 환경에서 실험해보라. 윈도우도 써보고 맥도 써보고 유닉스도 써보고 하여튼 다 써봐야함. ./configure, makefile, make도 해봐야되고 IDE도 써봐야되고 하여튼 다 써봐야한다.
트렌드를 계속 파악하고 있어야한다. 주요 뉴스피드를 읽고 이메일 구독도 계속 봐야한다. 맨날 안읽고 쓰레기통에 넣어 비우지 말고..
인터넷을 이용하라. 구글께서는 답을 알고계신다.
올바르게 질문하는 방법은 이 링크와 같다. 똑똑하신 구루는 kldp에도 있다. OKKY에도 계신다. 내가 원하는 기술 커뮤니티의 영역 어디든 다 계신다. 그런 똑똑한 분들에게 '올바른 방법으로' 많이 물어서 답을 내꺼로 하자!
비판적인 사고는 중요하다. '내 말이 옳다!' 하는 사람은 멀리해야한다. 어떤 문제에 대해 무조건 풀 수 있는 마스터 키 같은건 없다. 주어진 문제를 풀 수 있는 방법은 다양하기 때문이다. 하지만 때로는 아름다운 단 하나의 답만이 존재할 수도 있다.
kldp의 어느 사람의 말을 기억하자.
프로그래밍 언어는 목적이 아니라 수단일 뿐입니다.
Buzz와 Fanboyism에 휘둘리기 보다는
하고 있는 일이 잘되게 하는 Getting Things Done에 집중하시길 추천드립니다.
Tip 9. 읽고 듣는 것을 비판적으로 분석하라.
'Development > 개발 관련 도서' 카테고리의 다른 글
[실용주의 프로그래머] 서론 (0) 2018.05.28