今天我閱讀了《大道至簡》第四章，「流於形式的溝通 」。首先作者提到了「客戶不會用 c，難道就會用 uml 嗎？ 」這個問題。在作者的論述中，我明白了而要求客戶學習 c 語言明顯是自殺式的行為。在 客戶學會用c 語言來向開發人員描述他們的需求 之前，可能我們就已經被老闆開掉了。c 語言是程式設計師與計算機交流的語言，而不是他與客 戶交流的語言。程式設計師面對的是計算機，但計算機不是客 戶。與此同時，程式設計師不能要求客戶會 c language，我 們也不能要求客戶一定會 modeling language。因此，溝通的方式很重要。
接下來作者又說到「專案文件真的可以用甲骨文來寫 」。作者說到，只要你運用得法，甲骨文一樣可以用來畫用例圖 和寫用例規約。同樣的，只要約定一套「語法」，你同樣 可以用甲骨文來做活**、類圖、構件圖⋯⋯以及這些圖 相關的規約。從這我明白，不管什麼方式，只要雙方理解，就是好的溝通方式。
最後作者又提到了最簡溝通和為不存在的角色留下溝通的渠道。所謂最簡溝通，作者給了一些描寫。開始在網路上檢視相關的軟體系統的特徵以抽 取客戶所關注的內容；了解該客戶的公司、經營理念、組 織結構形式以及工作模式；了解同類公司的成功經驗和優 秀的管理模式，以及客戶的競爭對手在做什麼和在關心什 麼。 最後開始綜合兩個方面的因素： 客戶在公司層面的外在表現、內部機制和運營管 理手段；客戶在專案中既已明確的需求和可能發生的需 求，以及客戶圍繞其公司行為(和方向)所提出的 需求。 所謂為不存在的角色留下溝通的渠道，做專案的時候，如果也不留下歷史記錄 ，那麼以後別人來看這個專案，也會是兩眼一抹黑，所以我們要留下記錄和筆記。
通過作者的敘述，我更加了解了溝通的方式，給了我新的認知。
《大道至簡》讀後感
通過學校的老師，我拿到了 大道至簡 這本書的電子版，並且在老師的建議下利用暑假時間讀完了這本書。周愛民老師的 大道至簡 這本書被譽為 激盪新思的佳作 通過閱讀這本書，我得到的啟發還是蠻大的。作者靈活地將小故事融入到了論述中，開篇以愚公移山為例，本以為整本書是論述枯燥無味的方法，甚至讓我難以讀下，但是...
《大道至簡》讀後感
大道至簡 這本書很薄，是作者從事開發十年開發工作的總結 閃爍著獨立思考的光芒。該書指導著程式設計員的思維 例如 愚公移山，古代的專案產品經理 讓我們看到了 原始需求的產生 專案溝通 確定乙個專案的目標 程式設計的根本 順序 分支 迴圈 做出乙個好產品並不難 而且門檻也不高 設計師還需要一項基本素質 ...
《大道至簡》讀後感
去年，我滿懷對計算機的熱情填報了計算機專業，卻只經歷了潦裡潦草的一番學習，軟體工程對我而言依然陌生。不過幸好老師向我推薦這本書，才讓我對軟體工程這個專業有了一點初步的認識，讓我了解到工程並不只是程式設計，讓我知道，大一所學c c 其實知識只不過是冰山一角。在書中，作者以愚公移山的故事通俗地闡釋了程式...