一開始這只是乙個作業，但細讀後我想這是一次愉快的旅程。這是一本值得深度閱讀的書，其中不僅闡述了如何開發乙個程式，更讓我開始了解程式背後的故事。程式不僅僅是單一的敲**，更重要的是設計，能夠快速尋找更簡便的辦法來實現程式。
有一句話很觸動我：應該清楚的是，保障每一次溝通的有效性都是最重要的事。從這段內容中我突然發現我在自己做程式的過程中對程式的了解並不多，我通常是拿到程式要求後在簡單的看過條件之後就開始寫程式，然後在整個過程中不斷的發現不了解的地方，過不去的地方，然後再次回頭看程式要求。在這個過程中，效率很低，最後的結果也往往是以不完美告終。通過閱讀我對我設計程式的過程進行了調整，以前我覺得例圖，流程圖都很費事，但更改流程後我的效率大大提高，以前一些總過不去的坎好像有所鬆動了。
之前編寫程式一遇到難題，就去網上查詢類似題目，然後像套公式一樣將其中的細節改了，然後就完成了乙個自己的版本，然後基本就是什麼都不管了。之前拿到《大道至簡》的時候也以為是一本工具書，我只需要從中獲得我需要的模板公式之類的就可以了。但隨著閱讀我發現還是不一樣的，它更像是乙個老師，引領著我前進。給我乙個方向，告訴我思想，讓我明白如何變通。而不是死套公式。《大道至簡》這本書正是一本閃爍思考光芒的技術散文集，它講述的是軟體工程實踐者的思想。
通過閱讀第一章我懂得了：程式設計的根本就是順序、分支和迴圈三種，無論乙個程式再複雜，也離不開這三種結構。書中曾說：除非先天智障或後天懶惰者，都是可以學會程式設計的。程式設計實際上就是用自己的語言把一件事情教給計算機去做，你認為這件事該怎麼做，就用相應的程式語言的形式描述給計算機，所以程式設計的第一要務是先把事情分析清楚，時間先後的邏輯關係和依賴關係搞清楚，然後再去**實現。閱讀第二章我明白了方法的重要性。文中說到懶人造就方法，程式的固然做事需要勤奮但也要講求方法，懶惰的聰明人做事總會想方設法，追求效率。因此更多的方法被發明出來。
第三章講的是關於團隊的。乙個好的團隊不僅需要良好的管理，還需要組織好乙個確定的團隊模式。書中說乙個團隊需要乙個良好的管理者。管理者需要有乙個正所謂「皮之不存毛將焉附」，沒有確定的組織機構，又如何能指望做出來的管理制度「合用」呢？乙個好的團隊管理者要勇於承擔責任，在制度面前，既做得到「人性化」，又做得到「公平性」。正所謂「當局者迷旁觀者清」，你要緊緊跟隨你的開發人員發現問題但是不能進去他們的「螞蟻洞」，洞內就只有做循規蹈矩的「螞蟻」。書中說：做管理不等同於做伯樂，明確分工是一位管理者的職責。
第四章講和客戶的溝通。和客戶做好溝通很重要，它不是打**或者請客吃飯那麼簡單的事兒。你得到的每一次溝通機會，都是向客戶了解更深層次的需求的機會，因此最好是在見到客戶之前，你就已經設計好了所有的問題和提問方式。溝通是具有目的性的，如果在沒有明確目的的情況下與客戶溝通，那將是浪費雙方的時間。有目的，才能更好的了解專案的相關資訊，最後才是交流感情。但是要明白溝通不僅僅存在與客戶的交流之中，還存在於與專案的各個角色之間
第六章告訴我軟體工程分為四個層次：工具、方法、過程、實現物件。第七章從現實角度出發，強調了要保障團隊的穩定性和一致性和節約成本的重要意義。軟體工程是很靈活的，知律而變，不明道則不明智，不明則無所以為，要學會變通。
《大道至簡》讀感
這本書我用了接近四天看完，篇幅不長，但語言對 程式設計萌新 極為友好。並不是和教科書一樣的教學。在學習任何東西前，都需要先學習他的精髓思想和之後要走的路線，需要具備的能力等等，就好像學 你必須先學音律，學美術必須先學線條一樣，而這本書就充分又樸實的介紹了學好程式設計，你需要做些什麼。語言而又恰恰非常...
讀大道至簡
軟體開發 方法 過程 工程 組織 演算法 結構 方法 面向過程 物件導向 過程 瀑布模型 迭代模型 工程 專案管理 進度 成本 質量 組織 體制 組織結構和制度 是乙個向外擴充套件的過程。方法 分，模組化設計 過程 增量迭代，還是瀑布模型 工程 進度 成本 質量 組織 組織結構 制度 舉乙個做生意的...
初讀《大道至簡》
軟體，是一系列按照特定順序組織的計算機資料和指令的集合，還有另一種表現形式，即 軟體 程式 資料 文件。可以看出，程式是軟體的核心，因此，又引申到軟體工程及其他計算機方面重要的一門課程 程式設計。程式設計，在本書中被稱為勞力活，就好比千年前愚公的勞作，但是他又從側面告訴我們，無論多麼浩大的工程，都可...