# README Driven Development (2010)

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

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=15502](https://news.hada.io/topic?id=15502)
- GeekNews Markdown: [https://news.hada.io/topic/15502.md](https://news.hada.io/topic/15502.md)
- Type: news
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-06-25T09:31:02+09:00
- Updated: 2024-06-25T09:31:02+09:00
- Original source: [tom.preston-werner.com](https://tom.preston-werner.com/2010/08/23/readme-driven-development.html)
- Points: 44
- Comments: 9

## Summary

README 주도 개발은 소프트웨어 개발의 초기 단계에서 README 파일 부터 작성하여 프로젝트의 구조와 목표를 명확히 하는 방법론입니다. 이 접근 방식은 프로젝트를 체계적으로 계획하고, 팀 작업의 효율성을 높이며, 초기부터 우수한 문서를 확보하는 데 도움을 줍니다. README를 먼저 작성함으로써 개발자는 명확한 방향성을 가지고 코딩을 시작할 수 있으며, 이는 잘못된 문제 해결을 방지하고 사용자 요구를 충족시키는 소프트웨어를 만드는 데 필수적입니다. 2010년도 글이지만 지금 읽어도 배울게 있는 글이네요.

## Topic Body

- README 주도 개발 : 소프트웨어 개발시 README를 먼저 작성하는 접근 방식  
- TDD, BDD, Extreme Programming, SCRUM 등의 다양한 개발 방법론과 기술에 대해 많이 듣게 됨  
  - 하지만, 우리가 개발하는 소프트웨어가 사용자의 필요를 충족시키지 못하면 모든 것이 무의미함  
  - 완벽한 구현이라도 잘못된 명세를 따르면 무가치하며, 문서화되지 않은 아름다운 라이브러리도 거의 무가치함  
  - 소프트웨어가 잘못된 문제를 해결하거나 사용법을 알 수 없으면 심각한 문제 발생  
  
### 해결책: README 부터 작성하기  
- **Readme를 먼저 작성해야 하는 이유**  
  - 코드, 테스트, 스토리 등을 작성하기 전에 먼저 Readme부터 작성  
  - Readme 작성은 좋은 소프트웨어를 만들기 위한 필수 단계  
  - 소프트웨어에 대해 글로 작성하기 전까지는 무엇을 코딩할지 명확하지 않음  
  - Readme를 통해 프로젝트를 체계적으로 생각할 수 있음  
- **README 우선 작성의 이점**:  
  - **프로젝트를 체계적으로 생각할 기회**:  
    - 코드를 변경할 필요 없이 프로젝트를 체계적으로 생각할 수 있음  
    - 코딩 전 프로젝트의 구조와 포함될 API를 고민할 수 있음  
  - **우수한 문서 확보**:  
      - 프로젝트 초기에 높은 동기부여와 흥미를 가진 상태에서 문서를 작성할 수 있음  
      - 나중에 Readme를 작성하는 것은 지루하고 중요한 세부 사항을 놓칠 수 있음  
  - **팀 작업의 효율성 증가**:  
      - 팀의 다른 개발자들이 프로젝트 완성 전에 인터페이스에 대한 정보를 공유받아 다른 작업을 자신있게 시작할 수 있음  
      - 명확한 인터페이스 없이 작업하면 대규모 코드 재작업이 필요할 수 있음  
  - **구체적인 토론 기반 제공**:  
      - 텍스트로 제안된 해결책을 작성하는 간단한 행위로 모두가 명확한 아이디어를 가지고 논의할 수 있음  
- **README 주도 개발(RDD)의 특징**:  
  - RDD는 Documentation Driven Development(DDD)의 하위 집합이나 제한된 버전으로 볼 수 있음  
  - RDD는 단일 파일로 설계 문서를 제한하여 과도한 사양 작성의 문제를 방지함  
  - 작은 모듈화된 라이브러리를 유지하도록 유도함  
  
### 결론  
- Readme를 작성하는 과정을 진정한 "창작 행위"로 생각할 것  
- 이 문서에 당신의 모든 기발한 아이디어가 표현되어야 하며, 문서 그 자체로 창의성과 표현력을 증명하는 증거가 되어야함  
- Readme는 코드베이스에서 가장 중요한 문서가 되어야 하며, 제일 먼저 작성하는 것이 올바른 접근 방식임

## Comments



### Comment 26633

- Author: princox
- Created: 2024-06-26T16:50:16+09:00
- Points: 1

소프트웨어든 소설이든 영화든 그 어떤 형태의 창작물을 만들 때에도  
종이 앞에 두고 설계와 기획을 하면서 만들면 좀 더 디테일한 것들을 쉽게 챙길 수 있지 않을까 싶습니다.. :)

### Comment 26622

- Author: markman
- Created: 2024-06-26T12:06:17+09:00
- Points: 1

가장 기본적인 것을 그동안 잊고 살았는데 이제 실천해봐야 겠습니다.

### Comment 26597

- Author: halfenif
- Created: 2024-06-25T18:30:01+09:00
- Points: 2

우리는 그것을 "기본설계"라고 부르기로 했어요.

### Comment 26592

- Author: gargoyle92
- Created: 2024-06-25T14:11:50+09:00
- Points: 1

의도치않게 제가 업무하는 방식과 맥락이 비슷하네요.  
그 부분이 "README" 형태로 산출되는 것 같네요.  
  
저는 일을할 때 What, Why, How 등을 명확히 작성하고 진행하면서 진행해야할 일에 대한 쉐입을 잡아가는 편인데 그와 비슷하네요

### Comment 26586

- Author: kandk
- Created: 2024-06-25T12:09:40+09:00
- Points: 1

README 주도 개발

### Comment 26575

- Author: dbs0829
- Created: 2024-06-25T10:01:19+09:00
- Points: 1

저는 연구 조직이라서 연구된 내용을 코드형태로 릴리즈하는 것에 고민이 많았는데, Readme 주도 개발이 저희에게 잘 맞을 것 같다는 생각이 드네요. 연구 시작 단계에서 부터 고민해볼만한 방식같아요.

### Comment 26571

- Author: jamsya
- Created: 2024-06-25T09:54:37+09:00
- Points: 1

이와 비슷하게 백엔드할 때 화면보면서 API 문서부터 러프하게 써보곤 하는데,  
시행착오를 줄이는데 꽤 도움이 됐습니다.

### Comment 26566

- Author: bbulbum
- Created: 2024-06-25T09:45:04+09:00
- Points: 2

어찌보면 해결해야하는 문제를 먼저 정확하게 정의하는 것의 중요성처럼 느껴지는군요.

### Comment 26564

- Author: xguru
- Created: 2024-06-25T09:32:02+09:00
- Points: 1

2010년도 글인데 다른 글을 보다 발견해서 함 올려봅니다.