英文原文：Why Does it Often Take Nearly a Month to Ship a Few Lines of Code?

　　本文最初發布于 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 開發人員來說，代碼更改看起來可能需要兩天的時間，但是考慮到上面的步驟，實際上可能需要幾周到一個月的時間。我用下圖來說明一下。

　　問這個問題的人是那個火柴人。我希望他現在明白了。

總結

以上是生活随笔為你收集整理的为什么我们经常要花将近一个月的时间来发布几行代码?的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。