《構建之法》閱讀-第一次做業

構建之法第一次做業

做業屬於的課程：https://edu.cnblogs.com/campus/xnsy/2019autumnsystemanalysisanddesign

做業的要求：http://www.javashuo.com/article/p-awxmclqg-dw.html

我在這個課程的目標：

（1）系統分析做爲咱們專業的核心必修課程，其在軟件組織中，分析與設計的做用是舉足輕重的。本身也是但願利用這門課程，把大1、大二兩個學年所學到的在軟件開發過程當中最重要的一些核心思想、設計模式等方面的知識貫穿起來，使本身可以有一個更加完整的知識體系結構，深入對軟件工程的理解。

（2）不管從提高本身的專業動手能力，仍是爲得到一個更高的分數。本身都應該認真高質量的完成每一次的做業。本身也感受到每一次的做業設計的都很合理。特別是團隊和我的項目時，應該利用所學的理論，從相反方面加以討論軟件系統分析與設計的方法、流程、工具與文檔。實現從理論和實踐兩方面的能力同時提高。

這個做業在哪一個具體方面幫助我實現目標：

本次做業針對性對博客園優秀的博文和教材進行了大量閱讀，也使本身對軟件工程這門課程和博客園這個工具備了一個更深刻的認識。同時也是第一次在博客園寫文章，接下來的日子也會利用好這門課程的每一次做業和博客園的豐富文章來極大的豐富和完善本身的知識體系。

1、 創建博客並介紹本身

本身的博客地址：https://www.cnblogs.com/Slow-Walker/

自我介紹：

我叫王柄鈔，是來自2017級軟件工程卓越班普通程序員一枚，愛好登山、打籃球、喜歡處處陪「girl」一塊兒吃吃逛逛。本身認爲本身動手能力仍是不錯，追求突破和解決困難問題以後的成就感，遇事可以比較成熟穩重思考以後再作決定，可以吃苦、勇於挑戰，記得曾經作的一個比賽，大概熬了一個月的通宵原本是不可能完成的項目，最終提交做品的時候仍是作出了比較滿意的做品也取得了意想不到的成績。有些時候總以爲本身學東西老是比人家慢了一個節拍同樣，可是相信本身只要可以持續性的努力就必定不會比人家差，正如本身的博客名Slow-Walker，I’ am slow-walker ,But I never walk backwards.

2、 閱讀與思考

（1）回想一下你初入大學時對你所在專業的暢想

當初你是如何作出選擇你所在專業的決定的？

回首兩年前選專業的場景，其實那個時候本身對計算機這個行業不是很瞭解，也僅僅就知道他在將來就業還很是好，對於咱們這種家庭沒有特別厚的背景的人學計算機可以經過本身的能力，走出屬於本身的一片天地。模模糊糊就選了這個專業，從大學進來的時候本身想着，本身在大學裏面必定要好好學，由於這專業學好了本身可以憑藉本身的技術去創業開公司。

 

你認爲過去一（兩）年中接觸到的課程是否符合你對你本身所在專業的期待，爲何？

在過去兩年裏本身接觸和學習的東西主要來自兩個方面，第一個就是學校開始的課程的學習，第二個就是來自本身閱覽和看的視頻所學的感興趣的方向的知識。都比較滿意本身在剛剛大一之處對本身這兩年的規劃，惟一還有點不足的是本身學習的知識仍是比較零散，也但願經過本身這一年的學習鞏固和增強豐富本身轉也課程體系。

 

你以爲你所在的專業是你喜歡的領域嗎，它是你擅長的領域嗎？

自我感受軟件工程學生將來有不少發展方向，所以針對本身也選了一個本身的將來發展方向，我喜歡大數據領域，我相信本身經過這三年一直朝着這個目標前進，不斷曾強本身在這方面的知識，相信到即將大三結束工做面試活動研究生面試都能取得本身一個較滿意的結果。

 

未來你會選擇從事和你專業相關的工做嗎？是的話給出你想去的城市、公司和崗位，否的話給出緣由

未來的我會選擇從事如今所學專業的工做，固然想去的城市可以留在成都固然也是挺不錯的，公司的話仍是但願本身起初實習以及起初正式工做不該該只看中眼前的工資，而應該考慮將來五年深知十年的薪水，因此起初應該本着對將來學習和發展更有幫助的公司去上班。指望的固然仍是BAT這種大公司，崗位仍是想作大數據研發這一塊，大數據架構。

