提問回顧與個人總結

一、提問回顧

在學期初，我寫下了一篇關於構建之法的閱讀小結,當時針對交材提出了幾個問題並嘗試做了解答。三個月過去了，經歷了一個學期的學習與實踐，回頭看當時提出的問題，觀念和認知上有了新的變化。現在對曾經提出的問題嘗試解答。

1. Bug or feature

   軟體行業也有一句著名的笑話:It's not a bug, it's a feature!很多人認為有Bug就是不合格,沒有Bug就是質量完美．其實這也未必． ——《構建之法》

   現在回顧之前的問題，我覺得這個問題沒有必要過多地討論和深究。It's Not a Bug,It's a Feature，具體起源或許沒人能知道。這句話雖然曾經是程式設計師的行話，但如今可以適用於各個領域。通常意義上來說，這個問題是開放式的，帶有哲學意味的，不侷限於軟體行業；而從技術領域來看，對待bug的態度應該是儘量在軟體開發和測試的過程修復，而不是等到產品釋出之後，無奈而又調侃地說一句It's Not a Bug,It's a Feature.

2. 單元測試必須由最熟悉程式碼的人（程式作者）編寫嗎？

   單元測試必須由最熟悉程式碼的人（程式的作者）來寫．程式碼的作者最瞭解程式碼的目的，特點和實現的侷限性． ——《構建之法》

   經歷了團隊專案的實踐，我對於這個問題的認知有很大的變化。

   當時我認為，做好單元測試很重要，最好由他人（而不是程式的作者）編寫，因為這樣做能在測試的時候儘量做到客觀和理性。

   但現在我的想法是完全贊同《構建之法》作者的觀點。在小型專案中，專案程式碼量較少，由他人負責單元測試的成本不是很高，這個時候無論是程式的作者還是他人，編寫單元測試我認為問題不大。但對於一個大型團隊專案，如果由不熟悉程式碼的人進行單元測試，由於程式碼規模很大，重新熟悉程式碼的成本過高，測試需要額外花費大量時間和精力。而對於一個快速開發的專案來說，時間是最寶貴的。另外，由最熟悉程式碼的人員進行單元測試，由於程式碼已經具備一定的複雜度和規模，作者不太會侷限於之前的思維定勢因為之前寫的細節都已經不記得了

   ,所以不用擔心作者編寫單元測試會忽略很多bug的問題。

   事實上，在團隊專案中，我們都是負責自己程式碼的單元測試。

3. 結對程式設計的實用性和搭檔的選擇

   在結對程式設計的模式下,一對程式設計師肩並肩,平等地,互補地進行開發工作.他們並排坐在一臺電腦前, 面對同一個顯示器,使用同一個鍵盤,同一個滑鼠一起工作.他們一起分析,一起設計,一起寫測試用例,一起編碼,一起做單元測試,一起做整合測試,一起寫文件,等等.

   ——《構建之法》

   我的想法和之前一致。我認為結對程式設計對結對人員素質要求極高，並且敏捷開發要求快速產出MVP，而結對程式設計讓兩個人做同一份工作，在現實生活中結對程式設計很難有實際應用場景。

4. 如果你是病人，你希望你的醫生是下面哪一種呢？

   作為一個軟體工程師, 你覺得自己表現如何? 有沒有這樣的體會:

   看書的時候覺得“技止此耳”，開發專案的時候才覺得實際情況和書上講的都有一些出入，一些重要的細節書上沒有提。我們很多人是邊看asp.net的書, 邊開發asp.net 的專案，這相當於一邊看醫學書一邊動手術……如果你是病人，你希望你的醫生是下面的哪一種呢？

   a）剛剛在書上看到你的病例，開刀的過程中非常認真嚴謹，時不時還要停下來翻書看看……

   b）富有創新意識，開刀時突然想到一個新技術、新的刀法，然後馬上在你身上試驗……

   c）已經處理過很多類似的病例，可以一邊給你開刀，一邊和護士聊天說昨天晚上的《非誠勿擾》花絮……

   d）此醫生無正式文憑或正式醫院的認證，但是號稱有祕方，可治百病。

   事實上，很多軟體專案就是用a）或者b）這樣的方法搞出來的。當然 也有一些人走d）這條路。

   ——《構建之法》第三章

   這個問題我的看法也與之前一致。但現在有了新的想法。我認為與其將醫生劃分為abcd，不如將手術分類：a) 需要邊翻書邊開刀的手術，對應於需要邊學邊做的專案 b) 冷不丁實踐新技術的專案 c）駕輕就熟沒有任何難度的手術 d) 宣稱能按時完成，但無任何具體計劃的專案

   我認為作為一個軟體開發者，我們需要多做做a手術，私下練功夫時做做b手術，爭取讓c這樣的手術越來越多，這樣做手術時才能越來越胸有成竹。也就是說，完全沒有難度的專案沒有挑戰性，對個人的成長幫助不大；在團隊專案的過程中，最好不要臨時改變技術，這會給團隊帶來麻煩，建議私下嘗試。

