閱讀部落格
問題回顧
1
2.1 "是以，寫單元測試沒有比作者更适合的人選了。"
現在想來，當初的我是把單元測試神格化了。我的腦子裡似乎認為單元測試就是測試的所有，這次當了半個多學期的測試我才認識到單元測試隻是測試環節中的很小的一部分，而且在非測試驅動開發的模式下确實應該由作者本人來編寫。因為單元測試的目的就是驗證寫出來的代碼和腦子裡的代碼一緻，而驗證腦子裡的代碼這一步應該由其他測試環節保證。
2
3.1 "軟體工程的創始者之一瓦茨·漢弗雷總結說，軟體領域可以分為兩個方面：一方面是技藝創新的大爆發；而另一方面是堅持不懈的工程工作，包括軟體的改善、維護和測試等，這一方面占了90%—95%的比例。"
我的意見沒有發生改變，我依然認為他的這番話不是對個人的評價，而是整個軟體的工程實作。
3
3.3 技能的反面
我現在覺得需要分情況決定是否應該進行大量的訓練來将低層次的問題解決變成不用經過大腦的自動操作。
讓我改變想法的原因是這次我切實地感受到“時間不夠用”的問題。和以前我熬一下夜、趕一下工就能解決的“時間不夠用”不是一個量級，這次的時間不足度可能會是需要已有工時的四倍、五倍才足夠。我在想，如果我是一名編寫測試樣例的老手的話，或許效率能是現在的好幾倍，畢竟能省去太多試錯、思考的時間了。
但我依然覺得這應該是有所取舍的，過長時間執着在一個點上，對于我們這個行當的“匠人”而言并不是良好的發展方式。我們需要時常去看看新的東西，去學習新的東西，是以一樣事物的練習時間不應該過長。
4
4.2 "另外，注釋（包括所有源代碼）應該隻用ASCII字元，不要用中文或其他特殊字元，否則會極大地影響程式的可移植性。"
我事後想了想，誠然，utf-8正變為主流，但是考慮到對過去産品的相容性，确實ASCII字元會有更好的可移植性。
5
4.3 "函數最好有單一的出口，為了達到這一目的，可以使用goto。"
意見不變。
6
4.4 在todo标記那裡加上人名
現在我覺得這在某些開發模式下确實是個好習慣，因為像是靈活開發時，每個疊代的人員基本不會變動，而且像是我們這次的開發過程中，項目管理和版本控制是非常緊密地聯系在一起的，是以在代碼中使用人名指定任務确實是個不錯的做法。
不過，當然，也有不适合的開發模式，以一個較長時間為周期進行開發的模式就不适合這種。
7
4.5 "如果團隊的人員要在多個項目中工作，不能充分保證足夠的結對程式設計時間，那麼成員要經常處于等待的狀态，反而影響效率。"
意見不變，而且還要追加對scrum meeting的質疑。我們并不是全職的軟工課程學生，每個工作日都要求我們在軟工項目上有所進展是太不合理的要求了。
8
5.2.5 秘密團隊
知識點總結
需求
需求方面讓我眼前一亮的是“黑客”，這類惡意的存在，也是我們的使用者，不過是惡意使用者。他們也會為我們提供需求，不過我們要做的是防止他們的需求被滿足。需求分析不應該隻對理想使用者，而是應該考慮到所有可能與産品産生互動的存在。
設計
這次前端和UI的設計互動讓我感覺很欣賞。他們首先決定由UI進行主導，然後UI會反複詢問前端、PM，對設計的可行性、合理性進行讨論，同時前端還會對設計的方法為了可行性而進行限制。這樣一套設計方法真的很有效。
實作
實作方面，其實我感受最深的是實作的進度管理問題。良好的commit記錄能讓進度管理變成一件很舒心、輕松的事情。commit記錄本身就包含了“完成時間”、“複雜程度”、“項目進度”等等資訊。
測試
最大的收獲是領悟到了“測試應盡可能不幹涉開發”。這展現在多方面，像是版本控制應獨立、應盡可能讓測試配置與生産配置相似、代碼的依賴性應是單向而且盡量松散的等等。項目剛開始的時候因為沒有意識到這件事情，我做了太多無用、甚至有害的工作了。
釋出
釋出……俺一竅不通诶，這部分俺一點也沒了解。要說的話，領悟到的是一項産品一旦進入到市場中的話就應提供與市場主流一緻的、或者同等級的服務，而不管這項産品的投入是多少。因為投入與回報并不是一個線性曲線，如果提供的服務沒有到一定的線的話，是一點回報也不會有的。
維護
“資料維護”，這是我領悟到的一點。我以前對維護的認識局限于“服務維護”、“代碼維護”，但這次了解了資料庫以後（我大三上沒修資料庫），我才意識到資料庫現在原來如此重要、複雜。我意識到了現在的維護中很大很大的一塊應該是資料維護，這包括現在的資料存儲格式的向後相容性、已有資料的備份等在整個項目生命周期上的資料保障。
個人心得
我本來以為我很會敲代碼、很會開發的。這種自傲并非空穴來風，我姑且還是讀過一些大工程的源碼（主要是遊戲的就是了x），也寫過很多很多代碼，也和别人共事做過東西（那時候我還是leader呢，雖然現在回想起來很不稱職），我确實是有一些自傲的資本的。但是我也切實地感受到了自身經驗、能力的嚴重不足。
在結對程式設計的時候，我缺乏手段去滿足一個高難度的需求。是的，那确實是非常高難度的，憑我的算法能力肯定無法解決，但這并不代表我就一定沒有任何手段去做到。當時的我直接放棄了。現在我回想起來不禁打了一個寒戰，怎麼可以放棄？那是一個産品的需求，怎麼可以放棄？确實，我當時做了很多工作來說服自己去放棄，那些工作也确實是有效的，但我的思路太過狹隘了。我僅僅是說服了自己“憑我和我搭檔的算法水準是無法解決這個問題的”，僅僅隻是說服了這點，我就說服了自己去放棄一個需求。明明除此之外還有不計可數的手段。真正的産品開發中，可以依靠的遠不止自身的基礎能力。我以前就明白一些這個道理，我知道去尋找别人已經造了的輪子，但我的了解還是太過狹隘，肯定還有更多更廣的思路。現在的我還沒有那個經驗與能力去講明白那些思路，我還有很長的路要走。
團隊項目中也是，我深深地意識到了工時是一件多麼嚴苛的事情。事實上，要完成所有我預期的目标的話，我估計需要的時間是這次的實際工時的五倍。我缺乏經驗，無畏地給自己填充目标、任務，對它們的時間估計不合理。我缺乏能力，有很多期許的願望最後并沒能實作，它們在我腦中雖然存在繪景，但那與現實太過遙遠，我的想象太過朦胧而與現實脫節，要讓這份想象具象化需要太多試錯、努力了。我現在甚至覺得，哪怕讓我重來一次，我也依然做不到我的理想，我做不到，這不是先驗先知就能解決的問題，而是時間本身就限制着問題的解決。哪些是一定要做到的——我怠惰地、自傲地将太多工作都劃進了這類工作裡，結果導緻工作反而失去了優先次序。
說起來似乎每次完成一個項目的時候我都是這種感覺，“自己有太多的不足了”。這些問題不是一套軟工方法就能解決的——我察覺到了這件事情。誠然，這其中有大量的問題都源自非編碼工作，它們似乎可以用一套軟工方法來解決，我以前都是這麼覺得的。但事實上，這次實踐了一段時間後，我才察覺到要實踐那些規範本身就要求着豐富的經驗與出色的能力。舉個例子，我對工時的估計的錯誤，這不是我提前估計就能估計得好的，而且我連任務劃分本身都可能是錯的，不過任務劃分是錯的是很正常的事請就是了，一個好的工時估計應該是哪怕出現這種意料之外的情況也不會偏差太多。
總結的來說，就是一句很諷刺性的話，要想做好一個項目，就需要做壞很多項目。希望我以後做壞項目的時候，至少也能交差吧（笑）。