README（自述文件）驅動軟體開發

Python部落(python.freelycode.com)組織翻譯，禁止轉載，歡迎轉發。

這些天我聽到了很多關於 TDD、BDD、極致編程、敏捷式軟體開發、站立會議，以及各種各樣的為開發出更好的軟體而提出的方法和技術。但是我想說的是，除非你正在設計的軟體能夠符合使用要求，要不然這些都沒什麼用。換句話說，就算你的規範做的再好，沒有用對地方就沒有任何價值。同理，一個沒有一本藏書的漂亮圖書館是沒有任何價值的。如果你的軟體解決了一個實際問題，但是沒人知道怎麼去用它，這樣就沒什麼意義，問題依舊存在。

那我們如何解決這個問題呢？比你想像的要簡單許多。

首先編寫自述文件。

當然，我知道我們是程序員不是技術作家，但是為了編寫一個好的軟體，在你寫任何代碼、測試、計劃、故事或者是任何其他的事情前，一份自述文件都是非常必要的。否則很有可能當你開始著手寫軟體的時候，你都不知道自己該如何寫代碼。在人們對瀑布式軟體設計的強烈反對和對敏捷式軟體開發的極力支持之間，我們一定缺失了什麼東西。不要誤解我的意思，瀑布式設計需要的東西太多了，以細微的細節來構造一個龐大的系統，最終會導致這些細微的細節構造出一個錯誤的系統。所以停止對瀑布式設計的使用是很明智的。但是換個思路想想，我們要拿什麼來代替它？現在，我們有很多工程項目，它們只包含一個簡單的或者一個隨便寫的文檔，甚至可能都沒有文檔。有些工程項目甚至都沒有自述文件。

這是並不能被接受，在有大量的技術規範和沒有技術規範之間應該有個折中點。實際上，這個折中點是存在的，他就是自述文檔。

區分自述文件驅動軟體開發（RDD）和文檔驅動軟體開發（DDD）是很重要的。RDD 可以認為是 DDD 的一個子集或者一個微縮版。將設計文檔簡化為一個單個可讀文件，然後作為軟體的說明。RDD 通過限制文件內容的長度或者過於詳細的說明文檔來避免瀑布式開發的 DDD 弊端。同時 RDD 也鼓勵是去實現庫的小型化和模塊化。這些簡單的增強功能可以驅使你的項目朝著正確的方向前進，從而避免過多的、沒必要的步驟。

先寫自述文件，會給你帶來一些好處：

• 最重要的一點是，它為你提供了一次全局審視項目的機會，從而避免了每次你改變了想法就去修改你的代碼的麻煩。而這些想法可能是關於某些東西的應該如何組織，或者什麼東西應該包含在公共 API 中。請記住那種感覺，那種你第一次編寫自動化測試程序並且捕獲到那些一不留神就可能溜進你代碼中的錯誤的那種感覺。這種感覺就和你在實際編寫代碼前，先寫自述文件的感覺一樣。

• 編寫自述文件還有另外一個好處，可以讓你更好的了解你想實現什麼。你將擁有一份非常好的文檔。同時你會發現，當你的興奮度和動機達到最高的時候，在項目開始前先寫一份文檔就會變的容易的多。當你的項目結束後你再去寫自述文件將會變得很困難，並且你肯定會遺漏很多重要的細節。

• 如果你在一個團隊中工作，你將會從你的自述文件中學習到更多的東西。如果在你完成這個項目之前，團隊中的其他人可以看到這份文檔，他們將會非常放心的使用你的代碼介面來開展其他的項目工作。如果沒有任何合適的預定義介面，你就不得不自己去寫代碼或者重寫大部分的代碼。

• 使用你寫下的自述文件來參與討論將會使事情變的簡單。如果沒有白紙黑字，人們很容易陷入對某個問題無休無止的討論中。一個簡答的辦法就是把提議的解決方案寫下來，這樣大家進行反覆討論的時候就有一個具體的概念了。

把為你的項目寫自述文件的過程看做一個真實的創作過程，在這裡你可以表達你所有的想法。這份文件應該立足於你的觀點，從而證明你的創造力和表達力。在你的代碼庫中，自述文件應該是一份最重要的文件，你應該首先寫你的自述文件。

英文原文：http://tom.preston-werner.com/2010/08/23/readme-driven-development.html
譯者：無

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！