本文最初發佈於hackernoon.com，經原作者授權由InfoQ中文站翻譯並分享。
你有沒有想過，爲什麼我們要花將近一個月的時間，才能把幾行代碼修改交付給我們的明星客戶或忠實客戶？當所做的更改符合產品、營銷和應用程序管理人員的要求時，有什麼會妨礙它立即發佈？爲什麼管理人員會針對維護髮佈列出一個在你看來如此“不現實”的時間表呢？這些是我在編寫生產級代碼的最初幾個月裏的思考。
在大學的時候，我總以爲完成項目就是開發，就是永無止境地編寫代碼。一旦特性的初版完成，項目即告完成。全部完成。沒有同行代碼評審，沒有文檔，什麼都沒有。只是一些原始的代碼文件，其中零星有一些註釋。它是有效的，可以滿足需求。我們從不考慮可維護性、可讀性、可伸縮性等等。你提出的功能需求，你設計了它，開發了它，然後又測試了它，你當然會對它滿意。
更重要的是，我們的軟件有效。我不只是說它沒出問題，或者它的行爲完全符合書面規範，或者它可以高效地生成報告。它是真得很有效。
但是，企業界的情況似乎有所不同。
有一種東西叫做“流程”，流程的成功/成果取決於團隊。團隊要有足夠的耐心和紀律來遵循流程。本文將討論這個所謂的流程。不同的公司遵循不同的流程，我會盡量使這篇文章儘可能的通用，以便讀者可以將自己的情況與本文的內容聯繫起來。請在評論區與我們分享您公司的流程。
第一步：軟件產品建議
產品線的市場營銷部門會分析產品服務的市場趨勢，在一個較高的層面上簡要地瞭解客戶的需求（有些客戶往往會提供更多的細節和見解，但一般情況下，很多人只會提供高層細節，因爲你還沒有表現出要給予任何承諾。這也取決於你的目標市場的活躍程度）。下面這句話總結了營銷團隊的工作。
在編程中，困難的不是解決問題，而是決定要解決什麼問題。
一旦市場營銷團隊基於前面的分析找到了一個有前途的ROI，他們就會繼續，創建一個軟件產品建議，簡要說明公司在市場上的位置、產品的規格、潛在客戶、預期收益等。一旦得到批准，領導團隊就會確定每個模塊對應的所有者——業務所有者、產品經理、S/W經理、S/W開發人員、S/W測試主管、質量經理和應用程序/客戶經理。
第二步：軟件產品規範
一旦確定了高層次的市場需求，相關的產品經理就會介入，並創建一份全面的S/W產品規範。一般情況下，其中會包括執行概要、產品描述/分類、產品分銷、客戶的特定要求和產品安全要求（適用於汽車和相關行業）。產品經理會考慮不同的受衆，並創建框圖來解釋高層次的設想。
草案准備好之後，產品經理就會將其分發給不同涉衆進行評審，並召開評審會議，討論什麼時候可以執行完成、外部依賴關係以及向客戶交付產品。
第三步：軟件架構、設計&測試計劃
一旦研發團隊與業務/營銷團隊在功能和規範上達成一致，他們就會繼續下一步工作，創建S/W架構和設計文檔。他們從產品經理那裏獲得輸入，並創建這些文檔，以便將每個營銷特性很好地映射到需求。每個需求都會映射到各自的架構和設計規範。這樣，就可以無縫地進入開發階段了。
構建軟件設計有兩種方法：一種方法是使其非常簡單，明顯沒有缺陷，另一種方法是使其非常複雜，沒有明顯的缺陷。
S/W開發經理了解所有的映射，並將需求分配給S/W開發人員（根據可用資源情況）。與此同時，S/W測試主管會了解規範，他/她將制定測試計劃和測試策略來測試特性。產品執行所需的任何豁免現在就開始執行。
在此階段，產品經理和S/W開發經理還創建了風險管理計劃，記錄了所有的依賴關係、可用的資源，以及如果事情沒有按照預期進行，可能出現的時間延遲。（通常情況下，事情並不像預期的那樣發展）。基本上，這份文檔旨在抑制所有可能的意外，但我每天都會經歷。
第四步：特性&測試用例開發——單元測試
如果軟件產品規範、需求、架構和設計文檔廣受好評，就意味着可以進入開發階段了。終於到容易產生共鳴的東西啦。
開發完全由研發團隊掌控，間歇性地從應用管理方和項目管理方那裏獲取輸入。通常，特性開發與測試用例開發同步。然而，測試用例開發將特性視爲一個黑盒，對特性開發一無所知。測試計劃的整個輸入是軟件產品規範。這有助於保持測試的公正。當特性開發部分完工時，大多數開發人員會編寫單元測試用例來檢查預期的功能。通常，單元測試是高度模塊化的，並且在函數級進行。這可以使開發人員有足夠的信心相信函數的響應總是確定的。下面是我最喜歡的一種調試形式。
最有效的調試工具仍然是經過仔細考慮的、放在適當放置的打印語句。
S/W開發經理會密切關注開發進度，並向項目經理報告執行進度的最新信息（每週/每月）。
第五步：更多測試——集成測試&靜態/動態分析
當特性和測試用例開發快完成時，開發人員會以可測試的方式將代碼交付給測試負責人。當測試團隊在代碼上執行嚴格的迭代測試時，開發人員也沒閒着，他們會執行需求級的集成測試。他們通過集成各種單元測試來測試特性/需求。他們有了足夠的信心，事情會按預期進行，但這還沒完。測試負責人將報告一些不確定的行爲，顯然，這些行爲會使開發人員感到驚訝/沮喪。通常情況下，開發人員和測試人員會保留各自的意見。你不能責怪測試人員，因爲那是他們的工作職責：發現Bug。
測試的另一個重要方面是執行靜態和動態分析。這種形式的測試屬於開發人員的職責範圍。大體上，他們會檢查代碼是否符合適當的編碼準則，先前執行的單元測試覆蓋了多少語句和函數，等等。根據我的個人經驗，通過執行這項分析，我已經修復了許多未發現的Bug。這保證了代碼的完整性，並使代碼更具確定性和可維護性。通常，一旦由開發人員提供的報告（如單元測試、集成測試和靜態分析）就緒，代碼就會被凍結。同時，測試負責人會生成測試報告。
第六步：整合
代碼被凍結。已確認。通過所有測試用例。已確認。你認爲我們可以交接並繼續前進了，對嗎？堅持住，夥計。
文檔，它的重要性再怎麼強調都不過分。
文檔是一封寫給未來的自己的情書。
這個產品現在只有兩類人可以理解——開發人員和測試人員。應用工程師/客戶工程師完全不知道如何有效地使用你提供的特性。開發人員需要編寫清晰的文檔說明如何使用該特性。不要太長，那令人厭倦。也不要太短——他們肯定會回來問你更多的問題。文檔的資源佔用經常被低估。它確實會花費你大量的時間來解釋如何使用這個特性。
S/W開發經理移交代碼，應用團隊提供產品信息，測試負責人提供報告，質量經理驗證文檔並根據流程的遵循情況來打分。項目經理把所有東西都整合在一起，召開最後的交接會議。
回到文章開頭提出的問題。爲什麼要花近一個月的時間來發布幾行代碼？
假設我們的目標是一次維護髮布，我們只執行開發、測試和文檔編制的步驟（步驟4-6）。對於一名S/W開發人員來說，代碼更改看起來可能需要兩天的時間，但是考慮到上面的步驟，實際上可能需要幾周到一個月的時間。我用下圖來說明一下。
問這個問題的人是那個火柴人。我希望他現在明白了。
原文鏈接：
Why Does it Often Take Nearly a Month to Ship a Few Lines of Code?