📚 해석 공유(3주차)

J002 강유진

Ch 7. 프로덕트 중심주의

<aside> 1️⃣ - 반복적으로 완성하기 -

빠르게 완성하고 싶은 욕심에 반복과 피드백 과정을 거치지 않고 많은 양의 코드를 작성하곤 합니다. 하지만 이러한 직관과는 달리 이터레이션 기반의 점진적이고 반복적인 개발이 최선의 길입니다.

- ”개발자 원칙”, p.194.

</aside>

<aside> 2️⃣ - 디테일까지 도달하기 -

그런데 많은 프로젝트 현장에서 이터레이션을 단순히 기능만 나열하고, 기능 구현을 완료하면 끝맺는 식으로 운영하기 때문에, 요구사항을 만족시키면 더 이상 발전하지 않고 멈추는 경우가 많습니다.

-”개발자 원칙”, p.195

</aside>

<aside> 3️⃣ - 망설일 바에는 실패하자 -

보잘것없거나, 심지어 본인이 보기에 완전한 실패라 해도 시도를 망설일 필요는 전혀 없습니다. 더 나은 프로덕트를 목표로 삼고 무언가를 계속 반복적으로 시도하면 점점 프로덕트를 잘 이해하게 됩니다. 프로젝트 실패 경험은 오히려 큰 성장을 이루게 하며, 앞으로 더 잘할 수 있는 역량을 보장하기 때문입니다.

-”개발자 원칙”, p.200

</aside>

  1. 지금까지 나의 목표는 무엇일까. 챌린지 과정이 아니라 딱 미션만 본다면, 빠르게 그리고 해결 그리고 학습 3가지가 목표였나 싶다. 여기서 “빠르게”가 들어가면서 내가 매번 놓쳤던 검증 단계가 많았을까 하는 생각이 들었다
    1. ex) 택배 시뮬레이터 미션에서… (동기/비동기)
  2. 지금까지 대부분 처음 설계를 할 때에는 디테일까지 가지만 후반으로 갈수록 오히려 디테일을 따지지 않았던 것 같다. 그래서 이번주 Day 13 미션에서 각 메소드를 모두 구현했다는 사실에 쉽게 자만했고, 뒤늦은 개선 사항을 피어세션에서 많이 알게 된게 아닐까 싶다. 많이 반성하고 있다.. ㅎㅎ
    1. ex) git 미션에서…
  3. 지금까지 끝나고 나서 설계를 엎었던건 1번의 경우가 아니라면 3번의 경우 같기도 하다. 처음에 설계에서 완벽하다고 느껴서 용기있게 진행한 구현을 나중 검증 단계에서 보자니 오류가 있던 것이었다. 그때 당시에는 검증이 부족했다고 아쉽다고 좌절만 했지만, 이로써 또 배웠다는 것을 생각할 필요도 있는 것 같다.
    1. ex) 함수형 프로그래밍 미션에서…

J091 문설민

기술적 실행 관례

XP, TDD, 페어 프로그래밍 등 기술적 실행 관례에 대한 설명. 짧고 빠른 피드백 루프를 통한 목적 달성에 집중. 기술적 실행 관례를 가져오거나 가져오지 않는 선택에 대한 책임감 필요. 허나 지금까지의 기술적 실행 관례를 절대적 진리로 바라보는 것은 지양. 실용주의적 관점으로 다른 실행 관례가 더 나은 가치를 주고 피드백 루프가 더 짧다면 도입.

길고 긴 여정

어디로 가고 있는지 모르고 있다면 결국 가고 싶지 않은 곳으로 간다. 커리어에 있어서 방향성을 결정하는 것은 중요. 어디로 가야할 지 모른다면 여러 문을 두드려보자. 지식인을 움직이는 것은 자율성, 통달, 목적의식. 많은 부분을 고려해서 커리어를 신중히 결정.