一個學期我真的不覺得我們學生能夠做出什麼很好的軟體，不過我覺得這門課程倒是培養了我們學生對軟體開發的興趣，清楚了軟體開發的整個流程，積累了經驗，增強了學習的熱情（如果認真對待這門課程，以上幾點是理所應當的）。

在開發過程中能夠一路順風也真是難得，但是對於那些前臺加上資料庫以及很簡單的後臺支援就能做出來很精美的軟體當然讓人看上去很滿意，但是對於那些偏向於後臺的程式開發者來說有點太不公平了，沒有很多精美的介面，但是花了很多很多的時間，踩到了很多的地雷，需要一個一個小心翼翼的拆（還需要反覆確認是否拆除成功了，是否還會“爆炸”），同樣花費了很多的時間，甚至比很多組花的時間更多，卻被定為沒有認真對待課程(小小的抱怨一波　　程式設計師命苦哇┭┮﹏┭┮）。

　　作為學生，我覺的有一點是老師只能望其項背的，那就是對於學習，對待這門課程，以及對知識的渴求以及迫切的希望能夠通過這個專案來證明我們自己的實力，簡而言之就是passion。在大人們的世界裡，這種對知識的純粹的喜愛（passion）可能早就已經被世俗磨平，沖刷殆盡了，只留下滿目瘡痍的殘骸，又或者是功利性的去做某些事情。雖然我們所學的知識有限，還只是一種半杯水的狀態，但是卻具有十足的自我優越感，這又有何不可呢，遇到BUG了拼命解，解的越多，學到的越多，慢慢的一點點進步。這門課程有一個很難被其他課程替代的部分就是從錯誤中學習嘛，那些領域的牛人不都是通過在實踐中累積知識，慢慢成長起來的嘛。不過一般的牛人都是很謙虛的,見識多了、眼界寬廣了、自己犯的錯誤多了（可以理解為出現的BUG很多，這和你的工作量、程式碼量應該是成正比的），就會積累經驗，總結教訓，從中成長，慢慢地學會低調做人。

身為PM，做完專案，總結自己踩到的雷，發現加在一起比威力不亞於原子彈

使用c++，踩得最多的坑就是指標了。
個人認為最噁心的bug大多都是指標帶來的，這也是為什麼c語言被詬病的主要原因之一。就算你知道這個BUG是指標帶來的，你都不一定能夠找得出，就問你氣不氣-。-

這些bug編譯一般都能通過，無論多麼完美的工業級編譯器，或者使用怎樣的輔助工具，都很難自動幫我們發現這種錯誤。
因此當我們愉快的執行程式時，就會發現各種執行異常(個人認為最噁心，最難解的bug，不接受反駁(:－))

我總結了一下在開發過程中遇到的種種難題 ，希望對你有幫助（可能整理的優點重複）:

1、靈活的指標給我們帶來的痛苦

（傳送門--->>>）
https://www.cnblogs.com/xwmcc/p/10174998.html

https://www.cnblogs.com/xwmcc/p/10107626.html

https://www.cnblogs.com/xwmcc/p/10033706.html

2、框架的優缺點
（傳送門--->>>）

https://www.cnblogs.com/xwmcc/p/10033706.html

3、程式的功能紊亂 （意想不到的執行結果？  資料不同步帶來的問題？）

       說白了，設計者真的能夠完美的做到資料同步的話，那些記憶體訪問衝突，野指標什麼的問題基本上都迎刃而解了，因為記憶體衝突一般都是非法記憶體訪問，也就是訪問到不屬於程式的記憶體，這不就是因為物件被提前釋放或者根本沒有被建立嘛，但是設計者這個時候就是不知道這個要訪問的資料不存在，在設計者的腦海裡，資料沒有“同步”。當然這只是一個狹隘的說法，還有很多種程式裡面的資料不同步造成的問題以及意外的程式功能。

       （傳送門--->>>）

       https://www.cnblogs.com/xwmcc/p/10174998.html        

4、虛擬函式過載繼承問題

（傳送門--->>>）

https://www.cnblogs.com/xwmcc/p/10030934.html