大道至簡：軟件工程實踐者的思想

大概有1/4的章節 講述了一個和軟件工程無關的故事，外加對應的分析，到還是蠻有趣的。書裏面強調的觀點，主要是關注“道” - 找出來最重要的東西，別太在意那些不重要的。不重要的，比如用什麼語言 用什麼工具 如何實現；重要的，比如實現什麼，期待是什麼，爲什麼實現這個。 此外，對於團隊管理方面，作者也有自己獨特的思考（然而我忘了具體內容了...）

本書內容精闢，充分展示了工程的真諦，跳開程序實現的細枝末節，直達核心。雖然主要講傳統的軟件工程，其實對互聯網的工程也有很強的借鑑價值。工程中，實現是第一要務，用什麼語言，什麼模式……都是爲實現服務

這本書是很值得看一看的。尤其是有幾年工作經驗和工程經驗的人。

用實際經驗教訓說了怎麼做工程，不像大量理論書籍那麼枯燥。但是，語言不夠精煉，特別後面章節，主題不夠突出

不關注細節，站在更高維度去審視軟件工程。我印象最深的就是做工程目標只有一個，就是完成。如果沒有完成，無論選擇的語言多麼高效，框架多麼完善，代碼多麼精巧，它也是失敗的。對於上層而言(老闆？)是沒有意義的。

求真務實，解決實際的業務問題，不迷信，不盲從於各類的軟件工程論，或是某個大師的論斷。立足於現有的資源，人力物力，解決遇到的現實問題，不擴大，不忘想。目標明確，不爲所謂的道、法、式所左右，探就道法式的本質，爲最終目標服務，適者用之，不適者棄之。現在看來，寫代碼者，根本之道在於今天的代碼，會不會給將來的運行與維護，帶來心理上的負擔。今天的努力會不會被將來的自己所鄙視？將來的某個時刻，在回顧這段代碼的時候，會不會覺得怎麼這麼low？簡潔一點，想遠一點，這或許就是代碼者的道吧。

管理 關於編程 編程的第一要務是先把事情分析清楚，把事件先後的邏輯關係和依賴關係搞清楚，然後再去寫代碼實現 語言只是工具 關於團隊 團隊至少是以三個人爲規模的。這有其合理性。爲什麼呢？首先一個人算不得團隊，那是個體。兩個人則互相支撐，古文中“從”字是二人互立，就是這個意思。然而二人互立並不算團隊，因爲沒有監督。三個人便可以構成團隊，這樣便有了團隊的一些基本特性：主從、監督和責任。 驅動你的團隊 只有有了確定的團隊模式，才能尋求相應的管理制度，並且才能把這樣的制度實施在團隊之上。 沒有制度，你沒有辦法和依據來懲戒員工，因此是管理者的過失； 有了制度而沒有懲戒他，是執行者和監督者的過失； 一而再、再而三地犯錯，又一而再、再而三地被懲戒，那就是教而不改，就真正是員工的品性和素質問題了。 最前面的人去看有沒有牆，其他人則關注於腳下有沒有坑——方向與遠景不妨讓大家都知道，但“保障方向”這件事，應該只交給頭羊。 三鼓而竭 關於項目 如果他既不歸任何人管理，也不管理任何人。如果有，那麼就早早把他開掉好了。 項目文檔真的要寫，溝通的必要條件 流於形式的溝通，極有可能是你的項目被不斷推翻和不斷延遲的最直接原因。 做過程不是做工程，目的是實現，工程不是做的，是組織的 項目經理是需要時間來成熟的。他需要機會來承受錯誤，而不是一開始就享受成功。 控制工程的規模和隔離問題域

前後花了七八個小時纔讀完，不是因爲這本書易讀性不高。恰恰相反，整本書的風格有點像話題研討，針對一個個具象的問題，作者提出了一些他的看法，每一章都可以獨立閱讀，適合花費零散的時間看。 但其實歸根結底，整本書都在講一個道理：多思考多多思考多多多思考，搞清問題的本質比「一上來就幹」、「選擇哪種工具幹」重要的多的多的多。對於個人而言，意義不大。適合留給執着於技術，不考慮技術真正價值的開發讀。 不過，全文引經據典的地方比較多，作者應該對歷史很感興趣，從歷史的故事帶入工程，這點我還是比較認同的。個人看來，人文、經濟、心理、社科，這些學科都是相通的，翻來覆去講的都是一個道理，很多事情想通了一點，一通俱通。 另外，如果對軟件工程感興趣，比較推薦《構建之法》，先大概瞭解軟件工程通用的工作內容、工作順序比較好。

前半本精讀，後半本泛讀了一遍。總體作者從不一樣的角度談了軟件工程的一些思想。 萬物之始，大道至簡，衍化至繁。-----老子《道德經》。軟件工程也是如此，開始都很簡單，但慢慢的各種思想、架構、編程方式的出現，跟容易讓軟件開發拘泥於各種形式。 正如作者看來，語言其實是開發的細枝末節，而在大學時代、在課桌上令人昏昏欲睡的《軟件工程》纔是軟件開發中的髓質與靈魂。畢業後幾年的軟件開發實踐中，其實在很多時間裏都讓自己都落入了細節陷阱

從頭到尾，讀的很勉強，很多地方難以理解。也可能是專業術語太多，而自己積累不足的緣故，導致共鳴之處甚少。