第0次做業

1、First項目地址：https://git.coding.net/yangmx2016011904/First.git

2、問題1:你爲何選擇計算機專業？你認爲你的條件如何？和這些博主比呢？

既然選擇了遠方 便只顧風雨兼程

    在高考前，對於將來上什麼大學，去哪一個城市上大學，選擇什麼專業...這些問題，我彷佛沒什麼特別喜歡的，也沒什麼特別討厭的。個人心裏有着深深的無力感和不知所措。從小到大的循序漸進讓我不知道如何選擇，我感覺到了將來的不肯定性。

    與博客F博主相似，我也是因爲偏科，高考成績並無想象中理想，我也沒有選擇的權利，所以被調劑到了——計算機科學與技術專業。

    不如博客F博主的「糊里糊塗」，這個專業並非我感興趣而且擅長的，從小學到高中學校的計算機課並無被重視，因此上大學前，我對計算機的瞭解並很少，更不用說這個專業。當得知本身的將來可能所有都要與這個專業相關了，我特地上網搜了一下計算機科學與技術。這也是我在上大學前，第一次接觸這個專業。

    我認爲本身是一個不太聰明的人，適應了被老師灌輸的講課方式自我學習能力也不是很強，初入大學遇到了一些困難，但我還算是個願意努力的人，就像博客B中郎朗說沒有所謂的興趣，興趣都是練出來的。面對全新的大學我以爲更多的是適應。相比博主，我沒有大佬般的天賦和高起點，但我有一顆努力上進的心。正如博客F的博主，從偏科到找到正確的學習方法、專一地學習專業知識，從社團到公司，將來很美好，咱們一直在路上。

問題2：你理想中的大學應該是什麼樣子？

       我渴望着這樣一所大學，思想自由開放，學科門類齊全，人們不是純粹爲了實用而是由於興趣而去學習，沒有學科界限，不分具體專業，沒有必修課程，隨時有各種課程，能夠自由聽課，學習氛圍濃厚卻不看重成績，重視全面發展又確定我的興趣方向與特長，除了品格與思想培養不強求學生學習哪一科課程，各種大師匯聚，精英雲集，談天說地，無所限制，不否認每個人，不否認思想。

       在我眼裏，理想的大學是碰見幾個志同道合的朋友，能有一個自由開放的環境，能灑脫不羈的活出自個人地方。

    在學我想學的東西，看我喜歡的書，在畫我喜歡的畫，在睡覺前對次日充滿期待，而不是爲了績點忘記享受個人18歲。

問題3：對於你將來在IT行業的發展，你有什麼樣的夢想或者將來想從事什麼樣的工做？你準備怎樣來規劃你技術道路，職業道路和社會道路？

　　對於我將來的發展，從我小時候的心願來講就是成爲一名老師，最好的就是能成爲一名大學老師，我喜歡學校裏的氛圍，也喜歡能一直和有活力的年輕人們待在一塊兒。

       因此我目前對本身的規劃就是認認真真，仔仔細細地學好學校開設的課程，並儘早爲考研作準備，同時多看書，多積累。我認爲積累是極其重要的。不少博客都分享了不少經驗，我認爲對我頗有幫助。我曾經看過這樣一段話「珍惜每個生命階段。每個人的生活都是精彩的，沒有必要厚此薄彼，也沒有必要給本身太多的打擊。每一個人獨立地擁有時間，也許我很笨，也許我很窮，因此我須要花費比別人更多的寶貴時間，僅此而已，我要的是——享受過程。」每一個人的生命都很短，咱們的大學生活更是轉瞬即逝。。因此我但願本身在之後的日子裏，踏踏實實作好眼前的每一件事，能一點一點進步，享受努力的過程。

3、關於《構建之法》的思考

第1章

       「什麼是好的軟件，一些同窗認爲，所謂好軟件，就是軟件沒有缺陷（bug），所謂軟件工程就是把軟件中的bug都消滅的過程。這的確抓住了軟件工程的一個要素」看到這，引起了個人思考，到底怎樣的軟件是好的軟件？雖然心裏裏認爲有無bug不能做爲惟一標準，但在一些軟件測試中這一項確實是佔比不小的衡量標準。我也經過百度得知了衡量軟件質量的5個最經常使用的指標：SLOC（源代碼行，可使用Metrics工具來統計）；每一個代碼段/模塊/時間段中的bug數；代碼覆蓋率（單元測試階段考慮）；設計/開發約束（可維護性，可讀性）；圈複雜度（用來衡量一個模塊斷定結構的複雜程度，已經成爲評估軟件質量的一個重要標準，能幫助開發者識別難於測試和維護的模塊，在成本、進度和性能之間尋求平衡。圈複雜度可使用pmd工具來自動化計算。）我認爲不能過度強調bug數和軟件好壞的關係。

第2章

　  經過代入「小飛」的經歷，老師講解了用VSTS來寫單元測試，同時也經過小飛和阿超之口向咱們傳達了單元測試的重要性。以後又對好的單元測試標準和迴歸測試進行了講解。以後我又瞭解了效能分析工具和兩種分析方法，抽樣和代碼注入，知道了要「先用抽樣的方法找到效能瓶頸所在，而後對特定的模塊用代碼注入的方式進行詳細分析」，接下來對我的開發流程作了敘述，從而提出來PSP模型，但在我看來，這樣的流程可能就適合那種大佬，可以把握本身作好每一項的時間和花費，而對於一些初出茅廬者並不太適用。同時PSP是依賴於數據的並且是須要工程師輸入數據，會不會有些麻煩？

第4章

    在本章老師提出來不間斷地複審，「結對編程讓兩我的所寫的代碼不斷地處於「複審」的過程，程序員們可以不斷地審覈，提升設計和編程質量，能夠及時發現並解決問題，避免把問題拖到後面的階段」，但我想這樣的複審，會不會雙方都不太瞭解彼此的程序，同時若是複審效果很差也可能會影響團隊進度。一樣結對編程中若是雙方都不承認對方的見解僵持不下，是否是對工做的進度更加不利？

第7章

    章節7提到成員受權和信任問題。若是在實際開發中，當項目開始前所信任的有能力幹活的人中途離開了或者在開發過程當中這我的遇到技術難題，長時間未解決，其餘成員對這我的產生能力質疑時，如何解決這個問題？

第16章

    看書本的16章時以爲這章的內容輕鬆有趣，在有很強的故事性的同時，也蘊含了不少使咱們受益的想法。「不要一開始就想着找到並拼對全部的拼圖塊，覺得可以打造一個巨大的創新。」對於這句話我很認同，過於追求結果只會使事不如人願。一步一步，不急不躁，踏實穩步的走，你會發現，走着走着，你想看到的一切風景，盡在你眼前。但如今這個社會，不少事情都追求一個實效性，而又不少時候過於追求時間上的需求而忽略了質量，怎樣能作到兩者的平衡呢？