轉行程式設計師成長史（一）《構建之法》學習筆記

眨眼又是一周，這周完成了以下工作：

與國外同事合作，完成了cpa分析

完成自動化測試系統框架的開發

進行了為期兩天的公司價值觀培訓

練習英語聽力200分鐘

閱讀了《構建之法》的前四章

這週做了很多事情，但讓我收穫最多的是閱讀《構建之法》。在介紹學習《構建之法》的心得前，先簡短總結一下其他的事情。

完成cpa分析

cpa(critical path analysis)分析即軟體關鍵路徑分析。

簡要來說，在汽車ecu軟體的開發階段，工程師通過cpa分析找出軟體設計過程中的缺陷，並及時更正，從而保證車輛執行過程中軟體的可靠性，保證乘客安全。

本週與國外同事合作完成了軟體的cpa分析，並提出了若干修改意見，例如：變數漢明距離、重要訊號備份、crc校驗等等。

這些問題已經在本週六修改完畢。並發布了乙個小版本。

自動化測試系統框架開發

自動化測試是team leader安排給我的額外專案，目的是完成回歸測試的自動化，節省人力。

為什麼會安排給我？因為整個team只有我乙個人會python。白天上班用c語言，下班回家用python，這種酸爽也是妥妥滴。

經歷了兩周苦逼的摸索，利用python基本完成了自動化測試系統框架的開發。

閱讀《構建之法》

之前，我在極客時間買了課程《軟體工程之美》，講師推薦閱讀這本書。而在開發過程中過程中，我也遇到了很大的問題，反思後明白是由於基礎知識的缺乏。之後，我在**買了該書進行學習。

對於程式設計師來說，程式（演算法、資料結構）是基本功。如果想要開發高質量的軟體，則必須將軟體開發作為工程問題解決，而軟體工程決定了軟體質量。

軟體工程包括：軟體需求分析、軟體設計、軟體構建、軟體測試和軟體維護。同時，軟體工程也包括多種開發模型，例如：瀑布模型、極限程式設計、結對程式設計。

以汽車電子行業為例，汽車ecu軟體的開發通常按照「v」模式開發流程，其本質就是瀑布模型。

首先，根據主機廠需求，系統工程師寫出系統需求。接著，軟體工程師通過分析系統需求形成軟體需求。之後，程式設計師進行軟體設計，編碼。最後，進行單元測試、回歸測試、整合測試、系統測試和實車測試。

其中，軟體開發工程師負責分析系統需求，並形成軟體需求。之後，進行軟體設計、編碼、單元測試和回歸測試。但由於我所在的公司在產品概念開發階段沒做好，導致現在很多專案直接carry over別的專案，造成現有專案沒有單元測試。

根據《構建之法》的定義，單元測試是用於測試**的基本功能/引數的正確性。同時，單元測試應該覆蓋所有的**路徑，包括錯誤處理路徑。

由於沒有單元測試，使得目前開發專案的大部分時間用於解bug。而我作為乙個轉行程式設計師更是兩眼一抹黑，完全不知道如何針對ecu**寫單元測試。針對這點，我需要在以後的工作過程中多多留心，並向跳槽來的員工請教，總有會寫單元測試的同事。

至於回歸測試，公司有專門的測試文件，我也做了很多次，基本能夠明白回歸測試的用意。回歸測試即是每次發布新版**之前所做的測試，旨在測試該版本的**與上個版本相比是否發生了功能回退。

除了上述對軟體工程基本知識的介紹，《構建之法》著重講了「人」在軟體開發中的作用。

第二章講了個人技術與流程，作者引用了cmu的專家們針對軟體工程師開發的評價模型（psp, personal software process），**如圖：

各位讀者可以根據這張**參考自己處於什麼層級，我本人應該是處於psp0的層級，真的是很慚愧，看來轉行之路還是任重而道遠啊。

除此之外，《構建之法》在第三章講了軟體工程師的成長。在這個章節，作者講了程式設計師自身的發展路徑和自我評估，以及團隊對於程式設計師的能力的要求。

第四章講了兩人合作程式設計，說明了在軟體開發過程中「1+1>2」的道理。由於我在汽車電子行業，工作中並沒有接觸過結對程式設計。因此，對結對程式設計這種工作形式並不很了解。

但根據書中的講述，能夠看出結對程式設計能夠在一定程度上保證**開發過程中單個程式設計師出現的紕漏，例如：**規範、**設計、**審核。而在汽車電子行業，工程師也會在編碼結束後開會進行review，從而在一定程度上保證**的正確性。

由於這周讀了四章，僅僅屬於皮毛。而《構建之法》的其餘章節才是精華，等下週讀完這本書再做一次總結。

轉行程式設計師成長史（一） 《構建之法》學習筆記