# 설계 문서보다 Throwaway Code 선호 현상

> Clean Markdown view of GeekNews topic #18294. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=18294](https://news.hada.io/topic?id=18294)
- GeekNews Markdown: [https://news.hada.io/topic/18294.md](https://news.hada.io/topic/18294.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-12-16T15:33:57+09:00
- Updated: 2024-12-16T15:33:57+09:00
- Original source: [softwaredoug.com](https://softwaredoug.com/blog/2024/12/14/throwaway-prs-not-design-docs)
- Points: 3
- Comments: 1

## Topic Body

- 우리는 소프트웨어 개발이 깔끔하고 질서 있는 흐름을 따르기를 상상함
  - 설계 문서를 작성하고, 작은 변경 사항을 PR로 롤아웃하여 기능을 구현함
  - 깃 히스토리가 깔끔하고 질서 정연하게 보임
  - 그러나 현실은 다름

- 설계 문서와 실제 구현의 차이
  - 설계 문서를 그대로 구현하는 것은 환상임
  - 코딩을 시작하면 설계 문서의 내용을 수정하게 됨
  - 계획은 적과의 접촉에서 살아남지 못함

- 새로운 설계 방법론: 코딩 몰입
  - 초안 PR을 사용하여 프로토타입을 구현함
  - 초기에 피드백을 받아 접근 방식을 조정함
  - 초안 PR을 역사적 설계 아이디어로 문서화함
  - 초안 PR을 완전히 버릴 준비를 함
  - 초안 PR에서 점진적으로 PR을 단계적으로 진행함
  - 각 PR을 단계적으로 테스트하고 견고성을 보완함

- 성숙함의 중요성
  - 코딩한 아이디어를 버릴 수 있는 능력이 중요함
  - 코드 라인이 아닌 조직적 지식의 전달이 중요함
  - 중요한 부분에 대해 초기에 정렬하여 프로토타입 작업이 낭비되지 않도록 함

- PR을 문서화로 사용하는 방법
  - PR은 개발자에게 가장 좋은 문서화 형태 중 하나임
  - PR은 특정 시점의 상태를 반영하는 역사적 유물임
  - 설계 문서는 종종 현실과 다른 정보를 제공함

- 프로토타입의 중요성
  - 프로토타입은 1000개의 설계 문서보다 가치가 있음
  - 변화를 주도하려면 문서가 아닌 코드로 해야 함
  - 조직이 프로토타입을 해답이 아닌 질문으로 보아야 함

- 설계 문서의 유용성
  - 다양한 이해관계자와의 피드백을 조직하고 아카이브하는 데 유용함
  - 아이디어가 너무 개념적이거나 장기적일 때 유용함
  - 코딩보다 글로 아이디어를 표현하는 것이 더 효율적일 때 유용함
  - 조직이 첫 번째 솔루션을 버릴 수 있는 규율이 없을 때 유용함
  - 주니어 직원이 시니어 개발자의 아이디어에 대해 안전하게 질문할 수 있는 환경을 제공함

- 설계 문서의 잘못된 사용
  - 덜 숙련된 개발자에게 프로세스를 늦추기 위해 사용됨
  - 문서화로 사용되지만 빠르게 구식이 됨
  - 모든 설계 문제를 해결하려고 하지만 실제 문제는 코딩을 통해 발견됨

- 팀이 규율을 가질 수 있다면 해킹이 설계보다 훨씬 효율적임
  - 조직 내에서 이러한 규율을 만들 것을 권장함
  - 결국 코드는 말보다 더 큰 힘을 가짐

## Comments



### Comment 32428

- Author: neo
- Created: 2024-12-16T15:33:58+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=42417478) 
- 프로토타이핑은 디자인 과정에서 중요한 부분이며, 문제를 정의하고 해결책을 명확히 하는 것이 필요함
  - 때로는 간단한 문서로도 충분하지만, 때로는 많은 피드백과 반복이 필요함
  - "몇 주의 코딩이 몇 시간의 계획을 절약할 수 있음"이라는 말이 있음

- 글쓰기는 문제를 탐색하는 데 유익하며, 문제를 이해했다고 생각했지만 글을 쓰면서 새로운 질문이 생긴 경험이 있음
  - 멘토가 Lucidchart를 사용하여 6개월간의 작업을 설명한 사례를 떠올림

- 프로젝트를 기한 내에 완료하기 위해 임시 해결책을 사용한 경험이 있음
  - 임시 해결책이 생산 지원 도구로도 사용되며, 영구적인 버전이 중단될 경우 대체 경로로 활용됨

- 디자인 문서의 가장 큰 문제는 아무도 읽지 않는다는 것임
  - 프로토타이핑의 문제는 사람들이 이를 최종 코드로 간주하는 것임
  - 하이브리드 접근법을 선호하며, 계획과 문서화를 철저히 하고 최종 제품에 사용할 수 있는 품질의 프로토타입 코드를 작성함

- 코드와 디자인에 대한 피드백의 차이가 큼
  - 디자인 문서는 문제 공간에 대한 "왜"라는 질문을 유도함
  - 프로토타입이 작동하면 이러한 질문을 제기하기 어려워짐

- 많은 코드를 작성하여 무엇이 효과적인지 보는 것이 직무 설명이라면, GPT가 더 빠르고 저렴하게 대체할 수 있음
  - 무엇을 구축해야 하는지에 대한 합의를 얻는 것이 항상 도전임

- 소프트웨어 개발이 깔끔하고 질서 정연한 흐름을 따른다고 상상하는 사람들은 거의 없음
  - 코드 작성은 글쓰기와 비슷하며, 초안은 항상 형편없고 좋은 글은 많이 수정됨

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

- 지속적인 댓글 스레드를 사용하여 디자인 결정을 문서화하는 프로세스를 선호함
  - GitHub 이슈를 사용하여 이 과정을 진행함

- 이 접근법에 대해 고민 중이며, 최악의 경우 많은 시간을 낭비할 수 있음
  - 문제를 충분히 생각하여 올바른 구현에 필요한 속성을 명시할 수 있을 때 디자인 문서 작성이 가장 유익했음
  - 부분적인 해결책을 구현하여 점진적으로 개선하는 것도 성공적이었음