| 項目 | 內容 |
|---|---|
| 作業歸屬課程 | https://www.cnblogs.com/nwnu-daizh/ |
| 作業要求 | https://www.cnblogs.com/nwnu-daizh/p/12369881.html |
| 我的學習目標 | （1）學習GitHub的基本操作； （2）通讀《構建之法》，並提出3個有意義的問題； （3）學會使用Markdown |
| 參考文獻 | [1]鄒欣.構建之法——現代軟件工程：現代軟件工程[M].人民郵電出版社，2014 |
一、初步了解
上周經老師推薦得知《現代軟件工程——構建之法》這本書，提及“軟件工程”我便覺得這對於我來說無疑是很大的困難，我的編程能力並不強，但是軟件工程在我的認知里就是需要將理論與實踐相結合，而且更注重於實踐，這對於實踐能力不強的我，可以算是一個很大的挑戰。上課的時候老師說這本書寫的淺顯易懂，大家可以以很放松的心態來讀，仔細閱讀之后發現確實如此。本書用一些貼近實際的語言和例子，塑造了不同的鮮活人物形象，通過例子給我們闡述軟件工程的基本理論知識，從不同方面詮釋所謂“構建之法”
二、三個問題
1.問題一：什么是足夠好的軟件：
問題描述：在閱讀書P15的時候讀到一個問題
“市面上有這么多不完美的產品，軟件團隊為什么還要把這些不完美的軟件發布出來呢?為什么不能等到它們完美之后再發布?軟件工程的一個重要任務，就是要在時間、成本等多種約束條件下決定一個軟件在什么時候能“足夠好”，可以發布。”
剛剛看到這個問題的時候，我充滿疑惑，一個“足夠好”的軟件到底是什么樣的，它既然作為軟件創造的目標，我們要如何達到這一水平呢？
根據鄒欣老師在書上寫的，結合我的理解也就是說一個“足夠好”的軟件，絕不是一蹴而就的，而是經歷一定的軟件流程，通過全體團隊成員的努力，在一個長期階段內，逐步完成的。對於現實生活中的軟件團隊來說，一個好的產品不是一個英雄長期加班突擊出來的。
根據我查到的資料，如Ed Yourdon 發表在 IEEE Software 上的一篇文章所描述的，你可以訓練自己，編寫出足夠好的軟件——對你的用戶、對未來的維護者、對你自己內心的安寧來說是足夠好，你會發現、你變得更多產。而你的用戶也會更加高興。你也許還會發現，因為“孵化期”更短，你的程序實際上更好了。
對此可見一個“足夠好”的軟件需要滿足用戶、未來維護者以及自己內心的需求，也就是說在用戶滿意度、可維護性、可靠性和軟件流程的質量都可以滿足大家需求的軟件才能夠被稱為是“足夠好”的軟件。
那么，現在大學的學校、學院使用的教務管理系統，它可以方便學生進行個人選課資料、考試安排、考試成績等信息的查詢，也方便了學校教務老師的管理和與學生之間的溝通。但是，當它面臨“開學選課”時，就會出現二維碼無法發送、頁面無法打開、選課信息跳轉延遲等情況。那么，我們的教務管理系統能被稱為是“足夠好”的系統嗎？
2.問題二：為什么單元測試必須由最熟悉代碼的人（程序的作者本身）來寫？
問題描述：在讀到書第二章P25的時候讀到一個問題
“單元測試必須由最熟悉代碼的人( 程序的作者)來寫。”
看見這個問題的我非常不理解單元測試應該就是白盒測試，它必須要保證每個被測試的函數里邊很高的路徑覆蓋，這樣才能保證程序在各種情況下都是按照預期運行的。那么為什么單元測試應該由程序員來寫呢？如果說，程序員寫代碼的時候都要滿足易讀性，那遵循“術業有專攻”的道理，讓程序員專心寫程序，由專人來做單元測試的工作豈不是效率更高才對嗎？
對於這個問題，我查了許多資料，但是也沒有查到比較權威的答案，只是有很多人在說“單元測試是程序員的基本功”、“單元測試決定細節，細節決定成敗”這樣的話。我也可以想得明白如果這么說有個很顯然的原因就是程序員寫測試的工程也是他驗證自己思路的過程，因為程序員知道他自己寫代碼的期望結果，所以在程序出現錯誤的時候，他能夠第一時間做出判斷。
大部分上來講，我也可以比較贊成這種說法，但是聯系實際想想，如果一個程序員，他寫的程序出現了問題，而單元測試和程序的作者又都是他本人，那么他的思路和解決模式會不會因此而受到限制，是不是因為這樣而沒有意識到一些或許很簡單的問題呢？這個時候是不是需要其他人幫忙點明思路呢？還是說單元測試只需要知道程序的主題思路就可以，所以要由程序的作者本人來做呢？
后來有位老師指教我說“合並之前要讓其他人Review，通過后才能合並代碼。”這便解決了我的疑惑，我會在接下來的學習中進行更進一步的探索。
3.問題三：如何對於團隊成員進行績效管理？
問題描述：在讀到書第十七章P402的時候里面提到
“如何衡量一個人的績效考核呢？”
這個問題我們平時也可以用到，許多時候，大家越來越多的以“團隊”身份出現，共同努力去完成一件事情，此過程中也必定會出現“三個和尚沒水吃”的情況，大家都會有惰性思維也都會對互相依賴，有時候可能還會拖慢進度，如果能夠善用績效管理仿佛可以有效解決這一問題，那么如何對於團隊成員進行績效管理呢？
對此我專門查詢了微軟和谷歌兩大公司的績效管理方式，其實他們的績效考核總結出來差不多就是：
（1）績效管理一視同仁：
這一點倒是比較容易理解，大體上講就是不能搞特殊化，要對團隊所有成員一視同仁；
（2）兼顧公司業績與個人發展：
微軟將績效管理分為兩個部分，分別是公司業績和個人發展，微軟是一個知識化的公司，當員工的個人發展得到提升的時候，公司水平自然得到提升，那么公司業績也必然會更好，以此來形成良性循環，互相促進。也就是說，在團隊中的每個成員都得到良好的發展的時候，團隊也會變得更好，這樣也就會形成良性循環；
（3）考核和戰略緊密結合：
在谷歌，會有公司的領導層和專家對要開發的項目進行集體評議,對於項目負責人做出的規划大家都會進行評議，通過多數專家的思想交流，確定你所做事情的合理性。在此條件下如若你提交的方案預計3個月完成，而你花了四個月的時間，是一定會被扣獎金的；
（4）評估的周期與標准、考核決定待遇與發展
可是我還是不太理解的是有時候團隊人員做的事情是相互依賴的，有些事情並不是一個人獨立做完的，那么我們就不能夠從功能的用戶喜愛程度或功能的好壞來評價。而且如果是根據工作量來進行績效管理的話,我們該怎么樣來確定每人的工作量呢?如果是根據每人完成的任務數來確定,但是那樣又會出現每人完成的任務困難度不一樣,按任務數來確定又不太公平。那么我們應該怎么來給每人確定他們的績效呢?
三、總結
通過本次實驗，我大致通讀了《構建之法》這本書，對於其中的一些軟件工程的問題產生或多或少的疑惑，這也激起了我學習軟件工程這門課的興趣，希望在這一個學期的認真學習中，能夠大概解決我心中的這些疑惑，使自己的知識更加深入，理解更加透徹。