連續三天對八期師弟師妹做的系統進行驗收，雖然我沒有太多的提問和發言，更多的是處於旁聽的角色，聽著七期的提問，聽著七期的發表自己的看法和理解。但是，這次驗收活動確實讓我收穫了不少。
雖然驗收的系統不是我的，改正的錯誤也不是我的，但是我覺得我得到的收穫比他們還要大。
因為我從他們這個階段經歷過，他們犯的錯誤我也犯過，他們疑惑的我也疑惑過。另外，我比他們多一年的學習，雖然這一年裡，好多疑惑依然存在或者疑惑越來越多，但是，當大家在討論這些問題的時候，基本上都能夠產生共鳴，我心裡的疑惑在大家的解答中也漸漸清晰了，有了自己的答案。還有之前覺得模糊的知識點，這次又得到了深入的剖析。
關於這次驗收，不想談具體的技術細節問題，原因上面一段我已經提到，而且，在這次驗收中我們也並沒有針對太多的技術細節，我們是站在軟體開發的角度而不是站在具體實現的角度上給師弟師妹找問題的。
出去工作的同學給我們講述他們公司流程混亂、沒有標準的文件說明、每個人自己幹自己的。而我們觀念中，非常強調文件和建模，**要有一套嚴格的程式設計規範。在合作開發中，要求全部文件驅動，嚴格控制許可權問題。在這些方面，我們細緻到時序圖的生命週期不能搞錯，用例之間的關係不能搞錯……我們把這些視為"法律"。
老師說能夠真正看懂並且可以靈活應用三層架構、設計模式的人並不是很多，當時有點不以為然，今天我又有了點新的看法，就拿我們的程式舉例，雖然實現了三層架構，雖然實現了抽象工廠+反射，但是，三層之間的呼叫在**中如何表現？工廠如果不用反射，那麼**又怎麼寫，圖又該怎麼畫？當你第一次把這些技術實現的時候，你有沒有想過這些問題？當你被問及這些問題時，是不是能夠很快的反應上來？說這麼多，最終還是想說學習這些東西需要自己去理解，在實踐中一次一次應用，而不是別人一下子把正確的都告訴你。這也是公尺老師經常說的話，他也是這樣要求和培養我們的，今天，這些話我又親身體驗了一次，因為那些問題我也是今天第一次想，發現想明白了之後，對這些知識又有了深一層的理解。
前幾天體驗了一下寫簡歷，感觸頗多，在介紹專案技術要點的時候，我費了好半天勁才列出兩條技術要點，想想原因：在做專案的時候把所有的功能看的都一樣，要求也一樣，不管**是否嚴密、是否優化，不管效能問題，只要能夠簡單實現功能就行了。所以，整個程式沒有了主次，自己也很難找出亮點，即使找出了亮點，寫著也心虛，因為並沒有好好對待它，沒有好好實現，只是將就著功能實現了就行了。
想想這幾年好像學了很多很多，**也敲了不少，但是，這才深刻的意識到，我們不能僅僅侷限在**的層次，我們站的角度應該高一點。在以後的專案中一定要注意做到：前期的工作要做充分，實現的時候也不能將就，最後一定要進行測試、部署，整個專案一定要做完整。
以上是個人感受，寫給自己，也給師弟師妹們分享一下。
收費系統的驗收
機房收費系統完成了已經有很長一段時間了，本以為就此結束了。可是，前幾天突然要求對其進行驗收了。開始的時候，感覺驗收就驗收沒什麼。可是，有小道訊息稱，做的不好的有可能重構。如果是因為當初的設計思路或者是邏輯錯誤而重構，那無話可說，必須要重構。但是如果是因為一些注釋 uml圖 命名規範等而重構，都會讓大...
機房收費系統 驗收
自己的機房收費系統開始的算是非常晚的，由於開始的晚。就導致了一件事情。拖。由於開始的時候，搬家。搬學習的地方，然後itoo的專案也開始，事情都堆在一塊兒，然後就做不動了。自己身為組長，突然就感覺到了壓力。以下總結一下自己通過這次機房合作的不足。由於是三個人一起合作。所以就非常自然地每人負責一到兩層。...
機房收費系統 驗收小結
拖拖拉拉好長時間，覺得終於做完了機房收費，但事實證明，專案還要繼續改進ing。在自己做完整體功能之後就找任焱和雅靜讓他們點點，發現問題很多，又接著改了，改完就和 說要驗收專案。就是 點點 就是錯誤。驗收的過程中，發現了很多問題。首先說說，刷卡的問題吧。昨晚一來就問我，你的這個可以刷卡嗎？然後就沒有然...