臨近學期末，本學期的軟體工程課也已經結束了，在此我對軟體工程課中，我們團隊M1和M2開發階段中，我做的工作做一個總結
我是DEV，主要工作是等著上級給我分配任務，但是很多時候如果這個活我不幹，其他人就幹了，導致我的貢獻分就危險了，所以多數時候需要搶活幹，主動點才有飯吃。
在M1階段，我們多次開會，重點討論了究竟要加什麼功能。這是一個非常艱難的過程，因為爬蟲軟體的功能很明確就是爬取連結及其所有子連結，而這個功能已經被實現了，所以我們討論的重點就是如何花式爬取網頁。最後我們定下來，要實現多種爬取方式，比如關鍵字爬取等，同時還要對爬取到的各種資料做好管理工作，比如按熱度排序等。
當然我們這個階段犯了一個比較大的錯誤，由於我們的使用者——下一個小組沒有找我們強調他們的需求，導致我們蹭蹭蹭做出來之後，我們唯一的使用者表示這東西不好用啊，我們還要爬ppt啊。雖然他們沒說，但是應該做好使用者需求分析的應該是我們，使用者才是上帝，所以我們默默把這個鍋接了。
具體的程式編寫，我負責的模組還是比較順利的，並且同時我也發現了連結傳遞時存在中文會變成亂碼的問題，最後使用統一的UT8編碼解決了這個問題。由於不太信任我們的TEST，所以我自己也對我自己的模組做了許多測試，確保基本功能無誤才嵌入了程式碼。
M1階段完成後，我們的爬蟲軟體也算功能眾多了，看著我們做出來的軟體，心裡還是有點小激動的，尤其還是得到了老師的讚許。
在M2階段，我們吸取了許多教訓，比如提前詢問了我們唯一的使用者的需求，再三確認後才開始工作，確保完成我們唯一的上帝的要求。
M2階段我主要負責修改網頁的儲存方式，因為之前是直接把檔案命名為其uri的，這樣存在許多問題，比如檔名過長無法在本地儲存，存入資料庫時會造成亂碼等等。我一開始想通過將檔名做HASH函式處理後再儲存的問題，後來放棄了這個想法，直接給每個網頁分配一個唯一的ID，使用這個ID號作為檔名，很好地解決了這個問題。
同時我還協助修改了許多bug。
http://www.cnblogs.com/wyjbjl/p/4028189.html
這是以前提出問題的部落格連結。
1.像這一類書籍，怎麼閱讀才更有效？
以我這幾年看程式設計書籍的經驗來說吧，我第一次看C++教程時，基本只是通讀了全書。真正到要寫程式碼時，還是沒有什麼概念。但是比如作
業要求我寫具有某個功能的程式時，我再去翻程式設計書，這時邊看邊寫，就基本可以記得下來。很多時候，當自己親自去從頭寫程式時才會
2.命名規範為什麼是加字首？
其實現在我還是習慣於加字尾，比如tableA，它的數量我就喜歡命名為tableA_num，因為在使用CB,VS一些程式設計軟體的時候，打出字首就可
以自動找到對應的變數。加字尾時的邏輯一般是這樣的，先是這個變數的“名字”，再是相應的“成員”，比如“tableA_num”表示的就是
“tableA”的“數量”，由於我喜歡先搞清楚這個東西“是誰的”，再搞清楚這個東西“是什麼”，因此我喜歡使用加字尾的命名方式。
字首表示的邏輯是這樣的，先是這個變數的“成員”，再是相應的“變數”，比如“num_tableA”表示也是“tableA”的“數量”。這種命
名方式先搞清這個“是什麼”，再搞清楚這個“是誰的”。這樣做的好處就是，起碼不會搞錯這個變數的型別，字尾命名就比較容易隨手一
點，點錯了型別。（說的好像字首不容易寫錯一樣。。。算了相對不容易一些），我覺得這種命名規範在合作程式設計的時候只要約定一下不要
搞混了，都是可以的。
3.對於一個已經有一定規模的軟體，增加功能重要還是精簡功能重要?
在做過我們團隊的專案後，我對這個問題也有了自己的體會，我們拿到學長的程式功能非常簡單，就是一個網頁爬蟲，給連結，就會迴圈爬
取其所有子連結。這當然不能算一個有一定規模的軟體，因此增加其可用性是非常重要的，我們加入了許多新功能，比如關鍵字爬取等等，
同時也砍掉了學長的許多功能，因為他們根本就沒有被實現。如果一個模組無法完全實現既定的功能，那麼容易造成冗餘，還是去掉比較好
。
4.程式質量控制的重要性？
就我本人而言，我還是非常重視程式質量的控制的。由於本人比較粗心，每寫完一段，我都喜歡再看上一遍，確保沒有問題。但是同時來說
，過於重視程式的質量，容易失去程式設計的敏捷性。我個人是程式質量優於敏捷性的，程式當場寫當場debug比較好，因為剛寫出的程式碼自己
比較熟悉，也比較好改，時間久了就不好說了。
5.DEV要不要TEST自己的程式碼?還是一直專注於寫?讓專門的TEST來做?
最熟悉自己程式的肯定是編寫者，當程式比較大時，比如這次的電梯程式，涉及到許多類之間的協調，那麼測試者就會十分痛苦，因為他要
先搞清楚程式的執行機理，那我才能給出比較好的測試用例，出現bug時，debug人員也要先搞清楚程式的機理才能debug。如果是編寫者，
輸出的資料發生異常時，他比其他人更容易想到這個錯誤的原因，那麼是不是當程式比較複雜不好測試不好debug時，由編寫者自己來做一
部分測試工作？
上面是當時自己得出的答案，經過專案的開發後，我又有了一些新的體會。畢竟做專案是有工期的，如果時間比較充裕，為了減小工作量，
DEV大可不必進行TEST工作，而專門交給TEST去做，出了問題再解決。這樣的好處就是每個人的工作量都比較小，畢竟人還是要休息的。但
是如果工期比較緊的話，那DEV還是要做一些基本的TEST的，畢竟最熟悉自己程式碼的肯定是自己，自己TEST肯定效率是最高的。
產生的新的問題：
由於我們的使用者就是下一個小組，因此我們主要要滿足他們的需求。而他們的需求是會變的，比如我們寫好了這個功能給他們，他們用著用著發現需要的東西又多了出來，這時候又要找我們重新加功能。也就是說，使用者的需求不固定。但是各個小組間的溝通又不夠，再時間不夠的情況下，容易產生下一組怪我們沒有提供足夠的功能，而我們又怪他們不早講，這種情況。
需求/設計/實現/測試/釋出/維護
需求階段：需求是來自使用者的，瞭解好使用者才是需求階段最重要的任務，需求分析及其重要！否則做完了東西發現功能不能滿足使用者的需求，那是要返工的。
設計階段：我們是在學長的程式碼基礎上進行修改的，學長沒有提供文件，因此應該讀程式碼，確定軟體各個組成部分內的演算法以及各部分的內部資料組織。
實現階段：實現主要指編碼實現，編碼是我們的老本行了，要說學到了什麼，主要是編碼時要寫好文件，注意規格吧。
測試階段：測試應該做好單元測試，寫好測試用例，保證覆蓋到儘可能多的情況。
釋出階段：釋出前要再三檢查，確保萬無一失再進行釋出，再發布一次可是很傷的。
維護階段：一個模組出了問題或是進行更新時，修改的時候要注意和他有關係的模組，注意是不是要同時修改。