工程師最大的冤屈莫過(guò)于辛辛苦苦寫的代碼卻不受待見(jiàn)。其背后的原因往往與release做得不夠好有關(guān)。 Release直譯為“發(fā)布”，其實(shí)是“更新”的意思，是軟件開(kāi)發(fā)的重要環(huán)節(jié)。自動(dòng)駕駛的工程師們和互聯(lián)網(wǎng)行業(yè)的軟件工程師們一樣，需要通過(guò)release證明自己的工作成果。和互聯(lián)網(wǎng)產(chǎn)品不同的是，自動(dòng)駕駛的release成果看不見(jiàn)也摸不著，一切只能上路測(cè)試見(jiàn)分曉。 然而在疫情期間，各個(gè)公司都已暫停了路測(cè)。路測(cè)是代碼的試金石，一旦沒(méi)有了試金石，就需要工程師們更加用心做好release，通過(guò)純軟件的方法，證明自己的代碼的價(jià)值。 其實(shí)，不論有沒(méi)有路測(cè)，工程師都應(yīng)該認(rèn)真做release。假設(shè)一個(gè)項(xiàng)目需要50天完成，寫代碼本身可能只需要30天，剩下的20天完全用于release，一點(diǎn)也不為過(guò)。一次高質(zhì)量的release往往要經(jīng)歷以下幾個(gè)步驟。

測(cè)試：越用心做，收獲越大。

毋庸置疑，未經(jīng)測(cè)試的代碼不可以被更新。問(wèn)題是，我們?cè)撊绾螠y(cè)試，又該測(cè)試哪些部分。代碼完成之后，工程師首先要寫的一份文檔應(yīng)該是測(cè)試文檔。在文檔中，我們要把測(cè)試分為幾個(gè)步驟：?jiǎn)卧獪y(cè)試、模塊測(cè)試、集成測(cè)試。然后根據(jù)每個(gè)步驟分析代碼中所牽扯的各個(gè)環(huán)節(jié)，分析與其他部門代碼之間的關(guān)系。讓自己的工程經(jīng)理或產(chǎn)品經(jīng)理去和這些部門協(xié)調(diào)，保證更新之后部門之間的代碼不會(huì)發(fā)生“摩擦”。

指標(biāo)與報(bào)表：白紙黑字證明你的實(shí)力。

我們需要思考，可以通過(guò)哪些方式衡量自己代碼的影響力。假設(shè)你的代碼是為了提高計(jì)算速度，那么，你就要證明之前的計(jì)算速度有多慢，現(xiàn)在有多快，然后將這些數(shù)據(jù)清清楚楚地反應(yīng)在一份報(bào)表上。這份報(bào)表最好可以自動(dòng)更新，用圖表顯示出速度提升的前后對(duì)比，讓同事和老板們都可以定期看到。

掌握好更新的節(jié)奏。

你打算多久更新一次？下一次更新需要做哪些？講清你的近期規(guī)劃有助于增進(jìn)同事對(duì)你代碼的信賴度。

你是否需要留一些保留項(xiàng)目？如果想一口氣把所有功能都做出來(lái)，就會(huì)需要更久的時(shí)間。我們需要思考哪一部分可以作為V0。

如果公司對(duì)的代碼反響很好，想讓你多加一些功能，你該如何處理？這一過(guò)程很像“客服”，也需要提前講清。

人靠衣裝，code靠doc裝。

你可以把你的代碼想象為一款辦公軟件，沒(méi)有用過(guò)的用戶其實(shí)很難了解這款軟件到底值不值得買。這時(shí)就需要靠包裝與產(chǎn)品說(shuō)明了，也就是文檔（doc）。一次優(yōu)秀的更新往往需要多種文檔，包括一些幾種。

文字文檔，也是最常見(jiàn)的文檔，比如Google Docs

代碼文檔，比如markdown

公司內(nèi)部網(wǎng)的網(wǎng)站

最后，通過(guò)郵件、做報(bào)告會(huì)議等方式，為這次更新做宣傳。

如果以上這幾方面都可以做到，不但可以保證release的質(zhì)量，同時(shí)也可以提升自己在公司的影響力，為其他同事樹(shù)立榜樣，營(yíng)造積極地工程師文化。