一、First項目位址：https://git.coding.net/yangmx2016011904/First.git
二、問題1:你為什麼選擇計算機專業？你認為你的條件如何？和這些部落客比呢？
既然選擇了遠方 便隻顧風雨兼程
在聯考前，對于未來上什麼大學，去哪個城市上大學，選擇什麼專業...這些問題，我似乎沒什麼特别喜歡的，也沒什麼特别讨厭的。我的内心有着深深的無力感和不知所措。從小到大的按部就班讓我不知道如何選擇，我感受到了未來的不确定性。
與部落格F部落客類似，我也是由于偏科，聯考成績并沒有想象中理想，我也沒有選擇的權利，是以被調劑到了——計算機科學與技術專業。
不如部落格F部落客的“糊裡糊塗”，這個專業并不是我感興趣并且擅長的，從國小到高中學校的計算機課并沒有被重視，是以上大學前，我對計算機的了解并不多，更不用說這個專業。當得知自己的未來可能全部都要與這個專業相關了，我特意上網搜了一下計算機科學與技術。這也是我在上大學前，第一次接觸這個專業。
我認為自己是一個不太聰明的人，适應了被老師灌輸的講課方式自我學習能力也不是很強，初入大學遇到了一些困難，但我還算是個願意努力的人，就像部落格B中郎朗說沒有所謂的興趣，興趣都是練出來的。面對全新的大學我覺得更多的是适應。相比部落客，我沒有大佬般的天賦和高起點，但我有一顆努力上進的心。正如部落格F的部落客，從偏科到找到正确的學習方法、專注地學習專業知識，從社團到公司，未來很美好，我們一直在路上。
問題2：你理想中的大學應該是什麼樣子？
我渴望着這樣一所大學，思想自由開放，學科門類齊全，人們不是純粹為了實用而是因為興趣而去學習，沒有學科界限，不分具體專業，沒有必修課程，随時有各類課程，可以自由聽課，學習氛圍濃厚卻不看重成績，重視全面發展又肯定個人興趣方向與特長，除了品格與思想培養不強求學生學習哪一科課程，各類大師彙聚，精英雲集，談天說地，無所限制，不否定每一個人，不否定思想。
在我眼裡，理想的大學是遇見幾個志同道合的朋友，能有一個自由開放的環境，能灑脫不羁的活出自我的地方。
在學我想學的東西，看我喜歡的書，在畫我喜歡的畫，在睡覺前對第二天充滿期待，而不是為了績點忘記享受我的18歲。
問題3：對于你未來在IT行業的發展，你有什麼樣的夢想或者未來想從事什麼樣的工作？你準備怎樣來規劃你技術道路，職業道路和社會道路？
對于我未來的發展，從我小時候的心願來說就是成為一名老師，最好的就是能成為一名大學老師，我喜歡學校裡的氛圍，也喜歡能一直和有活力的年輕人們待在一起。
是以我目前對自己的規劃就是認認真真，仔仔細細地學好學校開設的課程，并盡早為考研做準備，同時多看書，多積累。我認為積累是極其重要的。很多部落格都分享了很多經驗，我認為對我很有幫助。我曾經看過這樣一段話“珍惜每一個生命階段。每一個人的生活都是精彩的，沒有必要厚此薄彼，也沒有必要給自己太多的打擊。每個人獨立地擁有時間，也許我很笨，也許我很窮，是以我需要花費比别人更多的寶貴時間，僅此而已，我要的是——享受過程。”每個人的生命都很短，我們的大學生活更是轉瞬即逝。。是以我希望自己在以後的日子裡，踏踏實實做好眼前的每一件事，能一點一點進步，享受努力的過程。
三、關于《建構之法》的思考
第1章
“什麼是好的軟體，一些同學認為，所謂好軟體，就是軟體沒有缺陷（bug），所謂軟體工程就是把軟體中的bug都消滅的過程。這的确抓住了軟體工程的一個要素”看到這，引發了我的思考，到底怎樣的軟體是好的軟體？雖然内心裡認為有無bug不能作為唯一标準，但在一些軟體測試中這一項确實是占比不小的衡量标準。我也通過百度得知了衡量軟體品質的5個最常用的名額：SLOC（源代碼行，可以使用Metrics工具來統計）；每個代碼段/子產品/時間段中的bug數；代碼覆寫率（單元測試階段考慮）；設計/開發限制（可維護性，可讀性）；圈複雜度（用來衡量一個子產品判定結構的複雜程度，已經成為評估軟體品質的一個重要标準，能幫助開發者識别難于測試和維護的子產品，在成本、進度和性能之間尋求平衡。圈複雜度可以使用pmd工具來自動化計算。）我認為不能過分強調bug數和軟體好壞的關系。
第2章
通過代入“小飛”的經曆，老師講解了用VSTS來寫單元測試，同時也通過小飛和阿超之口向我們傳達了單元測試的重要性。之後又對好的單元測試标準和回歸測試進行了講解。之後我又了解了效能分析工具和兩種分析方法，抽樣和代碼注入，知道了要“先用抽樣的方法找到效能瓶頸所在，然後對特定的子產品用代碼注入的方式進行詳細分析”，接下來對個人開發流程做了叙述，進而提出來PSP模型，但在我看來，這樣的流程可能就适合那種大佬，能夠把握自己做好每一項的時間和花費，而對于一些初出茅廬者并不太适用。同時PSP是依賴于資料的而且是需要工程師輸入資料，會不會有些麻煩？
第4章
在本章老師提出來不間斷地複審，“結對程式設計讓兩個人所寫的代碼不斷地處于“複審”的過程，程式員們能夠不斷地稽核，提高設計和程式設計品質，可以及時發現并解決問題，避免把問題拖到後面的階段”，但我想這樣的複審，會不會雙方都不太了解彼此的程式，同時如果複審效果不好也可能會影響團隊進度。同樣結對程式設計中如果雙方都不認可對方的看法僵持不下，是不是對工作的進度更加不利？
第7章
章節7提到成員授權和信任問題。如果在實際開發中，當項目開始前所信任的有能力幹活的人中途離開了或者在開發過程中這個人遇到技術難題，長時間未解決，其他成員對這個人産生能力質疑時，如何解決這個問題？
第16章
看書本的16章時覺得這章的内容輕松有趣，在有很強的故事性的同時，也蘊含了很多使我們受益的想法。“不要一開始就想着找到并拼對所有的拼圖塊，以為能夠打造一個巨大的創新。”對于這句話我很認同，過于追求結果隻會使事不如人願。一步一步，不急不躁，踏實穩步的走，你會發現，走着走着，你想看到的一切風景，盡在你眼前。但現在這個社會，很多事情都追求一個實效性，而又很多時候過于追求時間上的需求而忽略了品質，怎樣能做到二者的平衡呢？