第一章：概論

有一個朋友問我：“你們軟件工程和計算機的課表差不多，你們有c有Java，他們也有，你們要學計算機組成原理，他們也要學，有什麽區別嗎？”大一我還真的無法回答，我只知道我們學費是他們三倍，但是學的課程差不多，師資也差不多，甚至一樣的老師。讀了第一章有了一定的認識。

問題：那麽我們為什麽有那麽多一樣的學科？

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

第二章：個人技術和流程

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

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

問題2：優秀的資深的程序員是否可以不做單元測試 ？

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

我的思考：繁瑣的步驟是不能僥幸省略的，人非聖賢，如果那些省略的步驟正好能規避麻煩，你恰好省略了，那麽將造成系統的麻煩。

第十六章 IT行業的創新

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

“不太做廣告，主要靠口口相傳，容易被技術進步淘汰”，的確作坊會被技術進步淘汰，因為他沒有大公司的實力。比如說現在很火的“吃雞”，感覺他就是找了一群忠實的粉絲，然後靠這群人來擴散，然後就形成了如果你不吃雞你就out了的形勢，這是一種成功的手段。創新要把握時機，否則面對的是風險和淘汰。

《構建之法》第1、2、16章閱讀隨筆