[TIL 1] 실용주의 프로그래머 #1. 실용주의 철학

오늘 TIL 3줄 요약

• 안 되면 안 되는 이유를 설명하자.
• 잘못된 부분을 발견했다면, 미루지말고 빠른 시일에 고치자.
• 반복하지말자. 그게 잘못된 코드든.. 행동이든..

TIL (Today I Learned)

2022.03.19

오늘 읽은 범위

1장 실용주의 철학

책에서 기억하고 싶은 내용을 써보세요.

당신은 당신의 조직을 바꾸거나, 당신의 조직을 바꿀 수 있다.

• 기술에 뒤쳐지는 기분이 든다면 여가 시간을 쪼개서 재미있어 보이는 것을 공부하라. 여러분 자신에게 투자하는 것이니 업무 외 시간에 하는 것이 옳다.

=> 회사가 오래된 레거시 기술을 사용한다고 느껴진다면, 스스로 시간을 내서 새로운 기술이나 언어를 학습하고, 응용하여 토이 프로젝트를 진행해보자. 프로젝트를 진행하면서 학습한 내용을 토대로 그에 맞게 현 회사의 프로젝트에 적용해보거나, 그게 안 된다면 그럴 수 있는 조직으로 이직하자.

어설픈 변명 말고 대안을 제시하라.

• 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.
• 코드를 지워야 하나? 지워야 한다고 말하고 리팩토링의 가치를 설명해줘라.
• 어설픈 변명을 늘어놓기 전에 그 변명거리를 없애도록 노력해 보라.

=> 기획자나 다른 부서의 사람들의 기능추가 또는 수정 요청이 들어왔을 때, 무작정 안 된다고 말만하지말고 깊이 생각해보자. 깊이 생각해보았으나 처리할 수 없는 문제라면 "잘 모르겠다" 라는 어설픈 변명 대신, "한번 확인해볼게요"라는 해당 문제를 책임지는 전문가의 모습을 보이도록 노력하자.

깨진 창문을 내버려 두지 말라.

• 나쁜 설계, 잘못된 결정 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자 마자 바로 고쳐라.
• 깨진 창문 하나, 조악한 설계의 코드, 형편없는 경영상의 결정 등 프로젝트 기간 동안 팀이 동고동락해야 하는 문제는 내리막기로 가는 첫 걸음이다.
• 깨진 창문이 꽤 있는 프로젝트에서 일할 때는 "나머지 코드가 전부 쓰레기까 나도 그렇게 하지 뭐." 라는 사고에 빠지기 너무 쉽다.
• 명심하라. 깨진 창문은 없어야 한다.

=> 애초에 처음부터 설계가 잘못되거나, 처음에는 근사했던 코드가 프로젝트를 진행하면서 새로운 기능을 추가하다보면 어느새 스파게티 코드가 되어있는 모습을 종종 발견하곤 한다. 기존의 근사한 코드를 시간이 없다는 핑계로 코드를 엉망으로 만드는 첫 주자가 되지 말자.

멈춰야 할 때를 알라.

• 완벽하게 훌륭한 프로그램을 과도하게 장식하거나, 지나칠 정도로 다듬느라 망치지 말라. 그냥 넘어가고 코드를 현재 상태로 한동안 그동안 놓아두라. 완벽하지 않을 수도 있다. 그래도 괜찮다. 완벽해지기란 불가능하다.

=> 과유불급! 충분히 괜찮은 코드를 자신만의 철학에 빠져 필요 이상으로 수정하지 말자. 안 하느니만 못하다.

지식 포트폴리오

• 성공적인 경력을 위해서는 지식 포트폴리오에 투자해야 한다.
• 일단 스스로 한 번 해본 다음, 습관을 들이는 것이다. 따라 할 절차를 만든 다음 여러분의 뇌에 각인될 때까지 반복하라. 그러고 나면 새로운 지식을 무의식적으로 빨아들이는 자신을 발견할 수 있을 것이다.

