本篇文章是我在讀完這本書時，根據自己的感悟寫的一些感想，也算是我對這本書的總結吧。
開篇以愚公移山舉例，論證程式設計的精義。愚公移山，這個寓言故事很多人都聽過。愚公比作專案組織者、團隊經理、程式設計人員、技術分析師等。我了解到愚公的專案。在《愚公移山》的工程專案中，我們認識到了程式設計的根本：順序、分支和迴圈。無論是什麼樣的工程，即使是「愚公移山」這樣龐大的工程，當有了專案需求，再確定整個專案的工作流程，其中包含必須的順序、分支和迴圈結構，都是可以通過簡單的程式設計來實現的。而順序、分支和迴圈結構便是程式設計的精義所在。專案目標是平山。他也制定了詳細的計畫。愚公的專案甚至可以用**表示出來。
『程式=演算法+結構』這是程式設計的本質。作者闡述了工程的含義。沒有實現工程，其實這些語言，演算法，資料結構也不能完成什麼專案。
的確，方法都是懶人創造的，如果人不偷懶，也沒有今天這麼多的工具供我們使用。愚公那樣堅持不懈，但是造就不了方法，唯一的結果就是耗時長。作者的思考:程式 = 演算法 + 結構 + 方法。作者想到物件導向和面向過程的方法。與「物件導向」是否出現完全無關的乙個東西，卻因為「過程」和「單元」的出現而出現了。這就是「工程(engineering）」。
團隊的概念。三個人為乙個團隊。『首先乙個人算不得團隊，那是個體。兩個人則互相支撐，古文中「從」字是二人互立，就是這個意思。然而二人互立並不算團隊，因為沒有監督。三個人便可以構成團隊，這樣便有了團隊的一些基本特性：主從、監督和責任。』引用作者的話。以後做專案大多都是團隊一起，既然是團隊就要有管理人員。如果團隊有失誤，管理人員要先擔起責任。做專案 = 死亡遊戲 ? 如果專案失敗，大部分責任在管理人員也就是專案經理。專案經理雖不用像李離伏劍那樣，但至少也要有遞交辭呈的勇氣。專案經理也不是什麼好做的。乙個團隊的組織機構尤為重要，有時甚至可以決定專案的成功與否。
接下來就是關於過程的討論。前有瀑布模型將軟體開發的過程分成需求、分析、設計、開發和測試等 5 個主要階段。後有v型模型，將測試改到每乙個階段。專案建設的過程複雜又簡單，複雜在每一項分管許多小的模組；簡單在流程的固定。
『組織』工程，是乙個專案經理需要做的。工程的概念涉及很深，需要很多構思，要經歷長時間的思考，才出現乙個雛型。從經營到管理，是乙個巨大的工程，需要更加的深入。
如今，網際網路盛行的時代，各大公司開始發展自己的軟體工程。雖然如此，但軟體工程並沒有成熟。回顧整個軟體工程的體系，體系完整，但是複雜難懂。各種概念術語讓人費解，但又讓人著迷，想要去了解它，掌握它。
如今的我對軟體工程思想的了解並不深，只能領悟到這樣。如果真正了解到深層的思想，我這些字數也不能描述乙個軟體工程的輪廓，我還需學習。
寫的有些倉促，如有錯誤請提出。
大道至簡 讀書隨筆
閒暇時，拿起手邊剛藉的這本書 大道至簡 軟體工程實踐者的思想，看打這個名字還是有一點的好奇，很想看看我這個身為初級程式設計人員和那些真正的軟體工程師的思想層面上的差距和一些借鑑。開篇並沒有長篇大論也沒有說一些讓人難以理解話題，只是引用了中國古代的乙個故事，從這個我所熟悉的故事開始展開作者身為軟體工程...
大道至簡閱讀筆記
學什麼都有方法，程式設計更不例外。在我看來，學程式設計最重要的就是方法。正如書中所提及的，人的精力終歸是有極限的。做事不能一昧的依靠動力，得提出新的 方法 這才是解決事情成效的根本問題。也許會有人說我們可以多吃點飯，多加點班，但是人終究突破不了精力的極限。一昧這樣做，到最後可能會適得其反，終究被現實...
閱讀大道至簡有感
程式設計是一件很難但又很簡單的事，只要我們將其分解為簡單的幾步就很容易了。first is目標，乙個程式最根本的就是目標，我們需要將我們的程式交給客戶，then is solution,找到解決問題的方法，the last is program，就是這個程式的基本。很多人們認為程式設計很難，就像愚公...