피어세션에서..
어제 개선 이후에도 다른 분들의 개선 사항을 보면서 한 번 더 개선할 사항들이 보였던 것 같다. 역시 엊그제는 자만하면 안됐다 ㅎㅎ
개발자 원칙을 읽으면서..
아래의 느낀점을 느꼈다. 특히 첫번째와 세번째를 느끼면서 기존에는 실패 경험을 여러가지로 분류하기 보다 그냥 “실패했다” 라고만 봤는데, 책을 읽으면서 좀 복잡한 생각이 들었다.
나는 그저 지금까지 “검증”을 충분히 하지 않아서 실패한건지, 혹은 검증 과정을 거쳤음에도 실패한건지 헷갈렸다. 첫번째라면 검증 과정을 추가하면서 충분한 검증이란 무엇일지, 내 설계가 주어진 요구사항을 지키는지 검증하는 방법은 무엇일지, 좋은 설계란 무엇을지 등을 고민해보아야 할 것 같다. 두번째라면 검증을 충분히 했다는 생각이 들었으나 내가 끝에 와서 발견하게 된 것이고 “과정에서 학습한게 있었을테니까 시도한 것은 잘 한것이다.” 라고 생각해야할지.. 머리가 복잡하다.
생각 정리를 거치다보니 종합적으로 설계가 실패할 것 같아도 시도하고, 이걸 검증해가면서 나아지는것 같다..! 그럼 결론은 난 시도는 했지만 검증이 아쉬웠던게 맞는 것 같다.. ㅎㅎ 나아가기 위해 악셀은 시도하기고 검증이 브레이크였구나.. 다음주는 더 잘해봐야겠다.
<aside> 1️⃣ - 반복적으로 완성하기 -
빠르게 완성하고 싶은 욕심에 반복과 피드백 과정을 거치지 않고 많은 양의 코드를 작성하곤 합니다. 하지만 이러한 직관과는 달리 이터레이션 기반의 점진적이고 반복적인 개발이 최선의 길입니다.
- ”개발자 원칙”, p.194.
</aside>
<aside> 2️⃣ - 디테일까지 도달하기 -
그런데 많은 프로젝트 현장에서 이터레이션을 단순히 기능만 나열하고, 기능 구현을 완료하면 끝맺는 식으로 운영하기 때문에, 요구사항을 만족시키면 더 이상 발전하지 않고 멈추는 경우가 많습니다.
-”개발자 원칙”, p.195
</aside>
<aside> 3️⃣ - 망설일 바에는 실패하자 -
보잘것없거나, 심지어 본인이 보기에 완전한 실패라 해도 시도를 망설일 필요는 전혀 없습니다. 더 나은 프로덕트를 목표로 삼고 무언가를 계속 반복적으로 시도하면 점점 프로덕트를 잘 이해하게 됩니다. 프로젝트 실패 경험은 오히려 큰 성장을 이루게 하며, 앞으로 더 잘할 수 있는 역량을 보장하기 때문입니다.
-”개발자 원칙”, p.200
</aside>