（2）對照前人們走過的路和描述將來發展，如今的你

自我感受你已經具有的專業知識、技能、能力有哪些？已經寫過的代碼量是多少？描述你作的最複雜的項目/做業。

自我感受本身以及具有基本的c、c#、java、python、PHP基本的程序設計能力，可以熟練的使用MySQL數據庫，對面向對象、設計模式有比較深入的認識。本身寫過的代碼量至少應該有3萬行+，本身作過最複雜的項目印象最深入的有兩個。

第一個就是石工設計大賽給斯倫貝謝公司作的一個petrel插件，其實在開發這個插件業務不是很複雜，難的就是他的開發框架要用他本身的ocean框架是集成在vs裏面的。遇到的最大的困難就是要去學習這些全英文開發文檔，要去明白他的數據域以及數據結構是怎麼樣的。從項目啓動到結束持續性的花費了一個月的時間，基本上天天最先睡覺也是兩點。但最後仍是取得了一個滿意的成績。最終在這個過程提高的是本身的一個快速學習和克服問題解決問題的能力，使本身在將來開發過程當中有了更加向前的動力。

 

離成爲一個合格的本科畢業生，在專業知識、技能、能力上還差距哪些？

其實針對本身如今像一個合格的本科生出去工做的話，本身專業知識上也主要差在本身學的東西還很零散，基礎不夠紮實，不能融會貫通，動手能力上還有待增強。在與人溝通協做的技能上還有必定的差距，特別是在編碼這一塊，自我感受一個真正合格計算機本科畢業生，本科畢業至少也得應該有10萬+行代碼量，也正是須要這樣的代碼量的不斷練習咱們學的知識，才能豐富和融會貫通，使得咱們的知識體系結構更加完整，才能在寫代碼的過程當中不斷改進，提高代碼質量，我想這也是有些人能進一些大廠，然而有些人也只能進一些小公司的緣由所在。

（3）目前是一我的生選擇的十字路口，考研、工做、考公、出國，不一樣的選擇在大三就有不一樣的努力方向。而不管考研仍是工做的每條路徑，也有許多不一樣的分支。

對照以上你閱讀的前人們的經歷，你的選擇是什麼？

針對在老師們列出的優秀博文，其實他們不少都講了一個共同的特色就是剛剛開始也比較菜，可是本身不肯意待在溫馨的環境，都是經過一次次失敗一次次前進，並在這個過程當中厚積薄發，最終達到了本身既定的目標。一樣，本身的選擇也是，我也首先會選擇考取研究生，想經過這樣一個平臺不斷提高本身的能力，再到後面工做的時候本身應該起步五年應該主要沉下心來厚積薄發，後面五年到十年纔會實現由量變到質變的一個過程。

 

在這種選擇下，你認爲你相比其餘同窗來講有何優點，有何劣勢？

優點的話主要是經過本身更高水平的研究生學習，相信本身將來的起點必定會比人家高，本身的將來對事物的認知水平也會有更加不一樣的高度。劣勢就是相比於同齡進入社會的人，本身晚出去三年，也許到本身畢業的時候人家已是有很強經驗的項目經理了。

 

針對你的選擇，你給本身的大三設定的規劃安排是什麼？

設定的目標，努力學好本身的課程，將本身的績點有所提高，更加完善本身的動手能力和豐富本身的專業知識結構體系。爭取把六級過了，爭取可以有一篇儘可能高一點水平的文章和一張含金量較高的國獎。

 

你對於實現本身的夢想已經作了或者計劃作什麼樣的準備？

所作的計劃，首先就是天天認真按照本身的規定計劃完成當天的英語學習，其次將來提高代碼量和成績本身努力完成每一次老師課後佈置的做業，並上課積極與老師交流互動。針對課後，本身也正在準備參加數學建模國賽，以及後期的泰迪杯，以及主動學習相關的研究，相信本身可以在大三關鍵的一年多出一些成果。

3、提有質量的問題

針對性閱讀以後的羅列的本書邏輯目錄：

 

第一章 概論

大馬哈魚洄游模型

程序數據結構算法 軟件程序軟件工程

軟件工程定義

軟件工程三步曲

 

第二章 我的技術和流程

單元測試

我的開發流程

 

