《構建之法》第一、二、16章閱讀隨筆

第一章：概論

有一個朋友問我：「大家軟件工程和計算機的課表差很少，大家有c有Java，他們也有，大家要學計算機組成原理，他們也要學，有什麼區別嗎？」大一我還真的沒法回答，我只知道咱們學費是他們三倍，可是學的課程差很少，師資也差很少，甚至同樣的老師。讀了第一章有了必定的認識。

問題：那麼咱們爲何有那麼多同樣的學科？

思考：科學家和工程師的區別：一個是回答why的問題，一個是回答how的問題;一個培養的能力是ask/answer why，一個培養的能力是know-how.那麼咱們爲何有那麼多同樣的學科？我想兩個緣由分別是軟件須要一些計算機科學中的相應知識和對於之後又多一條選擇之路。

第二章：我的技術和流程

 

問題1：什麼是單元測試？

 

百度答案：單元測試是開發者編寫的一小段代碼，用於檢驗被測代碼的一個很小的、很明確的功能是否正確。一般而言，一個單元測試是用於判斷某個特定條件（或者場景）下某個特定函數的行爲。例如，你可能把一個很大的值放入一個有序list 中去，而後確認該值出如今list 的尾部。或者，你可能會從字符串中刪除匹配某種模式的字符，而後確認字符串確實再也不包含這些字符了。 單元測試是由程序員本身來完成，最終受益的也是程序員本身。能夠這麼說，程序員有責任編寫功能代碼，同時也就有責任爲本身的代碼編寫單元測試。執行單元測試，就是爲了證實這段代碼的行爲和咱們指望的一致。

 

問題2：優秀的資深的程序員是否能夠不作單元測試 ？

答案：在真實世界裏，每一個人都會犯錯誤。即便某個開發人員能夠抱着這種態度在不多的一些簡單的程序中應付過去。 但真正的軟件系統是很是複雜的。真正的軟件系統不能夠寄但願於沒有進行普遍的測試和Bug修改過程就能夠正常工做。 編碼不是一個能夠一次性經過的過程。在真實世界中，軟件產品必須進行維護以對操做需求的改變做出反應， 而且要對最初的開發工做遺留下來的Bug進行修改。你但願依靠那些原始做者進行修改嗎？ 這些製造出這些未經測試的原始代碼的資深專家們還會繼續在其餘地方製造這樣的代碼。在開發人員作出修改後進行可重複的單元測試能夠避免產生那些使人不快的負做用。

個人思考：繁瑣的步驟是不能僥倖省略的，人非聖賢，若是那些省略的步驟正好能規避麻煩，你剛好省略了，那麼將形成系統的麻煩。

 

 第十六章  IT行業的創新

說到創新，我反應是如今的軟件基本可以知足咱們的須要，創新是很難了，除非是有很大的技術飛躍。經過對各類現有技術的有效集成，造成有市場競爭力的產品也是一種很好的方法，好比美團，從外賣到旅遊，能夠吃喝玩樂，還能買機票。支付寶也具備愈來愈多的功能，也是一條集成化的道路。

「不太作廣告，主要靠口口相傳，容易被技術進步淘汰」，的確做坊會被技術進步淘汰，由於他沒有大公司的實力。好比說如今很火的「吃雞」，感受他就是找了一羣忠實的粉絲，而後靠這羣人來擴散，而後就造成了若是你不吃雞你就out了的形勢，這是一種成功的手段。創新要把握時機，不然面對的是風險和淘汰。