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

MEUN·2022년 3월 19일
0
post-thumbnail

1 주차

토 | Assignment #02

  • 📚 서문 ~ 1장. 실용주의 철학
  • ✔️ TIL

1장. 실용주의 철학


📘 책에서 기억하고 싶은 내용

  • 실용주의 프로그래머는 무엇이 다른가? 우리는 문제와 해법에 접근하는 태도와 방식, 철학에 차이가 있다고 생각한다. (p.1)
  • 당신의 인생이다 (p.2)
    • 당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있으니 주도적으로 행동하여 기회를 잡아라
  • 고양이가 내 소스 코드를 삼켰어요 (p.4)
    • 실용주의 철학의 초석 중 하나는 자신과 자신의 행동에 대해 책임을 지는 것이다.
    • 여러분의 팀이 여러분을 믿고 의지할 수 있어야 하고, 여러분도 다른 팀원 누구에게나 편하게 의지할 수 있어야 한다.
    • 실수는 할 수 있지만, 어설픈 변명 대신 대안을 제시해야 한다.
  • 소프트웨어 엔트로피 (p.8)
    • 소프트웨어가 부패하는 데에 많은 요소가 관여하지만, 가장 중요한 것은 프로젝트 내 발생하는 심리학적 또는 문화적 요소이다.
    • 명백히 망가진 상황을 무시하는 것은 아무도 고치지 않을 것 같다는 생각, 아무도 신경쓰지 않는다는 생각 등 부정적인 생각을 더 굳어지게 만든다. 그리고 이런 부정적인 생각이 팀원들 사이에 퍼져 악순환을 만들 수 있다.
    • 깨진 창문을 고치지 않은 채로 내버려두지 마라, 고칠 시간이 없다면 주석 등으로 해당 상황을 관리하고 있음을 보여줘라
    • 어떤 위기가 찾아왔다고 해서 그 위기를 해결하느라 다른 부가적인 피해를 일으키지 말아야 한다.
    • 깨진 창문이 꽤 있는 프로젝트에서 일할 때 '나머지 코드가 전부 쓰레기니까 나도 그렇게 하지 뭐.' 라는 사고에 빠지기 너무 쉽다.
  • 돌멩이 수프와 삶은 개구리 (p.11)
    • 소프트웨어 참사는 대부분 너무 작아 알아채기 힘들 정도의 문제에서 시작되고, 프로젝트는 대부분 어느 날 갑자기 폭주한다.
    • 큰 그림에 늘 주의를 기울여라.
    • 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보라.
  • 적당히 괜찮은 소프트웨어 (p.15)
    • 사용자나 미래의 유지 보수 담당 아니면 자기 자신이 마음의 평화를 유지하기에 적당할 정도로 괜찮으면 되는데, 이는 절대 너절하거나 형편없는 코드를 의미하지 않는다.
    • 프로그램에 새 기능을 추가하거나 코드를 한 번 더 다듬기 위해 사용자의 요구 사항을 무시해서는 안 된다.
    • 시스템의 범위와 품질은 해당 시스템의 요구 사항 중 하나로 논의되어야 한다.
  • 지식 포트폴리오 (p.19)
    • 새로운 것을 배우는 능력은 가장 중요한 전략 자산
    • 모든 독서와 연구는 시간이 걸리고, 시간은 늘 부족하다. 따라서 미리 계획해야 한다.
    • 포트폴리오 만들기
      • 다각화
        • 현재 작업에 사용하는 기술에 관해서는 속속들이 알아야 하는데, 이외의 분야도 포함하여 필요한 다른 역량도 잊지 말라
      • 싸게 사서 비싸게 팔기
        • 새롭게 떠오르는 기술이 인기를 끌기 전에 미리 알고 학습하는 게 저평가된 주식을 찾아내는 것만큼이나 어려울 수 있지만 이익 또한 그만큼 클 수 있다.
    • 목표
      • 매년 새로운 언어를 최소 하나 이상 학습
        • 다른 언어는 동일한 문제를 다르게 풀어 사고를 확장하는 데에 도움이 된다.
      • 기술 서적을 한 달에 한 권씩 독서
        • 깊이 있는 지식을 원한다면 긴 글 형식의 책을 읽어야 한다.
      • 기술서적이 아닌 책도 읽어라
      • 수업을 들어라
      • 지역 사용자 단체나 모임에 참여하라
      • 다른 환경에서 실험해 보라
      • 최신 트렌드를 놓치지 말라
  • 소통하라 (p.28)
    • 전달하려는 내용을 제대로 전달하고 있는 경우에만 소통하고 있다고 할 수 있다.
    • 무엇을 말할지 미리 계획하라.
    • 가능하다면 독자가 문서 초안에 참여하도록 하고, 피드백을 받고 그들의 머릿속을 도용하라.
    • 언제나 이메일과 음성 메시지에 답을 하라.
    • 문서화를 전체 개발 프로세스의 필요 불가결한 부분으로 생각하고 진행하는 게 좋다.
    • 모듈과 외부로 노출하는 함수에는 주석을 다는 것을 추천한다.
    • API가 아닌 코드에 주석을 쓸 때는 왜 이렇게 되어 있는지, 즉 코드의 용도와 목적을 논해야 한다.
      • 기술적인 절충점, 어떤 결정의 이유, 폐기한 다른 대안 등 기술 가능

🤔 소감 및 생각

  • 이번 챕터의 내용은 알지만 잊고 지낸 중요한 부분들에 대해 짚어준 것과도 같았다. 그리 새로운 내용은 아니지만 중요한 내용이었다.
  • 다른 전공 서적에 비해 읽는 데 걸리는 시간이 훨씬 적게 걸릴 줄 알았는데, 의미를 되새기면서 읽다보니 생각보다 오래 걸림을 깨달았다. 예상보다 더 쉽지 않은 챌린지가 될 것 같다고 생각하였다.

🔍 새롭게 또는 다시 알게 된 내용

  • 기능 블로트(feature bloat) : 제품에 너무 많은 피처 기능을 포함시킨 결과를 나타내는 용어로, 기능이 많은 만큼 버그나 보안 취약점이 생길 가능성도 높은 것을 말함

0개의 댓글