5. 在校學生如何為成為一個PM做準備？

   你是否覺得你的長處不在於寫程式碼和debug，而是協調、溝通，讓一個團隊或組織有效運轉起來？你是否喜歡錶達，善於和各種專業背景的人溝通？你是否經常思考如何該井生活中點點滴滴的小問題？你是否會思考這樣的問題麼：新浪微博、豆瓣、qq、微信都可以社交，它們的定位、產品特性、使用者群、解決的需求，有什麼不同？你是否對以下領域感興趣，甚至自己找過相關的書來看：心理學、社會學、組織行為學、統計學、商業模式？

   當時對這個問題頗有疑惑，如何成為產品經理，以及大學裡是否有對應的專業和培養方案。

   參與了團隊專案、參與軟工講座以及這學期的生活經歷讓我對PM這個職業有了進一步的認識。我認為產品經理這個職業在大學裡是沒有專門的培養方案，也找不到對應的專業。從某網際網路公司對產品經歷的招聘也能看出來，這個職業對專業沒有太大限制。

   從團隊專案的實踐來看，合格的產品經理需要具備良好的管理能力（計劃、組織、領導、控制）；具備人際交流能力，能與團隊成員進行溝通交流，推動專案進展；具備設計概念圖、進行需求分析的能力，能使用相關設計工具、對相關行業/產業/產品/使用者需求有深入獨到的瞭解。

   雖然產品經理對專業沒有太多限制，但我認為計算機相關專業、工業設計、數學專業、經濟學相關專業都有成為產品經理的優勢和潛力，當然成為優秀的產品經理，更重要的是個人能力的培養。

新的問題與思考

在團隊專案工作分配時，我選擇了爬蟲和資料庫儲存的工作。在此之前我對軟體開發沒有什麼經驗，團隊選型的技術也是我當時不掌握的。於是我考慮了我對資料分析有所經驗，並對爬蟲工作有信心，做出了這個選擇。事實證明，雖然開發過程碰到了一些困難，從結果來看，我的工作完成得還不錯。

可惜的是，由於爬蟲可以作為專案中相對獨立的模組，在實際執行中也是作為一個單獨的程序常駐後臺。雖然負責爬蟲模組的開發讓我學習到了很多爬取資料的知識和技術，但由於時間和精力，我沒有深入地參與到”傳統的前後端工作“中。

在團隊專案中，個人應該如何選擇或者接受團隊的工作分配？是選擇有利於自身成長、最具挑戰性的工作、還是有利於團隊、有把握的完成的工作，這個問題我在某段時間總是會思考。經過一番思考，我認為應該以集體利益為核心，選擇後者。對技術棧的擴充套件還是放在個人專案裡吧。

二、在實踐中學習

羅傑、任健老師的軟體工程課程內容豐富，在”做中學“的過程中，我學習到了一些知識和經驗。

• 需求階段

  實踐證明NABCD分析是一種非常有效的需求分析手段。NABCD模型從Need-Approach-Benefit–Competitors-Delivery/Data五個維度刻畫需求，能讓立項時的需求變得很清晰。

• 設計

  設計階段的工作涉及到方方面面，包括軟體總體架構設計、功能詳細設計、資料庫和API介面設計、介面設計等。在實踐中我學會綜合運用很多設計工具，如UML（劃分模組、模組功能）、原型圖設計（介面設計）、E-R圖（資料庫設計）等等。

