Hacker News 의견

• 프로토타이핑은 디자인 과정에서 중요한 부분이며, 문제를 정의하고 해결책을 명확히 하는 것이 필요함

  • 때로는 간단한 문서로도 충분하지만, 때로는 많은 피드백과 반복이 필요함
  • "몇 주의 코딩이 몇 시간의 계획을 절약할 수 있음"이라는 말이 있음

• 글쓰기는 문제를 탐색하는 데 유익하며, 문제를 이해했다고 생각했지만 글을 쓰면서 새로운 질문이 생긴 경험이 있음

  • 멘토가 Lucidchart를 사용하여 6개월간의 작업을 설명한 사례를 떠올림

• 프로젝트를 기한 내에 완료하기 위해 임시 해결책을 사용한 경험이 있음

  • 임시 해결책이 생산 지원 도구로도 사용되며, 영구적인 버전이 중단될 경우 대체 경로로 활용됨

• 디자인 문서의 가장 큰 문제는 아무도 읽지 않는다는 것임

  • 프로토타이핑의 문제는 사람들이 이를 최종 코드로 간주하는 것임
  • 하이브리드 접근법을 선호하며, 계획과 문서화를 철저히 하고 최종 제품에 사용할 수 있는 품질의 프로토타입 코드를 작성함

• 코드와 디자인에 대한 피드백의 차이가 큼

  • 디자인 문서는 문제 공간에 대한 "왜"라는 질문을 유도함
  • 프로토타입이 작동하면 이러한 질문을 제기하기 어려워짐

• 많은 코드를 작성하여 무엇이 효과적인지 보는 것이 직무 설명이라면, GPT가 더 빠르고 저렴하게 대체할 수 있음

  • 무엇을 구축해야 하는지에 대한 합의를 얻는 것이 항상 도전임

• 소프트웨어 개발이 깔끔하고 질서 정연한 흐름을 따른다고 상상하는 사람들은 거의 없음

  • 코드 작성은 글쓰기와 비슷하며, 초안은 항상 형편없고 좋은 글은 많이 수정됨

• 코드가 Jenga처럼 쌓여 아무도 손대고 싶지 않게 되는 경우를 본 적이 있음

• 지속적인 댓글 스레드를 사용하여 디자인 결정을 문서화하는 프로세스를 선호함

  • GitHub 이슈를 사용하여 이 과정을 진행함

• 이 접근법에 대해 고민 중이며, 최악의 경우 많은 시간을 낭비할 수 있음

  • 문제를 충분히 생각하여 올바른 구현에 필요한 속성을 명시할 수 있을 때 디자인 문서 작성이 가장 유익했음
  • 부분적인 해결책을 구현하여 점진적으로 개선하는 것도 성공적이었음