回想一下你曾經對計算機專業的暢想
當初你是如何做出選擇計算機專業的決定的？經過一個學期，你的看法改變了麼，為什麼？
回答： 最初選擇計算機是因為聯考志願被調劑到軟體工程專業，雖然并不是自己的本意但也沒有換專業的想法。是以最終還是讀了計算機的研究所學生。當然這一決定也得益于這個行業良好的就業前景。現在的想法依然沒有改變，計算機這一專業的前景依然廣闊，我也依然不讨厭這一學科。
你認為過去接觸到的課程是否符合你對計算機專業的期待，為什麼？經過一個學期，你的看法改變了麼，為什麼？
回答：大學階段的課程是更加偏重于理論的，就連考試都不需要程式設計。雖然這與我預想的計算機專業不同但是我卻更喜歡這樣的方式，而大學階段學到的看似無用的理論知識在同學們工作後被證明了确實是有用的。而研究所學生階段的課程，有幾門是與大學有交集的。其中有的授課方式與大學階段無異，比如網絡實驗，有的與大學階段完全不同，比如軟體工程。我認為這些課程都是讓我受益匪淺的。
你覺得計算機是你喜歡的領域嗎，它是你擅長的領域嗎？經過一個學期，你的看法改變了麼，為什麼？
回答：計算機是我喜歡的領域，也應該會成為我喜歡的事業。我不擅長計算機，但是目前在所有領域裡我最擅長的領域是計算機。這一情況經過一學期沒有什麼變化
（2）考取研究所學生，對照前人們走過的路和描述未來發展，現在的你自我感覺你已經具備的專業知識、技能、能力有哪些？
離成為一個合格的計算機學生，在專業知識、技能、能力上還差距哪些？
經過一個學期，你的看法改變了麼，為什麼？
回答：經過一個學期，這一情況沒有什麼改變。我的程式設計能力依然有待提高，同時，将理論知識應用到實際問題的能力還是不夠
（3）每天都是一個人生選擇的十字路口，學術研究、工程項目、社會實踐 (？) ，不同的選擇有不同的努力方向。
對照以上你閱讀的前人們的經曆，你的選擇是什麼？經過一個學期，你的看法改變了麼，為什麼？
在這種選擇下，你認為你相比其他同學來說有何優勢，有何劣勢？經過一個學期，你的看法改變了麼，為什麼？
針對你的選擇，你給自己的本學期的規劃是什麼？經過一個學期，你的看法改變了麼，為什麼？
我的想法是畢業之後進入遊戲公司。因為大學想要進入遊戲公司是非常困難的，是以想要在研究所學生階段達到進入遊戲公司的要求。想要達到這個目的，本學期兩個目标，一個是将C++用的熟一些，第二個是對計算機圖形學有一個比較好的了解。
這樣的選擇并沒有改變，我也在按部就班的朝着這個方向努力。
（4）你對這門課的期待是什麼？
你打算平均每周拿出多少個小時用在這門課上？經過一個學期，你的看法改變了麼，為什麼？
實測結果，每周平均用在本課程上多少小時？
我對這麼課的期待就是将以前學過的軟體工程理論應用于實踐當中（當然也會繼續了解這些理論），比如文檔的編寫以及項目進度的控制和品質控制等，雖然以前這些工作都做過，但是文檔一般都是最後寫，項目進度完全看大家心情，希望這門課能帶來不同的體會。時間上初步估算十個小時左右，具體視項目和工期而定。
可以說這麼課的學習符合了我的期待。總用時是9.35小時
五個問題：
（1）關于軟體工程的目标，為什麼是“足夠好”？
在1.2.4節中提出了 軟體工程的目标是創造“足夠好”的軟體
而我個人認為這對于需求分析的要求會大大提高。因為很多時候使用者并不能全面的表述出自己的需求，這就使得如果隻是做的“足夠好”，到了使用者使用時會變得“沒那麼好”。而在書中第八章需求分析中也提到了要給使用者驚喜的功能，那麼為什麼不将軟體工程的目标定為“盡可能好”呢，即在成本允許的範圍内将使用者可能會提出的需求先行滿足。
經過一學期的學習，我意識到可能足夠好對于一個團隊可能是可以完成的目标，更符合實際。 （2）關于軟體工程師的衡量，如何衡量？
在3.1節中提出了軟體工程師的衡量問題，其中提到 5.實際成果 絕大多數軟體工程師的工作成果都是可以公開的，你參與的産品使用者評價如何？。。。。。。是最重要的評價标準
而我想到了大學答辯的時候，一個阿裡的實習生講了一個他們公司高大上的項目，老師們問他哪一部分是他做的，他說都有參與，結果老師們都不滿意。是以我感覺一個人在團隊中的作用是很難量化的，将他作為最重要的評價标準是否合适。
這個疑問依然存在，以我們的課程舉例，不同的人在本組中貢獻是不一樣的，我們能根據貢獻分來展現貢獻，而實際工作中沒有這樣的分數，那麼以項目來評價軟體工程師的好壞是否合理呢。
（3）關于産品經理的問題，為什麼不同公司的團隊配置不同
在9.1節提到了 微軟通常有專門的産品策劃，他們和市場部門的專職人員一起，負責産品的長期發展和市場推廣
文章隻提了一句産品的問題，卻沒有給出原因。而據我的了解，國内一些網際網路公司例如百度，産品與開發是在同一團隊的，這兩種方式是為了适應不同的開發模型嗎，他們的優劣是什麼？
這個問題依然存在，比如我們小組可以看成是産品與編碼在同一團隊的，而我們認為這樣更便于交流。是以對于産品與開發處在不同團隊的模式不是非常了解。
（4）對于整體的系統開發完成，隻是定期的添加功能與維護，那軟體工程的方法是否還有必要？
這個問題稍微脫離了書本，一個同學在某知名網站負責管理廣告的工作，據他說不僅沒有文檔，甚至連測試也不需要，完成時間也是産品問過他之後定的。雖然這種方式感覺是不好的，但是卻又不會出現太大的問題。
這個問題得到了解決。經過了實踐我們感覺到，哪怕是一小點的修改工作其實都不僅僅是對于個人的，會影響到很多方面，這就需要多方面的溝通與交流。而軟體工程的方法可以提高這一過程的效率。
（5）建構究竟怎樣了解
書名是建構之法，而書中也提到了每日建構的概念，但是對于建構本身的沒有系統的概念，怎樣進行？
依舊沒有很透徹的了解這一概念。
請根據本學期的學習、收獲、困惑，再提出5個問題，可以是讀後不了解的，或者讀後反對的。有求有觀點、有證據或分析。體驗一下，這5個問題，是不是更有深度了 。
（1）在軟體工程中如何處理任務完不成的問題。在學習中我們可以補交，那麼在實際的項目過程中如果出現這樣的現象該怎麼處理
（2）如何保證高效的結對程式設計。兩人共用一台電腦進行程式設計，确實提高了程式設計的準确性，但是也存在思路被隊友限制的情況，如何避免？
（3）在項目程序中，如何保證項目的整體架構不變而不斷加入預期外的功能? 例如很可能使用者提出新需求是目前的架構所不能完成的，該怎樣處理？
（4）如何處理團隊中成員不能或不想承擔應有工作的問題？
（5）真實的項目程序中任務配置設定是怎樣進行的？
回憶整個學期，你有什麼話想對後來的學弟學妹們說。
認真寫部落格，還有git是個好東西。
如果重新來過一次，你打算做哪些（技術上，而不是态度上的）改變－－基于希望得到什麼樣的更好結果，你才希望這樣改變的；更重要的是，你根據什麼估計這些改變會有預期的結果。
在需求分析和架構設計的部分進行改變，使用使用者調查等方式擷取更準确的需求，而不是想着先完成一個可釋出的版本。這樣可以使得架構設計進行的更順利，進而提高效率。如果我們組可以提前分析出需要增加詞庫選擇和歡迎界面的功能，那麼就能夠省去後續的大量的修改時間。
終于我們即将不再是師生。當你結束本課程，你和我就站在同樣的位置上，我将不再基于學校授權和知識、經驗 (年齡？)上的優勢而對你的自由有任何幹擾。除釋出及成績以外，我最後一次行使教師特權: 請問你有什麼要對教師 (我)說的，建議、抱怨、希望……多謝。
希望老師以後的作業要求更加明确。在我的了解中，高效而準确的溝通應該是工程項目中一個有意義的環節，是以清晰的便于學生了解的作業要求或許是第一步，特别是在前幾周。可以考慮在留作業之前找沒有上過這門課的人測試一下看看是否易于了解
總結
代碼總量：711
周平均代碼量：59.25
博文字數：22558
周平均博文字數：1879.8
總用時：9.35小時