第三章 軟件工程師的成長

我的能力的衡量與發展

初級軟件工程師成長階段

軟件開發的工做量和質量的衡量標準

軟件工程師的職業發展

 

第四章 兩人合做

代碼規範

代碼風格規範

代碼設計規範

代碼複審

結對編程

 

第五章 團隊和流程

寫了再改模式Code-and-Fix

瀑布模型Waterfall Model

瀑布模型的各類變形

Rational Unified Process統一流程RUP

老闆驅動的流程Boss-Driven Process

漸進交付的流程Evolutionary DeliveryMVP和MBP

 

第六章 敏捷流程

敏捷的流程

敏捷流程的問題和解法

敏捷的團隊

敏捷總結

敏捷的問答

 

第七章 MSF

MSF 簡史

MSF基本原則

MSF團隊模型

MSF過程模型

MSF敏捷開發模式

MSF CMMI開發模式

 

第八章 需求分析

 

軟件需求

軟件產品的利益相關者

獲取用戶需求用戶調查

競爭性需求分析的框架 NABCD模型

功能的定位和優先級

計劃和估計

分而治之Work Breakdown Structure

 

第九章 項目經理

PM 是啥

微軟PM的來歷

PM作開發和測試以外的全部事情

PM 和風險管理

PM 的能力要求和任務

在一個項目中PM的具體任務

 

第十章 典型用戶和場景

典型用戶和典型場景

用例Use Case

規格說明書

功能驅動的設計

 

第十一章 軟件設計與實現

分析和設計方法

圖形建模和分析方法

其餘設計方法

從Spec到實現

開發階段的平常管理

 

第十二章 用戶體驗

用戶體驗的要素

用戶體驗設計的步驟和目標

評價標準

 

第十三章 軟件測試

基本名詞解釋及分類

各類測試方法

實戰中的測試

 

第十四章 質量保證

軟件的質量

軟件的質量保障工做

 

第十五章 穩定和發佈階段

從代碼完成到發佈

不一樣頻率和不一樣覆蓋範圍的漸進發布

發佈以後過後諸葛亮會議

 

第十六章 IT行業的創新

創新的迷思

創新的時機

創新的招數

魔方的創新

最後針對性的章節提出問題：

問題1、

針對第二章中單元測試的學習，對以前寫過的一些程序試了一下更加深單元測試的理解，以前對這個沒什麼概念寫代碼就只管寫代碼了。也理解到了本身在寫單元測試時應該要跟軟件同步更新，而且單元測試要覆蓋全部代碼路徑，單元測試能夠把咱們的軟件能作的不能作的事都在「單元」中表達出來。而且也感覺到了有單元測試的話後期出現的bug修復起來也比很容易。

針對本身的寫的一個測試本身暑假寫的java代碼，感覺到單元測試的一個重要標準就是保持每一個測試的孤立性，即只測試本方法內的邏輯，若是遇到其它模塊或其它藉口的調用，則儘可能使用mock object來代替，在實際測試過程當中，若是一個類A中的一個方法須要調用到接口B、C、D、E、F、G（或更多）接口的時候，一般的作法，也是junit框架推薦的作法是將這些其它接口經過參數傳遞的方式供A使用，但這樣形成的最直接後果就是A方法中的參數過多，代碼難以維護且不美觀，可能有些得不償失。

然而過程當中也遇到的問題，怎麼保持單元測試的孤立性呢，並且存在的問題還有就是，假如測試方法中的參數過多就會形成在被測試方法業務邏輯複雜，並且會頻繁調用其它接口，如何減小參數呢？

問題2、

針對第六章的敏捷開發的整個流程和疑惑，敏捷開發的路程，我的覺的若是可以掌控好開發的流程和節點，及時的瞭解進度與遇到的問題，及時發現可能隱患的延時問題，就能掌控好開發的流程了；針對於複雜的開發確實頗有用，回想以前本身開發的幾個程序，只是簡單的執行，使用敏捷開發並不適用，簡單的東西也許敏捷反而不敏捷了；

