1） 回歸第一周目標
對於第一周的目標，在提高**量，多寫多練方面達到了，之前結點程式設計時還不是很熟悉python，現在寫的比較熟練了，同時學習了一門新的語言julia，在學習的過程中也看了julia和flux的一些原始碼。之前比較不注意個人**規範，在團隊專案中被強行規範了。
2） 快速瀏覽《構建之法》的問題
在結對程式設計中，因為有隨時的複審和交流，程式各方面的質量取決於一對程式設計師中各方面水平較高的那一位。這樣，程式中的錯誤就會少很多，程式的初始質量會高很多，這樣會省下很多以後修改、測試的時間。在做結對程式設計的專案中，我體會到了結對程式設計的優點，雖然剛開始對python**隊友比較熟悉，但是結對程式設計的時候我也能比較細緻的找到bug，比乙個人效率高，同時也是相互學習的過程，對於小而精的專案我覺得結對程式設計挺好的，從長期來看，成員互相提高，也能提高團隊的效率。結對程式設計是個漸進的過程，有效率的結對程式設計不是一天就能做到的。
軟體在發展過程中使用者需求是變化的，使用者的數量和多樣性也在增長，這時候我們是否應該重新定義我們的典型使用者？是的，雖然軟體不是為所有人服務的，但是有了新的典型使用者之後我們也應該根據新的需求增加對應的功能。
用**當前的使用者做實驗，萬一引起巨大的反感，使用者就真的流失了。在課上討論過，我認為不能把測試的工作全部寄託於使用者的測試，應該有專門的測試人員來保證質量，然後再去軟體的「死忠粉」使用者中測試，最後穩定了推廣。如果使用者體驗反饋比較準確，那麼測試使用者的數量要大，**是我們的真實使用者，這樣就存在文中的問題，那我們怎麼把這種測試的風險降低呢？
平時的時候負載不是很大，而在一些特定的時間，比如雙十一等等負載急劇增大，在設計的時候是否有必要考慮這種負載？我現在覺得我提的這個問題是沒有意義的，既然考慮到了為什麼不做呢....
成功的團隊更能創新 我不能完全贊同這句話。我認為小公司創新難，首先小公司資源比大公司少，其次員工每天花在例行的瑣事/工作上的時間多(人少),那麼花在思考如何創新的時間少，再者，顛》 覆性的創新會帶來產品和市場的巨大風險，小公司沒有承受這種風險的能力，和使用者基礎。這個問題只是我自己的一點思考....可能大公司會有更多的包袱，這個我覺得沒有定論....
4）「事後諸葛亮」分析的感想
最大的感想是做乙個專案或者事情之前要想清楚自己的目標是什麼(或者使用者的需求是什麼)，怎麼定義問題，定義明確的完成指標，不然到最後會陷入迷茫用力用錯方向，比如julia專案後期....
5）對比一些技能評價表，你有什麼提高？ 還有什麼收穫是不能用數字衡量的？
**能力和規範方面的提高，以及**的設計。還有的收穫就是團隊合作的能力和經驗（失敗的教訓....）是不能衡量的。
6）設想一年之後， 你到了你職業發展的下乙個階段（高年級， 讀研，工作），回頭看這門課， 你對於這門課的教學方法， 老師和助教的工作，和其他課程的銜接，有什麼意見和建議？
我覺得感觸最深的就是團隊專案真實的體驗了在公司做專案會有怎樣的流程，另外我覺得做團隊專案之前，要求每個團隊指定 清晰的目標/面向的典型使用者/需求/可量化的完成指標/團隊貢獻/**規範等等寫成文件放在github裡面，最後評價的時候就展示這個並答辯，其實這個過程老師帶我們在課堂上做過，有一部分也要求寫在團隊部落格裡了，很大一部分是我們沒有徹底執行的鍋。。。
年前假期學習最後一周學習總結
今天是2019 1 27 星期日 昨天忙著做手頭的專案沒有及時去更新最近一周的學習總結。在這一周裡面我每天都在把堆積在我手頭裡的乙個專案給趕緊完成，因為這個專案耽擱的時間有點久了，以至於之前寫的什麼還要重新去理解，儘管 有注釋，但是要很快的去理解還是有點困難的，所以，以後做事情一定要認真對待。學習上...
現代軟體工程 作業 最後一周總結
軟體工程作業彙總 1 回顧你的課程計畫 第一周的計畫 你完成的程度如何？請列出具體資料和實際例子 2 你在課程開始快速瀏覽了 構建之法 提了 5 個問題，請回顧那些問題，自己回答它們。如果不能回答，為何軟體工程課不能讓你回答這些問題？我們在學生開始上課的時候給學生創造了乙個 必要困難 參見 必要困難...
最後一周 銀行儲蓄系統
我學的並不好。好不容易看懂老賀的參考 加分的專案在多次嘗試下感覺有點弄巧成拙，錯誤百出。突然在這時想到了大話西遊裡至尊寶的那段自白，現在也許是內心最真實的寫照。main.cpp include include bank.h using namespace std int main return 0 ...