高品質軟體文件：持續分享技術與知識
簡介
本書囊括了各種情境下的文件需求以及對應的製作方法，主要概念是 :
- 文件是用來傳遞知識的
- 如果程式就是呈現知識最好的載體，那文件就應該從程式產生，隨實際情況變動
- 更好的情況下，任何其他包含知識的檔案如環境設定等，也應該自動化變成文件
本書從第一章就展示了一個理想情境，在商業邏輯、詞彙表、環境設定、部屬流程、架構圖、設計決策、測試案例都已經能自動化變成文件的情況下，專案成員能以多高的效率合作與討論解決方案。
剩下的章節大多在說明實際情況下該怎麼處理下列對理想情境的阻礙 :
- 文件無法反映實際情況
- 文件的維護成本過高
- 知識的保質期過短
本書提供的解決方案是使用工具對有價值的知識自動化產生文件。從另一方面來說，目前比較接近作者理想的實務方法就是BDD以及DDD了，因為兩者在執行上都需要為PM以及RD設計出屬於該專案的共通語言，因此也更有利於自動化產生活文件。這樣一想，或許直接把商業邏輯寫進Rule Engine可能更好，畢竟這種做法可以更方便非開發人員作調整，只是目前還沒看過有人這樣實作系統。
心得
由於我個人推崇文學程式設計因此才會看的標題就買下這本書，雖然把程式當成單一事實來源並藉此降低製作文件的成本是很好，但是這仍然與我的理想有根本性的差距。
因為程式實作根本上來說是需求想要的成果的投影，而自動化工具生成的文件只是對實作細節的補充說明，本書的活文件的範圍仍只包含實作文件以及驗收測試文件，因此需求領域包含的知識以及實作之間仍然會有落差。
以商務應用來說，我更希望撰寫需求文件後，裡面的業務邏輯以及資料流能直接生成程式以及測試，就算是只在特定領域以及框架下能達到這個效果，人們也就再也不需要煩惱任何實作與期待不符的問題了，甚至Bug也不會存在，畢竟當需求能產生程式的時候，Bug其實就是需求的衍生物。最近的趨勢有很多 XXX as Code 以及 No Code 的服務出現，未來在某些領域應該會出現統包PM跟Tech Planner的 No Code 工程師吧，那還真是內向仔的噩夢。