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