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

測試：越用心做，收獲越大。

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

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

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

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

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

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

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

人靠衣裝，code靠doc裝。

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

文字文檔，也是最常見的文檔，比如Google Docs

代碼文檔，比如markdown

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

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

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