README Driven Development (2010)
(tom.preston-werner.com)- 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는 코드베이스에서 가장 중요한 문서가 되어야 하며, 제일 먼저 작성하는 것이 올바른 접근 방식임
소프트웨어든 소설이든 영화든 그 어떤 형태의 창작물을 만들 때에도
종이 앞에 두고 설계와 기획을 하면서 만들면 좀 더 디테일한 것들을 쉽게 챙길 수 있지 않을까 싶습니다.. :)
의도치않게 제가 업무하는 방식과 맥락이 비슷하네요.
그 부분이 "README" 형태로 산출되는 것 같네요.
저는 일을할 때 What, Why, How 등을 명확히 작성하고 진행하면서 진행해야할 일에 대한 쉐입을 잡아가는 편인데 그와 비슷하네요
저는 연구 조직이라서 연구된 내용을 코드형태로 릴리즈하는 것에 고민이 많았는데, Readme 주도 개발이 저희에게 잘 맞을 것 같다는 생각이 드네요. 연구 시작 단계에서 부터 고민해볼만한 방식같아요.