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

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

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

指標與報表：白紙黑字證明你的實力。

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

掌握好更新的節奏。

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

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

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

人靠衣裝，code靠doc裝。

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

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

代碼文檔，比如markdown

公司內部網的網站

最后，通過郵件、做報告會議等方式，為這次更新做宣傳。

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