오늘 TIL 3줄 요약

• 실용주의 프로그래머가 되기 위해, 항상 자기가 무엇을 하고 있는지 생각해야 하며, 모든 결정을 비판적으로 평가해야 한다.

• 항상 책임을 다하기 위해 노력해야 하며, 변명이 아닌 대안을 제시해야 한다.

• 좋은 지식 포트폴리오를 구축하기 위해 노력하자. 그러기 위해 책을 읽는 것도 중요하지만, 소통하는 것도 매우 중요하다.

TIL (Today I Learned) 날짜

2022.03.19

오늘 읽은 범위

서문 ~ 1장. 실용주의 철학

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

• 어떤 특정 기술에 매이면 안 된다. 개별 상황마다 그 상황에서 좋은 해결 방안을 고를 수 있도록 충분한 배경지식과 경험을 쌓아야 한다. 배경지식은 컴퓨터 과학의 기본 원리에 대한 이해에서 생겨나고, 경험은 다양한 종류의 실제 프로젝트들을 수행해 봄으로써 얻을 수 있다. 이론과 실천의 결합이 여러분을 강하게 만든다. - xviii (서문)

• 실용주의 프로그래머가 되고 싶다면 어떤 일을 하면서 자기가 무엇을 하고 있는지 생각해야만 한다. 현재의 실천 방법을 검토해 보는 일회성 행사를 말하는 것이 아니다. 모든 개발 과정에서, 매일, 여러분이 내리는 모든 결정을 끊임없이 비판적으로 평가해야 한다. - xxi (서문)

• 실용주의 프로그래머는 직면 한 문제 너머를 고민한다. 문제를 더 큰 맥락에 놓고 더 큰 그림을 보려고 노력한다. - 1p (1장. 실용주의 철학)

• 실용주의 프로그래머는 자신의 경력에 대해 책임을 지고, 자신의 무지나 실수를 주저 없이 인정한다. - 4p (1장. 실용주의 철학)

• 변명 말고 대안을 제시하라. 안된다고 하지 말고 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라. - 6p (1장. 실용주의 철학)

• ‘깨진 창문’을 고치지 않은 채로 내버려 두지 말라. 나쁜 설계, 잘못된 결정, 혹은 형편없는 코드 등이 모두 깨진 창문이다. 발견하자마자 바로 고쳐라. 적절히 고칠 시간이 없다면 일단 판자로 덮는 것만이라도 하라. ...(중략)... 방치는 다른 어떤 요인보다도 부패를 더 가속시킨다. - 9p (1장. 실용주의 철학)

• 큰 그림에 늘 주의를 기울여라. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라. - 14p (1장. 실용주의 철학)

• 오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 완벽한 소프트웨어보다 낫다. 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 종국에는 더 나은 해결책에 도달할 수 있을 것이다. - 17p (1장. 실용주의 철학)

• 여러분의 지식과 경험이야말로 가장 중요하고 날마다 쓰이는 전문가 자산이다. 하지만 불행히도 이 자산은 ‘기한이 있는 자산이다. 새로운 기술, 언어, 환경이 개발됨에 따라 지식은 옛것이 된다. ...(중략)... 새로운 것을 배우는 능력은 여러분의 가장 중요한 전략 자산이다. - 20p (1장. 실용주의 철학)

• 투자를 지속하는 것이 중요하다. 한 기술의 새로운 용어나 기능에 익숙해지면 다음으로 나아가라. 또 다른 것을 배워라. -24p (1장 .실용주의 철학)

• 다른 사람과 이야기함으로써 개인 네트워크를 구축하는 데 도움이 되기도 하고, 답을 찾는 도중에 별로 관련이 없어 보이는 문제에 대한 해답을 찾아서 놀라는 일도 생길 것이다. 게다가 포트폴리오는 그사이 계속 커진다. - 25p (1장. 실용주의 철학)

• 여러분이 뭘 가졌느냐 만이 아니라 그걸 어떻게 포장하느냐도 중요하다. 최고의 아이디어, 최상의 코드 혹은 아주 실용적인 발상이 있다고 해도 다른 사람들과 소통할 수 없다면 궁극적으로 아무 효용이 없다. 효과적인 소통 없이는 아무리 훌륭한 아이디어라도 고립되고 만다. - 28p (1장. 실용주의 철학)

• 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다. 그렇게 하기 위해서는 청중의 요구와 관심, 능력을 이해할 필요가 있다. - 29p (1장. 실용주의 철학)

• 모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다. API를 사용하려는 다른 개발자에게 도움이 될 것이다. ...(중략)... API가 아닌 코드에 주석을 쓸 때는 왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다. 어떻게 동작하는지는 코드가 이미 보여 주기 때문에 이에 대해 주석을 다는 것은 사족이다. 게다가 이것은 DRY 원칙 위반이다. - 34p (1장. 실용주의 철학)

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

• 오늘 읽은 내용은 비단, 실용주의 '프로그래머'에게만 해당되는 말이 아니라고 생각한다. 어떤 분야에서든 통용될 수 있는 원칙이라고 생각하며, 실용적으로 일하는 사람이 되기 위해 항상 명심해야 한다고 생각한다.

• 앞서 읽었던 '클린코드'와 마찬가지로, 이 책에서도 책임과 코드를 깨끗하게 유지하는 것의 중요성을 언급했다. 항상 책임을 다하기 위해, 코드를 깨끗하게 유지하기 위해 여분의 시간을 투자하는 습관을 가지자.

• 더 많은 지식을 얻기 위해, 자신이 가진 지식을 계속해서 업데이트하기 위해 할 수 있는 방법들을 투자 포트폴리오를 구성하는 노하우에 비유해 표현한 방식이 인상적이었다. 돈을 굴리지 않고 가만히 두면 시간이 지날수록 가치를 잃어가듯, 지식도 점차 가치를 잃는다. 계속해서 높은 가치의 지식 포트폴리오를 지니기 위해 노력하자.

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

• DRY원칙 : 'Don't Repeat Yourself"의 첫 글자를 따서 만든 단어로, 동일한 코드의 중복을 피하라는 것. 동일한 코드의 중복은 오류가 일어날 확률을 높이기 때문. (참고: https://blog.naver.com/PostView.nhn?blogId=complusblog&logNo=221163007357&redirect=Dlog&widgetTypeCall=true&directAccess=false)

• 메시지 브로커(Message Broker) : Publisher로부터 전달받은 메시지를 subscriber에게 전달하는 역할을 수행함으로써, 응용프로그램 간에 메시지가 교환될 수 있도록 함. (참고: https://heodolf.tistory.com/49)

오늘 읽은 다른사람의 TIL

• hyune--4KXjeq님의 TIL https://nomadcoders.co/community/thread/3575