• 實現

  在開發階段，定期召開簡短的例會並總結非常必要。定期例會以及分配計劃階段劃分好的issues，能夠有效推動專案順利開展。值得注意的是，例會時間不宜過長，應該將大部分精力放在開發上，週期以1day或2days為宜，在例會上應該總結一個週期內完成的工作並計劃下一週期的工作，最後就遇到的問題進行討論；計劃的isssues可以結合實際情況動態調整，但一定要全力保證每一個週期都有任務完成，這樣才能保證在規定的開發時間內圓滿完成專案。

  scrum meeting在專案管理上給我很多幫助和啟發，我相信我會將它運用到之後的專案開發中。

• 測試

  測試的工作應該從專案開始時就考慮。CI的部署在專案開始就完成，必要的單元測試隨著程式碼的編寫完成；在開發工作結束後，應該進行壓力測試和效能測試。

• 釋出

  專案開發完成不是專案的結束，對於一個專案來說，有效且多樣化的宣傳才能實現對使用者的有效交付。

• 維護

  專案釋出之後，我們需要對軟體進行日常維護，包括運營、修復bug、版本更新。在宣發的時候就應該考慮到如何有效收集使用者反饋的問題。

三、個人小結

過去了，軟體工程課程即將正式落下帷幕。這一學期，我經歷了一個結對程式設計專案，兩個階段的團隊專案，參與完成了14篇部落格，在軟體工程課程上投入了很大的精力，也有不少收穫。

羅傑、任健老師的軟體工程課程相對於其他平行班來說，任務量很大。一個學期的課程安排非常緊湊，前期有部落格和調研，接著是結對程式設計的三個階段、團隊專案的兩個階段，中間還經歷了一次轉會。而其他平行班的同學，只有團隊專案的開發，我想凡是認真完成羅傑、任健老師的軟體工程課程作業的同學，都會”收穫滿滿“吧。

在前期撰寫部落格、調研的過程中，我閱讀了大量文章(第一次任務，你好，軟體工程)，進行了比較深入的調研（第三次任務，案例分析），通讀了《構建之法》，學習了自動化整合測試。對我來說這一階段的任務量巨大，調研與閱讀需要花費大量的時間與精力。而如今看來，這段時間給我最大的收穫是通讀了《構建之法》，瞭解到了自動化整合測試，讓我對軟體工程和單元測試有了新的認知。

結對程式設計階段，經歷了痛苦的三個階段。老實說，我認為這一階段在軟工開發中有點不合時宜。一方面我對結對程式設計這種形式我也很難認同（前文已經提及），而另一方面結對程式設計佈置的任務給我的感覺更像是OO的課程作業。私以為軟體工程課程的核心思想是敏捷開發，要求在較短時間內開發出一個最小可行產品出來，而結對程式設計作業的形式沿襲了OO課程，以AK為導向，佈置的作業也與OO的風格很像。以AK為導向的課程作業不可避免要求同學們追求細枝末節上的完美，但課程作業又有不少紕漏，這導致同學們在對需求文件咬文嚼字上以及測試極端資料上需要花費大量的時間。而這與敏捷開發的思想是有衝突的。在這一階段，我的最大收穫或許是如何快速開發一個程式吧（但這一收穫我在OO已經學到了）。

團隊專案階段是我收穫最多的階段。通過與團隊成員長達兩個月的合作，我們完成了一個尚有缺點、但總體完成度很高的專案！而開發過程中十幾次的例會、十幾篇部落格、宣傳文案、宣傳視訊也都是很有意義的產物！在爬蟲方面我學習到了很多有用的知識和技術，更重要的是通過參與整個專案的開發，我對軟工開發的流程有了整體的認知和巨集觀的把握，這對我以後的軟體開發來說是非常寶貴的經驗。這個專案，凝結了團隊所有成員的心血，也凝結了我的心血，我可以很自豪地將它寫進我的簡歷啦。通過兩個月的團隊專案開發，我結識了五位小夥伴，收穫了寶貴的友誼。回顧當初的團隊自我介紹，現在來看我在這個團隊中許下的期許都得到了滿足。