眨眼又是一周，這周完成了以下工作：
- 與國外同僚合作，完成了CPA分析
- 完成自動化測試系統架構的開發
- 進行了為期兩天的公司價值觀教育訓練
- 練習英語聽力200分鐘
- 閱讀了《建構之法》的前四章
這周做了很多事情，但讓我收獲最多的是閱讀《建構之法》。在介紹學習《建構之法》的心得前，先簡短總結一下其他的事情。
完成CPA分析
CPA(Critical Path Analysis)分析即軟體關鍵路徑分析。
簡要來說，在汽車ECU軟體的開發階段，工程師通過CPA分析找出軟體設計過程中的缺陷，并及時更正，進而保證車輛運作過程中軟體的可靠性，保證乘客安全。
本周與國外同僚合作完成了軟體的CPA分析，并提出了若幹修改意見，例如：變量漢明距離、重要信号備份、CRC校驗等等。
這些問題已經在本周六修改完畢。并釋出了一個小版本。
自動化測試系統架構開發
自動化測試是Team Leader安排給我的額外項目，目的是完成回歸測試的自動化，節省人力。
為什麼會安排給我？因為整個Team隻有我一個人會Python。白天上班用C語言，下班回家用Python，這種酸爽也是妥妥滴。
經曆了兩周苦逼的摸索，利用python基本完成了自動化測試系統架構的開發。
其流程為：利用python調用編譯器自動編譯代碼，然後打開CANoe下載下傳代碼到ECU，接着操縱CANoe進行自動化測試。
閱讀《建構之法》
《建構之法》的閱讀心得是本篇文章的重點。我之是以閱讀這本書也是各種機緣巧合促成的。
之前，我在極客時間買了課程《軟體工程之美》，講師推薦閱讀這本書。而在開發過程中過程中，我也遇到了很大的問題，反思後明白是由于基礎知識的缺乏。之後，我在淘寶買了該書進行學習。
在閱讀的過程中，書中提出的很多理論給我留下了深刻印象。例如：程式 = 資料結構+算法，軟體 = 程式+軟體工程，軟體企業 = 軟體+商業模式。
對于程式員來說，程式（算法、資料結構）是基本功。如果想要開發高品質的軟體，則必須将軟體開發作為工程問題解決，而軟體工程決定了軟體品質。
軟體工程包括：軟體需求分析、軟體設計、軟體建構、軟體測試和軟體維護。同時，軟體工程也包括多種開發模型，例如：瀑布模型、極限程式設計、結對程式設計。
以汽車電子行業為例，汽車ECU軟體的開發通常按照“V”模式開發流程，其本質就是瀑布模型。
首先，根據主機廠需求，系統工程師寫出系統需求。接着，軟體工程師通過分析系統需求形成軟體需求。之後，程式員進行軟體設計，編碼。最後，進行單元測試、回歸測試、內建測試、系統測試和實車測試。
其中，軟體開發工程師負責分析系統需求，并形成軟體需求。之後，進行軟體設計、編碼、單元測試和回歸測試。但由于我所在的公司在産品概念開發階段沒做好，導緻現在很多項目直接carry over别的項目，造成現有項目沒有單元測試。
根據《建構之法》的定義，單元測試是用于測試代碼的基本功能/參數的正确性。同時，單元測試應該覆寫所有的代碼路徑，包括錯誤處理路徑。
由于沒有單元測試，使得目前開發項目的大部分時間用于解Bug。而我作為一個轉行程式員更是兩眼一抹黑，完全不知道如何針對ECU代碼寫單元測試。針對這點，我需要在以後的工作過程中多多留心，并向跳槽來的員工請教，總有會寫單元測試的同僚。
至于回歸測試，公司有專門的測試文檔，我也做了很多次，基本能夠明白回歸測試的用意。回歸測試即是每次釋出新版代碼之前所做的測試，旨在測試該版本的代碼與上個版本相比是否發生了功能回退。
除了上述對軟體工程基本知識的介紹，《建構之法》着重講了“人”在軟體開發中的作用。
第二章講了個人技術與流程，作者引用了CMU的專家們針對軟體工程師開發的評價模型（PSP, Personal Software Process），表格如圖：
各位讀者可以根據這張表格參考自己處于什麼層級，我本人應該是處于PSP0的層級，真的是很慚愧，看來轉行之路還是任重而道遠啊。
除此之外，《建構之法》在第三章講了軟體工程師的成長。在這個章節，作者講了程式員自身的發展路徑和自我評估，以及團隊對于程式員的能力的要求。
第四章講了兩人合作程式設計，說明了在軟體開發過程中“1+1>2”的道理。由于我在汽車電子行業，工作中并沒有接觸過結對程式設計。是以，對結對程式設計這種工作形式并不很了解。
但根據書中的講述，能夠看出結對程式設計能夠在一定程度上保證代碼開發過程中單個程式員出現的纰漏，例如：代碼規範、代碼設計、代碼稽核。而在汽車電子行業，工程師也會在編碼結束後開會進行Review，進而在一定程度上保證代碼的正确性。
由于這周讀了四章，僅僅屬于皮毛。而《建構之法》的其餘章節才是精華，等下周讀完這本書再做一次總結。
ps. 歡迎關注我的公衆号[酷酷的coder]，分享轉行菜鳥程式員成長過程彙總的煩惱和反思。
