1） 回歸第一周目標
對于第一周的目標，在提高代碼量，多寫多練方面達到了，之前結點編程時還不是很熟悉python，現在寫的比較熟練了，同時學習了一門新的語言Julia，在學習的過程中也看了Julia和Flux的一些源碼。之前比較不注意個人代碼規范，在團隊項目中被強行規范了。
2） 快速瀏覽《構建之法》的問題
在結對編程中，因為有隨時的復審和交流，程序各方面的質量取決于一對程序員中各方面水平較高的那一位。這樣，程序中的錯誤就會少很多，程序的初始質量會高很多，這樣會省下很多以后修改、測試的時間。
結對編程是個漸進的過程，有效率的結對編程不是一天就能做到的。
在做結對編程的項目中，我體會到了結對編程的優點，雖然剛開始對python代碼隊友比較熟悉，但是結對編程的時候我也能比較細致的找到bug，比一個人效率高，同時也是相互學習的過程，對于小而精的項目我覺得結對編程挺好的，從長期來看，成員互相提高，也能提高團隊的效率。
軟件在發展過程中用戶需求是變化的，用戶的數量和多樣性也在增長，這時候我們是否應該重新定義我們的典型用戶？
是的，雖然軟件不是為所有人服務的，但是有了新的典型用戶之后我們也應該根據新的需求增加對應的功能。
用網站當前的用戶做實驗，萬一引起巨大的反感，用戶就真的流失了。
如果用戶體驗反饋比較準確，那么測試用戶的數量要大，來源是我們的真實用戶，這樣就存在文中的問題，那我們怎么把這種測試的風險降低呢？
在課上討論過，我認為不能把測試的工作全部寄托于用戶的測試，應該有專門的測試人員來保證質量，然后再去軟件的“死忠粉”用戶中測試，最后穩定了推廣。
平時的時候負載不是很大，而在一些特定的時間，比如雙十一等等負載急劇增大，在設計的時候是否有必要考慮這種負載？
我現在覺得我提的這個問題是沒有意義的，既然考慮到了為什么不做呢....
成功的團隊更能創新 我不能完全贊同這句話。我認為小公司創新難，首先小公司資源比大公司少，其次員工每天花在例行的瑣事/工作上的時間多(人少),那么花在思考如何創新的時間少，再者，顛> 覆性的創新會帶來產品和市場的巨大風險，小公司沒有承受這種風險的能力，和用戶基礎。
這個問題只是我自己的一點思考....可能大公司會有更多的包袱，這個我覺得沒有定論....
4）“事后諸葛亮”分析的感想
最大的感想是做一個項目或者事情之前要想清楚自己的目標是什么(或者用戶的需求是什么)，怎么定義問題，定義明確的完成指標，不然到最后會陷入迷茫用力用錯方向，比如julia項目后期....
5）對比一些技能評價表，你有什么提高？ 還有什么收獲是不能用數字衡量的？
代碼能力和規范方面的提高，以及代碼的設計。還有的收獲就是團隊合作的能力和經驗（失敗的教訓....）是不能衡量的。
6）設想一年之后， 你到了你職業發展的下一個階段（高年級， 讀研，工作），回頭看這門課， 你對于這門課的教學方法， 老師和助教的工作，和其他課程的銜接，有什么意見和建議？
我覺得感觸最深的就是團隊項目真實的體驗了在公司做項目會有怎樣的流程，另外我覺得做團隊項目之前，要求每個團隊指定 清晰的目標/面向的典型用戶/需求/可量化的完成指標/團隊貢獻/代碼規范等等寫成文檔放在github里面，最后評價的時候就展示這個并答辯，其實這個過程老師帶我們在課堂上做過，有一部分也要求寫在團隊博客里了，很大一部分是我們沒有徹底執行的鍋。。。
)
