閱讀《構建之法》1-5章的感想

這個做業的要求來自於：https://edu.cnblogs.com/campus/gzcc/GZCC-16SE2/homework/2178

---

 

 第1章 概論

       第一章前部分主要說了軟件、程序、軟件工程三者之間的關係，首先當寫了一個程序擁有了必定的用戶隨之而來的需求這時候便須要出現一個軟件去知足各類功能，而後再擴展到一個能保證服務質量的軟件服務，而軟件構建的過程又是十分複雜的，在保證軟件在修改過程當中能不斷提升質量又保持之前的質量，就須要進行軟件測試，一個軟件是否實現它的價值這時候就須要從需求分析開始，把合適的需求梳理出來，再開展後續工做，到最後發佈軟件，總的來講就是：軟件=程序+軟件工程 一個擴展的推論是：軟件企業=軟件+商業模式。 軟件開發包括四個階段：1.玩具階段 2.業餘愛好階段 3.探索階段 4.成熟的產業階段 

      接下來讀者向咱們介紹了什麼是軟件工程？ 總的來講軟件工程是把系統的、可量化的方法應用到軟件的開發、運營和維護上的過程。包括下列領域：軟件需求分析、軟件設計、軟件構建、軟件測試和軟件維護。

      看完了第一章我有一個疑問就是：咱們目前所學的專業知識是否與在外工做所需的知識技能是否匹配呢？

---

 

 第2章 我的技術和流程

       第二章前部分主要說單元測試，單元測試能有效解決本身負責的模塊功能定義沒法明確、模塊內部改變影響其餘模塊、模塊質量沒法保證穩定的、量化的等一系列問題，但是怎樣纔算一個好的單元測試呢?首先單元測試應該在最基本的功能/參數上驗證程序的正確性，單元測試也必須由最熟悉代碼的人(程序的做者)來寫，單元測試事後，機器狀態保持不變，單元測試要快（一個測試的運行時間是幾秒鐘，而不是幾分鐘），並且單元測試應該產生可重複，一致的結果，還有獨立性-單元測試的運行/經過/失敗不依賴於別的測試，能夠人爲構造數據，以保持單元測試的獨立性，還有單元測試應該覆蓋全部代碼路徑且集成到自動測試的框架中，並和產品代碼一塊兒保存和維護。

      接下來就是講的是效能分析工具，如何能讓本身的程序跑得又快又好，通常的作法是先用抽樣的方法找到效能瓶頸所在，而後對特定的模塊用代碼注入的方法進行詳細分析，接着代碼分析的結果就出來了，能夠繼續進行「效能測試，分析改進，再效能測試」的流程，逐漸提升程序的效能和咱們的編程水平，可是也要避免沒有作分析就過早地進行效能提升，若是咱們不經分析就盲目優化也許會事倍功半。

      看完了第二章我有一個疑問就是：若是單元測試的結果是錯的，爲何必定是程序出了問題？

---

 

 第3章  軟件工程師的成長

     這一章主要是講軟件工程師的成長，主要從我的能力的衡量和發展、軟件工程師的職業發展、技能的反面一共三個方面來說述軟件工程師的成長。

     首先咱們應該如何來衡量證實本身的能力呢？首先是成長，讀者認爲：1.積累軟件開發相關知識，提高技術技能。2.積累問題領域的知識和經驗。3.對通用的軟件設計思想和軟件工程思想的理解。4.提高職業技能。5.實際成果。接着衡量軟件開發的工做量和質量，從如下四個方面：1.項目任務有多大。2.花了多少時間。3.質量如何。4.是否按時交付。而後是團隊對我的的指望：1.交流。2.說道作到。3.接受團隊賦予的角色並按角色要求工做。4.全力投入團隊的活動。5.按照團隊流程的要求工做。6.準備。7.理性的工做。

     那麼軟件工程的職業是如何發展的呢？ 首先考級之路，接下來是職業成長，而後是大公司版本，例如成爲一個高級工程師，最後是對自個人評估。

     那麼什麼是技能的反面呢？就是一個「不精通」的面試者的編程過程實際上就是一個「解決問題」的過程。那麼咱們該如何提升咱們的技能呢？首先咱們須要經過不斷的練習，把那些低層次的問題解決了，變成不用通過大腦的自動操做，而後纔有時間和腦力來解決高層次的問題。

    看完了第三章我有一個疑問就是：在現在的時代，須要一位具有什麼職業素養的軟件工程師？

 

---

 

第4章 兩人合做

      這一章一開始寫的是如何規範咱們寫的代碼：1.代碼風格要規範。2.代碼設計要規範。 那麼代碼風格須要怎麼樣規範呢？首先代碼風格的原則是:簡明、易讀、無二義性（縮進、行寬、括號、斷行與空白的{}行 、分行、命名、下劃線、大小寫、註釋）；那麼代碼設計要如何規範呢？最好遵照如下規定：1.函數。2.goto。3.錯誤處理。4.如何處理C++中的類。

       接着講代碼複審，代碼複審的正肯定義：看代碼是否在「代碼規範」的框架內正確地解決了問題，那麼代碼複審的形式是什麼呢？1.自我複審。2.同伴複審。3.團隊複審。而同伴複審是最基礎的複審手段。代碼複審的目的在於：1.找出代碼的錯誤。2.發現邏輯錯誤。3.發現算法錯誤。4.發現潛在的錯誤和迴歸性錯誤。5.發現可能須要改進的地方。6.教育（互相教育）開發人員，傳授經驗讓更多的成員熟悉項目各部分的代碼，同時熟悉和應用領域相關的實際知識。那麼怎麼樣是一個簡單的代碼複審覈查表，主要包括：概要部分、設計規範部分、代碼規範部分、具體規範部分、具體代碼部分、效能、可讀性、可測試性。

     在咱們之後的項目中，有着很是多的並且多變的項目需求，同時存在着工期、質量、和資源的矛盾，咱們團隊成員各自的水平、目標也不一致。那麼咱們如何來構建一個和平友好高效的團隊呢？我以爲在一個團隊中，每一個人都有本身不一樣的想法和意見，這時如何能說服對方？我以爲咱們雙方都須要意識到，問題早點出現要比晚點出現要好得不少，而且正確地給本身的搭檔給予反饋。

     看完了第四章我有一個疑問就是：爲何要結對編程？我以爲單人編程也挺好的。

 

---

 

第5章 團隊和流程

    這一章一開始寫的是非團隊和團隊。團隊是有一致的集體目標一塊兒完成這個目標，一個團隊的成員不必定要同時工做，而非團隊成員則想搬多少就搬多少，不想搬了就走人。團隊成員有各自的分工，互相依賴合做共同完成任務，而非團隊成員各自行動獨立吧任務完成，軟件團隊的模式有如下幾種：1.一窩蜂模式。2.主治醫生模式。3.明星模式。4.社區模式。5.業餘劇團模式。6.祕密團隊。7.特工團隊。8.交響樂團模式。9.爵士樂模式。10.功能團隊模式。11.官僚模式。

   接下來說的是開發流程。有如下幾種模式：1.寫了再改模式。2.瀑布模式。3.由瀑布模型的各類變形。4.統一流程。5.老闆驅動的流程。6.漸進交付的流程，mvp和mbp。7.tsp的原則。

    看完了第五章我有一個疑問就是：流程的目的是什麼呢？

 

---

 

 參考文獻

技術人生的職場衆生相 – 十多年的經驗與心得   http://kayow.com/2018/05/devlife/

 https://www.cnblogs.com/xinz/p/3852177.html《現代軟件工程 課件 軟件工程師能力自我評價表》