回頭先以前的開發過程，也都感受使用了裏面的部分路程，本身最後總結的流程，首先是，快速的竟品分析。對市面上的同類竟品進行深刻的分析，提煉出產品框架，分析對比各竟品的優缺點，去其糟粕，取其精華。其次對用戶行爲數據分析。經過問卷，訪談等調查用戶使用此類產品遇到的問題，收集反饋意見。再經過設計多套概念產品方案。設計產品框架，主要任務流程，最初能夠設計多套交互方案，最後評審選出最優方案。再快速的視覺實現。定義產品主色和輔助色系，快速在一個典型的界面上進行多套方案的嘗試，經過簡單的用戶測試，決定出符合用戶預期的風格方案。最終高效配合，敏捷開發。技術人員根據交互原型和典型界面的視覺方案進行技術儲備和框架搭建，最後對各模塊精細化實現，最後產品上線。

問題3、

在本書的第11章，我看了這一段文字「小飛：你是說構建就像是運球、傳球。。。」，對於代碼重構不是很清楚。我查了資料，基本上都是在強調重構的好處優勢，重構就是軟件產品最初製造出來，具備良好架構。因爲隨着時間的發展，需求發生變化，爲了實現達到軟件對的雪球，不得已要打破以前的架構方式。然而新修訂的入戶軟件已經使得以前的變得面目全非，並限制以後功能的擴展。從而這個軟件若是要重構的花費還比不如從新開發一個軟件成本高。而重構在「軟件系統的過程, 它不會改變代碼的外部行爲, 同時改善其內部結構。 這是一種嚴格的清理代碼的方法, 它能夠最大限度地減小引入錯誤的可能性。重構的實質就是，在編碼可以考慮以後的維護和功能的擴展。」

然而如今對重構還有彷佛疑惑，針對什麼時候重構，在剛剛開始開發的時候應該在那些方面應該考慮後面的重構？

問題4、

針對第13章的閱讀各類的軟件測試，確實軟件測試是軟件工程中的一項重要的步驟，缺一不可，然而書中學會到了單元測試、構建驗證測試、「探索式」的測試等待，然而我感受能夠加一種測試方法，就是將用戶和測試人員相結合的方式一塊兒進行測試，這樣的話經過用戶的角度就可以更多的去發現問題，同事在他們測試過程過程當中，也能讓他們發現問題，並及時解決問題，不至於到最後交付項目時候出現誤差。

問題5、

針對在在第16章中，閱讀針對創新，文中談到了創新，談到了創新時機、創新的迷思和招數等。同事舉例了創新的產品，其中對於一個魔方的銷售，針對不一樣的客戶使用了一些不同的商業模式。然而針對軟件工程開發領域創新到底什麼樣的才叫創新？要達到什麼要求水平才能稱得上創新？新的開發技術的出現算是軟件工程的創新嗎？

 

4、瞭解和調查源程序版本管理工具

以前暑假作的項目都一直使用svn，用的過程當中一直注意的就是始終保持與SVN服務器保持同步，代碼的版本控制，分支控制，必需要靠有權限的人才能操做。而本次使用的git讓每一個用戶均可以有本身的版本控制，能夠用戶更多本身管理本身代碼的途徑。

管理工具	簡介	優勢	缺點
Git	開源的分佈式的vcs(version control system)版本控制系統	能夠先存儲在本地，不會存在服務器死機就影響工做，擁有豐富的資料來進行學習查閱，開源的，大小項目都可管理，擁有良好的分支機制	兼容性很差，可能在上個版本的項目內容放到另外一個git版本會出錯。
Gitup		一、適合分佈式開發，強調個體； 二、公共的服務器壓力和數量都不會太大； 三、速度快， 成熟的架構，開發靈活； 四、任意兩個開發者之間能夠很容易的解決衝突； 五、離線工做，管理代碼成本低，不須要依賴服務器； 六、部署方便。基本上下個命令就能夠用； 七、良好的分支機制，可讓主幹代碼保持乾淨。	一、資料少，學習成本比較大，學習週期比較長，要求人員素質比較高； 二、不符合常規思惟； 三、代碼保密性差，一旦開發者把整個庫克隆下來就能夠徹底公開全部代碼和版本信息。 四、不支持中文，圖形界面支持差，使用難度大。不易推廣。
Rational	一種面向對象的統一建模語言的可視化建模工具。用於可視化建模和公司級水平軟件應用的組件構造。	ROSE在UML建模方便太方便了，並且速度也比較快，支持分包，支持對軟件過程的全程管理	ROSE好像不能作數據庫設計，以前用的不支持c#，不能轉化成c#框架代碼，正逆向工程不是特別出色