（第一個問題和自己的看法）

在鄒欣老師的《構建之法》中我讀完了第一章我對 的說法一直是認同的我也一直覺得這說的沒問題但是當我看到了鄒欣老師舉出來的例子我發現一個好的軟體不僅僅是光有演算法資料就好了我發現還需要很多的維護功能二者僅僅是在船艦一個軟體的初始階段也就是鄒欣老師說的玩具階段只是在自己這裡可以使用可以滿足自己對這個軟體的構想然而對於後面的階段也就是自己想要讓自己的軟體能夠讓大家去使用這時候也就是探索階段剛開始去嘗試一些現在大部分軟體應用該有的功能然後去尋找該軟體的市場去調查也就是使用者的需求還有這個面向的是什麼市場在經歷了這一系列階段那就慢慢的讓一個軟體走向成熟變成一個成熟的產業階段所以我覺得鄒欣老師舉出的從一個玩具紙飛機到一個可載人的逐漸商業化實現飛機這個交通工具的實現例子簡單又模糊的認識了軟體工程。

（第二個問題和看法）

關於鄒欣老師說的考級之路在看到這個文案的時候沃不禁想到以前總認為一個專案或者是一個公司做的軟體什麼的基本上都是團隊合作所以不存在你做前端就不需要掌握後端的知識到那時在看完了這章節後我發現一個合格的軟體工程師不只是要只會負責自己的鄰域要去不斷的考證提升自我的實力吸收更多的知識那麼一個程式設計師的壽命才會久遠而且如果你要進入更加高階的公司比如你想要進入微軟公司那麼你就要要去考究他專有的證書（MCP）這其實也是獲得了和公司合作的機會到後面才能進入更加大公司進行合作或者是擁有工作的機會所以說一個合格的程式設計師那一定是不斷進步的當你懈怠過後那麼就會被掌握更多技能的人給擠掉這就是為什麼很多程式設計師的在一個公司的壽命只有幾年左右因為不學習安於現狀這就是我對於鄒欣老師的這張的理解看法。

(第三個問題和看法)

關於鄒欣老師提出的程式碼規範這就是事關兩人之間的合作還有為後續程式的開發更新維護工作都是非常的講究的這一點我能理解因為做好的註釋好的排序確實是可以讓自己更加清晰和讓合作的人能快速的招到關於一個功能程式碼的位置在一本《程式碼整潔之道》裡我也深刻認知到要有好的排序和註釋以便以後維護或者是在一個軟體專案的合作上能夠讓進度更快讓合作伙伴更加的舒服當然程式碼的規範之道也不僅僅就是註釋你得說明他是做什麼（what）為什麼這麼做（why）以及要注意的地方大小寫還有下劃線這些都是能夠讓程式設計師能夠清晰分辨是包還是類在做完這些之後還得進行程式碼的複審就是1.程式碼符合需求和規格說明嗎？2.程式碼設計是否考慮周全?3.程式碼可讀性如何？4.程式碼容易維護嗎？5.程式碼的每一行都執行檢查過嗎？這些都是在程式碼規範裡面的內容在我看來確實這些問題是必不可少的。

 （第四個問題和看法）

鄒欣老師提出的軟體團隊模式分為幾個模組又分為幾個文件

讓我不禁覺得有一個分工明確並且好的團隊是多麼的重要只要有一部分出現了問題那麼一個專案是肯定不能在預期達到想要的效果的所以我覺得一個團隊有一個好的分工是非常重要的每個團隊又有各自的分組這讓我感覺的到非常的愉快並且在以往在校園做專案的時候也感覺到一個好的團隊可以讓各自的工作進行的非常愉快。

（第五個問題和看法）

也是我對與鄒欣老師這本書的一些看法我覺得軟體工程不是你光會編碼就能完成一個專案一個軟體專案是對於各個階段有著每一個的做法還有專案在團隊中有可能會有這樣的情況：“為什麼他的任務比我的少？”，“為什麼他工資比我高？”。那麼團隊中這樣的分配如何找到一個平衡點？所以對於一個團隊的管理可能也是以一個大問題在有好的人員又該如何去管理呢這就是我的問題了？？？？