📍 느낀점
프로그램 프로그래밍 프로그래머 시리즈 책을 읽을 때마다 언제나 항상 머리를 강하게 맞은 느낌을 받는다. 나는 여태 뭘 해왔는가 후회도 되고 왜 여태까지 이렇게 좋은 것을 알지 못했을까 아쉬움이 언제나 남는다. 실용주의 프로그래머 책을 처음 접했을 때, 실용적이라는 단어만을 보고 지금 당장 개발에 도움이 될 수있는 엄청하게 화려한(?) 테크닉 같은 것을 기대했다.어떤 프로그래밍 언어로 화려한 기술을 보여줄지 기대하고 있었던 내가 부끄러워 진다...
1장 실용주의 철학을 읽어보면 프로그래머로서 반드시 필수적으로 갖춰야할 기본 소양이다. 토픽들을 읽으면서 중요한 내용을 밑줄 치면서 읽다보니 책이 더러워질 만큼 모두 다 중요한 내용들 뿐이다. TIL에 적을 내용이 너무 많다... 줄이고 줄여도 줄여지지 않는다... 가슴속에 되새기면서 실용주의 프로그래머가 될 수 있도록 노력해야겠다.
[서문] 을 읽고
✅ 기억해야 할 문장
쉬운 정답은 없다. 도구든, 언어든, 운영체제든 최고의 해결 방안 같은 것은 없다. 오직 특정한 환경 조건들마다 가장 적절한 시스템들이 있을 뿐이다. 바로 이것이 실용주의가 필요한 이유다. 어떤 특정 기술에 매이면 안 된다. 개별 상황마다 그 상황에서 좋은 해결 방안을 고를 수 있도록 충분한 배경지식과 경험을 쌓아야 한다.
쉬운 정답은 없다. C++를 사용하면서 이 언어가 가장 최고라 생각했고 모든 문제에 대한 정답을 만들 수 있을거라 생각했다. 그렇게 특정 언어에만 매이다 보니 나는 우물안에 개구리가 되었고 정체되어 있는 사람이 되어있었다. 최고의 해결 방안 같은건 존재하지 않는다. 다양한 언어, 운영체제, 프레임워크, IDE를 사용해보면서 나의 배경지식을 넓히고 다양한 경험을 쌓으면서 상황에 따라 가장 좋은 해결 방안을 찾을 수 있는 프로그래머가 되어야 한다.
모든 개발 과정에서, 매일, 여러분이 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다. 절대 기계적으로 일하지 말라. 언제나 일하면서 동시에 생각하고, 자기 일을 비평하라. 오래된 IBM의 표어 '생각하라!'가 실용주의 프로그래머의 계명이다.
개발을 하다보면 생각은 하고 있지만 생각을 하지 않는 경험을 많이 해보게 된다. 프로그램을 만들기 위해 생각은 하고 있지만 전체적인 시각으로 생각을 하지 않는다. 단순하게 눈 앞에 일만 처리하다 보니 비판적으로 나 자신을 평가할 수 있는 기회가 없다고 생각한다. 언제나 넓은 관점으로 스스로를 평가할 수 있는 프로그래머가 되어야 한다.
[1장. 실용주의 철학] 을 읽고
✅ 기억해야 할 문장
사실 모든 문장을 다 가져오고 싶지만 그래도 중요한 것들만 추려본다...
Topic 1 당신의 인생이다.
우리가 이야기를 나누어 본 많은 개발자가 불만에 가득 차있었다. 불만의 종류는 다양하다. · · · 우리의 답은 한결 같다. "왜 직접 바꾸지 않습니까?"
당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다.
이전 회사를 퇴직하면서 나 또한 불만이 많은 개발자였다. 현재 업무에 갇혀 있었고 회사에서 사용하는 기술이 나의 요구에 맞지 않는다는 불평을 했었다. 하지만 한번도 저런 질문은 해본적이 없었다. "왜 직접 바꿀 생각은 해보지 않았나?" 나에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다. 더 이상 불평 불만보다는 행동으로 바꿔보려 노력해야 한다.
Topic 2 고양이가 내 소스 코드를 삼켰어요
실용주의 프로그래머는 자신의 경력에 대해 책임을 지고, 자신의 무지나 실수를 주저 없이 인정한다.
해결책을 찾아내야 하는 사람은 여러분이다.
변명 말고 대안을 제시하라.
어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해보라.
사람은 누구나 실수를 할 수 있다. 하지만 실수할까 두렵고 막상 일이 터지게되면 다른 사람에게 책임을 전가하거나 회피하고 싶어 한다. 책임을 회피하기 위해 어설픈 변명을 만들어내는 것은 일상이다. 내가 한 행동에 책임을 지자. 변명을 만들고 회피하면서 문제는 더 커질 뿐이다. 어차피 해결책을 찾아내야 할 사람은 나일뿐 바뀌지 않는다. 그 시간에 해결 방법을 찾는게 더 좋은 선택이다.
Topic 3 소프트웨어 엔트로피
깨진 창문을 내버려 두지 말라.
소프트웨어의 부패에 영향을 주는 다른 요인들도 나중에 더 알아보겠지만, 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다.
어떤 위기가 찾아왔다고 해서 부가적인 피해를 일으키지 말라. 깨진 창문은 하나로 충분하다.
명심하라. "깨진 창문은 없어야 한다."
엔트로피는 시스템 내의 '무질서'한 정도를 가리키는 물리학 용어다. 개발을 하다보면 무질서의 끝은 없다. 시간이 조금만 지나도 깨진 창문은 자연스럽게 발생하고 소프트웨어의 부패는 가속된다. 이 소프트웨어 엔트로피가 우리를 지배하도록 내버려 둘 수 없다. 깨진 창문은 없어야 한다!
Topic 4 돌멩이 수프와 삶은 개구리
미래를 살짝이라도 보여 주면 사람들은 도와주기 위해 모여들 것이다.
소프트웨어 참사는 대부분 너무 작아 알아채기 힘들 정도의 문제에서 시작되고, 프로젝트는 대부분 어느 날 갑자기 폭주한다. 시스템은 애초에 명세와는 조금씩 조금씩 기능이 달라진다. 그러다 보면 코드에 패치가 하나둘 적용되다가 원본이 하나도 남지 않을 지경이 된다. 종종 작은 것들이 쌓이고 쌓여서 사람들의 의욕, 그리고 팀을 파괴한다.
큰 그림에 늘 주의를 기울여라.
이 Topic 에서는 두 가지를 말한다. 변화의 촉매가 되어야 하는 것과 큰 그림을 기억해야 하는 것.
군인들이 돌멩이 스프를 만들어서 마을 사람들의 관심을 끌고 자연스럽게 마을사람들의 참여를 유도해서 돌멩이 스프가 아닌 근사한 진짜 스프를 만들어서 먹었다는 이야기는 가능성을 보여주면 다른 사람들의 참여를 자연스럽게 유도할 수 있다는 것을 말한다. 하지만 마을 사람들의 입장에서 본다면 그들은 돌멩이 스프에 속아서 다른 중요한 것들(자신들의 소중한 음식)을 잊어버렸다. 큰 그림을 보지 않으면 중요한 것을 잊게되고 소프트웨어 참사는 시작된다.
Topic 5 적당히 괜찮은 소프트웨어
적당히 괜찮은 소프트웨어를 만들도록 자신을 단련할 수 있다. 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 된다.
사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다.
완벽하게 훌륭한 프로그램을 과도하게 장식하거나 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그대로 놓아두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다.
완벽한 프로그램을 꿈군적이 있다. 하지만 완벽해진다는 것은 불가능하다. 수정사항은 언제나 발생하며 시간이 지남에 따라 새로운 기능이 필요하거나 기존의 기능을 변경해야 한다. 따라서 완벽에 목매는 습관보다는 프로그램 사용자를 참여시켜서 적당히 괜찮은 소프트웨어 타협점을 찾아야 한다. 피드백을 통해 소프트웨어는 계속해서 성장한다.
Topic 6 지식 포트폴리오
여러분의 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다. 하지만 불행히도 이 자산은 기한이 있는 자산이다.
본인이 프로그래머라면 성장하고 싶은 프로그래머라면 지식 포트폴리오를 만들어라! 오늘 저평가 받은 프로그래밍 언어가 앞으로 10년을 주도하는 언어가 될 수 있고 지금까지 프로그래밍 언어를 주름잡던 언어가 내일 당장 사라질 수도 있다. 배움을 멈추지 말고 새로운 배움에 계속해서 투자하라. 지식 포트폴리오는 투자 포트폴리오 관리와 유사하다. 주기적으로 투자하며 리스크 관리도 해야하고 적은 input 으로 큰 output을 만들 수 있어야 한다.
Topic 7 소통하라!
효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다.
전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다. 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다.
외부와 단절된 환경에서 작업하지 않는 이상 우리는 의사소통을 해야 한다. 그 소통이 더 효과적일수록 좀 더 많은 영향력을 갖게 될 것이다.
나에게 가장 부족하고 필요한 능력이라 생각된다. 다른 사람과의 소통은 개발자로서의 인생 뿐만아니라 전체적으로 반드시 필요한 능력이다. 상대방의 요구와 관심을 파악하고 내가 말하고자 하는 바를 명확하게 전달할 수 있는 능력을 키워야 한다.
