原文鏈接

名詞解釋

RDD ： Readme Driven Development
TDD ： Test Driven Development
BDD ： Behavior-Driven Development
XP ： Extreme Programming
SCRUM : 迭代式增量軟體開發程序

翻譯

最近我聽到很多關于TDD、BDD、XP、SCRUM、站會以及開發更好軟體的各種方法和技術的討論，但這些都是無關緊要的，除非我們所構建的軟體能夠滿足用戶的需求，

讓我換一種說法，

有關錯誤相關的規范的完美實作是毫無價值的，基于同樣的原則，一個精心制作的沒有檔案的庫也幾乎毫無價值，如果你的軟體解決了錯誤的問題，或者沒有人知道如何使用它，那一定是非常糟糕的事情，

那么，我們如何解決這個問題呢？

它比你想象的要簡單，而且它足夠重要，可以用一段話來說明，

Write your Readme first.

首先，README應在你寫任何代碼、測驗、行為、故事或任何其他東西之前，我知道，我知道，該死的，我們是程式員，不是技術作家！但這就是你錯的地方，撰寫README對于撰寫好的軟體是絕對必要的，除非你已經撰寫完軟體，否則你甚至不知道要撰寫什么代碼，

在對瀑布設計的強烈抵制和對敏捷開發的高度接受之間，有些東西遺失了，不要誤解我的意思，瀑布式設計太過分了，它以小細節指導龐大的系統最侄訓成為在小細節中指匯出錯誤的系統，我們推翻它是對的，但取代它的另一個方向又太遠了，

現在我們有一些專案的檔案很短，寫得很糟糕，或者完全沒有檔案，有些專案甚至沒有README！這是不可接受的！在大量的技術規范和根本沒有規范之間必須有一個中間地帶，事實上，這個中間地帶就是謙遜的README，

區分RDD和DDD是很重要的，RDD可以被認為是DDD的子集或有限版本，將你的設計檔案限制在一個單獨的檔案中，作為你的軟體的介紹來閱讀，RDD通過懲罰冗長或過于精確的規范來避免DDD變成瀑布綜合癥，與此同時，它還鼓勵你保持庫的小和模塊化，這些簡單的增強功能對推動專案朝著正確的方向發展大有幫助，而無需大量的程序來確保你在做正確的事情，

通過先寫README，你會給自己帶來一些非常明顯的優勢：

最重要的一點，你為自己提供了一個全面思考專案的機會，而不必在每次更改關于應該如何組織某些內容或應該在Public API中包含哪些內容的想法時更改代碼，還記得當你第一次開始撰寫自動代碼測驗并意識到你捕獲了所有可能潛入代碼庫的錯誤時那種感覺嗎？如果你在撰寫實際代碼之前為專案撰寫了README，你會有同樣的感覺，
作為撰寫README的副產物，為了知道你需要實作什么，你會有一份非常好的檔案擺面前，你還會發現，在專案開始時，當你的興奮和動力達到最高時，撰寫這份檔案要容易得多，追溯撰寫README絕對是一種累贅，而且你肯定會錯過各種重要的細節，
如果你和一個開發團隊一起作業，你會從你的README中得到更多的好處，如果團隊中的每個人都能在你完成專案之前訪問這些資訊，那么他們就可以自信地開始處理與你的代碼互動的其他專案，如果沒有任何型別的定義介面，你就必須串行編碼或重新實作大量代碼，
基于寫下來的東西進行討論要簡單得多，如果一個問題從來沒有付諸文本，人們很容易沒完沒了地兜圈子進行討論，寫下一個提議的解決方案的簡單行為意味著每個人都有一個具體的想法，可以進行討論和迭代，

把為專案撰寫README的程序看作是真正的創作行為，你所有的好主意都應該在這里表達出來，這份檔案應該是你創造力和表達能力的證明，

README應該是代碼庫中最重要的檔案，先寫是正確的做法，

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/538997.html

標籤：其他

上一篇：將 Vue.js 專案部署至靜態網站托管，并開啟 Gzip 壓縮

下一篇：Git 的使用