近日花了一些時間在讀周愛民老師的《大道至簡》，全書整體來說是本好書，不過有些部分卻不是很認可，在這裡來談一下，對於整本書觀點，我的一些看法。1. uml之我見
從書中的文字中，我隱約感覺到愛民老師對uml是比較反感的，以至於出現了這樣的文字：
程式設計師不能要求客戶會c，難道需求分析師們就一定要求客戶會uml麼？
專案文件真的可以用甲骨文來寫。
我不了解愛民老師為何會對uml有如此看法，其實在我看來，的確，專案文件可以用甲骨文來寫，如果專案組都認識甲骨文的話。
uml的核心在於unified上，也就是統一。就像我們說為什麼製作乙個網頁需要用html語言呢？我們不用
而改用不也一樣麼？w3c最大的貢獻不是為我們發明了乙個語言，而是為我們發布了一套規範，讓我們每個程式設計師都可以通過html來溝通。
正如設計模式一樣，其一，他為我們提供了某類問題的解決辦法，而另外的貢獻還在於它為我們程式設計師提供了這樣乙個通用的語言。當遇到某某問題時，如果沒有設計模式，我們可能要畫圖，寫方法，然後講好久才能跟另外乙個人說明自己的意圖，但是有了設計模式，我可能只需要一句話：這個要用工廠模式來解決，大家都明白了我的意思。
就像我們可以自己做乙個編譯器，發明一種新的語言，然後使用這個語言，沒什麼不可。但是前提條件一定是，團隊成員熟悉你發明的語言，新加入團隊的人也要懂你的語言。
那麼也就是說，用 uml 寫文件最大的好處時，團隊成員，還是新加入的成員，都可以讀懂你的uml圖，減小了適應和溝通成本，這就是uml的最大價值之所在，這也是標準的力量。
2. 團隊中的討論
每個做技術的人都懂，與人討論，說出自己的想法，傾聽別人的想法，是對自己最大的提高。這是對於技術問題。
有句話是「三個臭皮匠，湊成乙個諸葛亮」。這也說明了在乙個專案中，或者乙個團隊中，討論的重要性，只有一群人交流，才可能會迸出奇蹟的火花。
而具有最終決策權的管理者，究竟應該如何看待這樣的討論。
愛民老師的話很有道理：不要把溝通目標設定為「讓對方認同」。
在我們沒有辦法把事情討論清楚的時候，旁觀者最清。因此這個時候，作為管理者，作為決策者，你應該跳出這場討論，作為旁觀者去觀察，去思考，只有作為這個角色，你才是最清醒的。
作為管理者，你可以適時地停止這場討論，但是並不意味著這次討論就劃上了句號。而是討論暫時不清楚就先讓他不清楚，讓需要討論的人（而不是整個團隊）繼續去討論。
你不要給這次討論試圖做什麼總結，這次討論，管理者需要做的是，為他們營造環境，讓討論的幾個人，在其他的時間把這次討論繼續下去，而你，要做的一直是個旁觀者，傾聽者，思考者。
大道至簡 溝通
在日常生活中我們少不了與人溝通，溝通搭建了人與人之間的橋梁。溝通的方式有很多種，不僅僅是語言，還有我們的表情，肢體動作等。但不可否認的是語言是我們人常生活中最常用的一種溝通方式，通過語言我們可以將我們的想法表達給其他人。溝通能力日漸成為用人單位選擇員工的重要指標之一。作為一名程式設計人員我們要了解計...
讀大道至簡
軟體開發 方法 過程 工程 組織 演算法 結構 方法 面向過程 物件導向 過程 瀑布模型 迭代模型 工程 專案管理 進度 成本 質量 組織 體制 組織結構和制度 是乙個向外擴充套件的過程。方法 分，模組化設計 過程 增量迭代，還是瀑布模型 工程 進度 成本 質量 組織 組織結構 制度 舉乙個做生意的...
《大道至簡》之溝通
c語言是每個程式設計師必需學習的語言，也是必須要掌握的語言。它對於開發人員，卻不一定對每乙個人來說重要。客戶是不需要掌握 c語言的，在開發人員看來，他們希望客戶學習或精通 c語言，這樣可以方便他們之間交流和溝通，可是要求客戶學習 c語言明顯是自殺式的行為。所以，開發人員最還不要只見面對客戶，讓專案經...