=> 자신의 가치는 자신이 만드는 것이다. 많지 않아도 된다. 처음부터 욕심부리면 금방 지치기 마련이다. 매일 조금씩이라도 지식 포트폴리오에 투자하자. 꾸준히 반복하다보면 이는 곧 습관이 되고 하루에 1씩 저장한다고 해도 1년이면 365의 지식이 저장된다. 물론 틈틈히 복습도 잊지 말자!

읽고 듣는 것을 비판적으로 분석하라.

• 비판적 사고는 그 자체만으로 하나의 학문을 이룬다.
• 왜냐고 다섯 번 묻기
• 누구에게 이익이 되나?
• 어떤 맥락인가?
• 언제 혹은 어디서 효과가 있을까?
• 왜 이것이 문제인가?

=> 오늘 날 우리가 얻을 수 있는 지식의 양은 방대하다. 인터넷에 검색하면 손 쉽게 많은 양의 정보를 얻을 수 있다. 개중에는 내가 찾는 문제의 답과 일치하는 정보도 있겠지만, 잘못된 정보도 많을 것이다. 이를 비판적으로 분석함으로써 잘못된 지식은 거르는 능력을 키우자.

청중을 알라.

• 회의에서 괴짜 개발자가 어떤 난해한 기술의 장점에 대해 긴 독백을 읊조리는 동안, 앉아 있는 마케팅 부사장의 눈이 점점 흐리멍덩해지는 걸 본 적이 있다. 이것은 소통이 아니다. 단지 지껄임일 뿐. 짜증 나는 일이다.

=> 기능에 대해 개발자가 아닌 다른 부서의 사람들에게 설명하다보면 자신도 모르게 개발 언어를 사용하게 된다. 앞으로 비 개발자와 대화를 할 때는 혼자만 아는 내용(단어나 기술)에 대해 신나게 설명하지 않고, 알아 들을 수 있게 설명하도록 노력해야 겠다.

문서화

• 일반적으로 개발자는 문서화를 그리 대단하게 생각하지 않는다. 고작해야 불가피하게 해야 할 일 정도로 여기거나, 최악의 경우에는 프로젝트가 끝날 무렵이면 관리자가 까맣게 잊어버릴지도 모른다는 희망을 품고 우선순위가 낮은 작업으로 취급한다.
• 실용주의 프로그래머는 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 받아들인다.

=> 프로젝트에서 기능을 만들 때, 먼저 프로세스에 대한 문서를 만들어보자. 시간이 없다면 주석이라도 괜찮다. 단, 이미 코드에서 충분히 설명하는 굳이 내용을 주석으로 설명하지 말자. DRY(Don`t Refact Yourself)원칙 위반이다.

오늘 읽은 소감은? 떠오르는 생각을 가볍게 적어보세요

• 개발자로서 프로젝트를 진행하며 엉망으로 작성한 코드를 나중에 수정해야지라며 지나친다거나, 반대로 이미 충분히 괜찮게 고쳐놓은 코드를 개인적인 욕심에 더 다듬기도 하고, 비 개발자와 대화할 때는 "잘 모르겠다." 또는 아는 부분에 대해서는 상대방을 고려하지 않은 개발적인 언어로 대화를 해왔다. 그동안 얼마나 안일한 마음으로 일해왔는지에 대해 생각해보면서, 바로는 힘들겠지만, 조금씩 고쳐나가야 겠다는 생각이 들었다.

궁금한 내용이 있거나, 잘 이해되지 않는 내용이 있다면 적어보세요.

• "소프트웨어가 부패하는 데에는 많은 요소가 관여한다. 가장 중요한 것은 프로젝트에서 발생하는 심리학적 혹은 문화적 요소다." 여기서 말하는 심리학적, 문화적 요소는 어떠한 것이 있을까? 문화적 요소는 팀 문화를 말하는걸까? 생각해 볼 필요가 있을 것 같다.