大道至簡
作者：周愛民
Tag標簽：無
用戶評論 (總計27條)
- 最近把大道至簡讀了兩遍，還是蠻多收獲，總體的結(jié)構(gòu)上以軟件工程的構(gòu)成為主線，但是單獨一章的內(nèi)容來講，結(jié)構(gòu)上稍微亂一點點，主要是談個人的經(jīng)驗，所以畢竟每個人的感受都是不一樣的，所以不可能面面俱到。 作者本人對技術(shù)有較深的研究，所以在讀本書的過程中可以看出重視軟件工程本身，而不是某一技術(shù)，印象最深的應(yīng)該就是“知律而變”，應(yīng)該知道原理，為什么要這樣子。很多時候，我們在學(xué)習(xí)各種技術(shù)、各種方法的時候，都是 為了寫文檔而寫文檔、為了畫圖而畫圖、為了看上去好看而作各種各樣的表格無用的東西，已表明我們掌握了各種技術(shù)方法，但是實際上發(fā)現(xiàn)實際的應(yīng)用中很難有成效，很難實際應(yīng)用。很多時候工作也需要做表面功夫，但是不能忘記本質(zhì)，也不能以表面功夫為理由，忽略本質(zhì)的東西，因為只有本質(zhì)的東西才能積累。
- 第二次讀這本書，感覺還是有些有用的團隊思維和經(jīng)驗。
但是作者大部分篇幅的文字讓人難以提煉觀點，不知道想表達什么，不知是否作者有意為之，總之有違書名“大道至簡”。愚公移山的故事引入也不知何意，生硬之感。
如果是3年前第一次看此書的我，可能給5分，因為我看不懂。 但是現(xiàn)在只有3分，也是因為我看不懂
- 前幾章都不錯，一直到第七章。
思緒有點亂亂的，從需求到管理到維護都講了一些，泛泛的，不過還是很有啟發(fā)，有必要閱讀第二遍。
后面的幾章沒看懂，下次讀第二遍的時候看看。后面說道人月神話，說道愚公銀山。
另外一些點評感覺扯淡，不應(yīng)該出現(xiàn)
- 從圖書館借的書，里面被”前輩“們用鉛筆畫的條條杠杠的，在107頁的右側(cè)幾個非醒目的大字”什么邏輯？“
看樣前輩與我也有相同的看法，里面的例子很多都比較牽強……例子有點生搬硬套，有時候就是甚至是在說解文字。。
不否認作者的論點，也肯定作者有很多年的經(jīng)驗，對很多東西有深刻的理解，但作為讀者的我，卻沒能很好的吸收作者的思想及經(jīng)驗。。
讀書的過程中，對soul比較感興趣，不知道他寫過書沒？想讀一讀。。。
經(jīng)常在群里面聽到一些人說”牛人都是用記事本來寫代碼的“…… 我經(jīng)常在心里自慚形穢一翻。。。。
作者也說到自己書中的例子90%是用記事本寫出來的，額，這真是裝B青年必備利器呀，我以后也可以在群里大喊，人家牛人寫代碼都用記事本的，誰還用IDE咧！
唉，說這例子感覺沒必要吧，你寫例子，人家是做大項目，如果還用記事本……唉！ 我還是無法想象。這有點誤人子弟呀……
還有一些其它其它……
不過里面還是有些觀點不錯的：
/////////////////////////////////////////////
項目經(jīng)理需要時間來成熟的。他需要機會來承受錯誤，而不是一開始就享受成功。
流于形式的溝通。
溝通的第一層障礙，并不在于你要表達的內(nèi)容，而在于你如何表達。
最好在見客戶之前，就已經(jīng)設(shè)計了所有問題和提問方式，避免造成溝通不暢或流于形式的溝通。（即有目的性的溝通，而不是與客戶交流感情）
留下歷史記錄，記錄下自己的決策過程等，方便后來者。
如果你不懂甲骨文，那么也不要指望你的用戶懂UML。
實現(xiàn)才是目的。實現(xiàn)是軟件開發(fā)的本質(zhì)需求。
成功的經(jīng)驗往往最不可信，反而是失敗的經(jīng)驗更有價值。
經(jīng)驗，是源于對過去的思考，而不是對過去的復(fù)制。
團隊要有遠期的目標，有共同的愿景。對短期的目標也要清晰，即里程碑。
“教官”的任務(wù)：協(xié)調(diào)、督促、激勵、監(jiān)督和凝聚。
工作上，先人后已，即先為團隊服務(wù)，然后自己再完成一些細節(jié)的事。獎勵，同樣也要“先人后已”。
要關(guān)注整體目標。從全局上把握，某一局部出現(xiàn)問題之后，要能盡快發(fā)現(xiàn)，并迅速調(diào)整。
不要壓抑你團隊成員的激情，他們提出自己的想法之后，要鼓勵與引導(dǎo)，即使你認為不合理，或有錯誤，也要以引導(dǎo)的形式，或者干脆讓他去犯這個“小錯誤”，從而讓他在這個上面有更深刻的認識與印象。
軟件工程層狀模型(EHM)
工具，是為了更好的實現(xiàn)結(jié)果。 - 7年前的書了，還是讓人很受教，所以說很多時候需要學(xué)的東西真的很多
縱觀現(xiàn)在軟件界，相當多的模式，流程，其實本質(zhì)的還是PAET，只是瀑布模型的變形而已，把握住本質(zhì)
關(guān)鍵是時刻要有做工程的心態(tài)去做，而不要沉迷于技術(shù)，方法這些枝葉中
但是還是要學(xué)習(xí)那些相關(guān)的模式之類的，只有學(xué)會了，才能更好的忽略掉+ - 感覺有些空洞，那個愚公移山的故事，怎么看都有穿鑿的感覺。其實大道理誰都懂，關(guān)鍵在于是否真對實踐有足夠的指導(dǎo)，并且能與實踐相結(jié)合。
和《程序員修煉之道》、《代碼大全》、《編程匠藝》之類的書差距不小。 - 看慣了論壇上對語言的無聊爭論，但是工作了，卻從來沒有碰到這樣走火入魔者。
也許是大公司里的，未必能力有多高，但大都都有招招即使九曲八拐還是不離主題。對于公司的盈利虧損： I am just a worker. 能混即可，發(fā)財不靠工資。I am justa a manager, 我只希望手下的人越來越多。什么xp, scrum， I just care my position.
也許那些入魔者還期望通過入魔來提高個人能力，加入大公司，沒有想到大公司里根本沒有這種討論。 - 感覺副標題很確切，就是在描述一個實踐者的心路歷程，內(nèi)容還算不錯。
然而，里面的古文引用是在令人發(fā)指，無法忍受。。 - 這是一本需要反復(fù)閱讀的書，我獲得此書是在幾年前下載到的電子版。每過一段時間都會找出來在讀一遍，每次都有新的收獲。書中是作者在實踐中總結(jié)的經(jīng)驗和道理。作者對軟件工程相關(guān)的問題有許多感悟，并且能夠生動的表達。這些實踐當中的總結(jié)十分寶貴，所以我每過一段時間都要再讀一遍，一邊讀一遍總結(jié)自己的工作，受益匪淺?？少F的是思想而不是生動的小例子，大家都的時候仔細體會背后的思想，一定有所啟發(fā)。
- 寫代碼之能力有余而管理之心不足?？傊杏X缺乏很多，個人深感空洞而不厚實。遂信意尋項目管理知識加以補充，無意間看到，閱后頗有所得，特此共鳴一下。
當軟件進入大規(guī)模工程化的年代，很多東西開始進入了工程的范疇，那就意味著是軟件不再是簡單的編碼和coding，不是一堆的類，而是融入了管理，計劃，方法論等一系列工程化的project，所以，考慮之處不能不謂周全。這就需要管理者從編碼的細節(jié)里面跳出來，站在更高的臺階上開始統(tǒng)籌和總覽整個工程，并且加以合理的規(guī)劃和控制。當然，你首先得有基礎(chǔ)的經(jīng)驗，無論是來自于編碼，還是來自于管理。
原始的：軟件＝算法+數(shù)據(jù)結(jié)構(gòu)。
在集成化開發(fā)的今天被修正為，項目＝程序＋方法＋過程＋管理（工程＋組織）。
團隊是項目的執(zhí)行和實現(xiàn)者，項目成為整個團隊的目標，所以以目標為導(dǎo)向的項目管理。建立在工程方法論的基礎(chǔ)之上的過程，用于控制整個產(chǎn)品的周期，成本，質(zhì)量。而對于細節(jié)，那只是技術(shù)經(jīng)理所要關(guān)注的事情，但是作為一個身兼技術(shù)和項目的經(jīng)理，必須進行統(tǒng)籌和規(guī)劃。作為一個小的團隊，一人身兼兩職，的確是一種高效方式，首先節(jié)約了溝通的成本，其次解決了技術(shù)和管理之間定制方案所產(chǎn)生的分歧的比例。這就要求團隊的Leader擁有很高的素質(zhì)，無論是在管理，還是在技術(shù)上。
作者對道家和儒家的思想很有研究，對史記和古文也有一定的涉獵，作為基礎(chǔ)的思想核心，來推動作者對技術(shù)和管理孜孜不倦的思考和探求。在技術(shù)中做長時間，難免會沉浸在技術(shù)中不可自拔，有苦有樂，當作為一種愛好，定然是孜孜不倦，全憑興致發(fā)揮。然而作為一個管理者，單憑技術(shù)和愛好不免難以應(yīng)對來自管理和工程方面的知識和方法論。所以充電是必然，MBA也是必然。
在作者的后記中猶有會心一笑，可嘆時間如此飛逝，光陰如此墮落，吾落后于人也。
- 最早是在北京清華園旁邊的一個小書屋內(nèi)看到這本書，當時就被書名所吸引，昨天終于花了一晚上的時間將整本書過了一遍。真正有用的道理通常都是樸素簡單的，年齡越大越是能體會到這一點?！洞蟮乐梁啞防镏靥崃恕赌愕臒羰橇恋膯帷分嘘P(guān)于智慧是認識事物本實這一道理，這引導(dǎo)我們透過現(xiàn)象觀到事物本身的目的和內(nèi)在的聯(lián)系、可以看出，作者在軟件工程領(lǐng)域確實是有一定經(jīng)驗的，對中國古典文化亦多有涉獵，這讓我對軟件工程領(lǐng)域之人的思想可以略窺門徑，正如作者所言，在軟件工程領(lǐng)域，講方法的書很多，但講思想的書確是不宜尋見，權(quán)且作為拋磚引玉吧。
道可以是至簡的，但尋道之旅卻是復(fù)雜甚至是漫長的。 - 面對副標“軟件工程實踐者的思想”，反躬自省，讀了太多理論，甚至都忘了實踐。我們總對新技術(shù)新概念趨之若鶩，總不曾觸及它們背后的“大道”。作者用愚公移山的故事貫穿全書，解說了“智”與“愚”。我以為，軟件工程的核心就是高質(zhì)量的完成項目，語言、工具、理論等等只是手段，是“做工程”而不是“做過程”。
大概是為了湊頁數(shù)，略扁的字體讓我覺得很不舒服。 - 第一眼看到它，就愛上它不是因為書本身，而是因為李維的那句書評。仔細閱讀，發(fā)現(xiàn)作者真的沉淀了很多很多，學(xué)習(xí)技能固然重要，更重要的是學(xué)到優(yōu)秀的思想！
- 作者總結(jié)的很好，其中的一些想法一看就是多年經(jīng)驗的沉淀，對大公司的戰(zhàn)略的分析讓我學(xué)到了很多，不可多得的好書!
- 含混不清，豈能坐而論道。
這種東西居然可以出版。
都是大忽悠。 多少無知讀者被忽悠了啊。悲哀。
- 溝通的第一層障礙： 不在于溝通的內(nèi)容，而在于如何溝通。
寫的不錯，有時說一個簡單問題 別人聽得稀里糊涂的。。。 - 每一本書都是作者總結(jié)實踐成功或走向成功過程中失敗而得到的，
隨手記錄下一些閱讀中的心得:
記憶最深的就是他的EHM(Engine Hierarchy Model),一圈圈像牛糞:) 。
幾個計算公式(一看就知道作者是邏輯思維嚴密的程序員)
程序=算法+結(jié)構(gòu)
方法=面向過程/oop/mda
過程=RUP/XP 模型與建模語言
工程=需求管理+過程管理+配置管理+文檔化
管理=管理+計劃
其中:程序、方法是實現(xiàn)，過程、工程是團隊，我猜測管理應(yīng)當算是財務(wù)了把，把團隊能用的資源進行限制。
團隊說明: p70
1.方法和目標明確
2.團隊并分工協(xié)作
3.能意識分享并有規(guī)避策略
態(tài)度必須認可，至于"想法好不好"是技術(shù)問題 p73
所謂矛盾，大多是自找的。 p79
偉大的球員和普通的球員的差別，就在于偉大的球員總是說:"這不是個問題"
項目經(jīng)理關(guān)注成本,成本=時間+人力+資金+客戶成本=客戶數(shù)量+客戶的耐心
p50 History可以用wiki來實現(xiàn)
p60 可以讀一下朱湘的《畫虎》，里面有非常棒的論花匠和畫師
p65 一個團隊的特質(zhì)是管理者在團隊生活和行為過程中逐漸形成的團隊特質(zhì)，成功的經(jīng)驗往往最不可信，失敗的才最可信。
p67 對失敗的案例進行分析，并于團隊中的成員分享可能要好很多。
p104 對于工程來講，能讓團隊理解，統(tǒng)一執(zhí)行，迅速而有效的實戰(zhàn)技法，才是真實所需的。
p105 惟手熟爾
p106 工而制具、工而制藝
p108 工具+技法>工程;良匠是一種好的品質(zhì)。
p105 融通是基于對"使用工具的方法、理論"的了解，融同，則是對這個工具存在的本質(zhì)價值的認識。
記錄了一下自己閱讀到的內(nèi)容，記下了自己當時最有體會的一些內(nèi)容。如果你認真做過項目，被管理過或者管理過他人，你對其中的話一定深有體會，作者還是認真寫了的。
- 我正在看本書，其實我覺的這本書雖然簡單，但它卻把我們工作中一些抽象的概念講的卻很容易理解，我想這或許就是作者的根本意圖所在。
- 如果這本書出版了，可能會罵聲一片吧，不是說內(nèi)容太差，而是這樣的形式在這個年代不適合印成鉛字，就像《Java夜未眠》一樣，可能因為那本比較早，所以評價還可以吧。
每件作品能讓受眾經(jīng)歷之后記住一點可算是成功的了吧（除了放在手邊的工具類書籍），這本書看了之后記住了那張關(guān)于程序，方法，過程，工程，組織的圖片，那也是作者一瞬間的靈光，可惜這里不能貼圖。
作者的網(wǎng)站是MSN spaces下的很慢，我傳了一個在51Files上：http://www.51files.com/?72KZD1N7L7N52UC3UNCD。 - 最近也在讀《最后期限》，相比之下，《最后期限》還是更合我的口味呀，寫的又通俗易懂。所以，力薦《最后期限》
《大道至簡》這本書，閑暇時間可以翻一翻，抓住里面的一些關(guān)鍵點就行了 - 我覺得用記事本寫代碼的意思是，無論何時何地都在思考，即使不在電腦旁邊時，也隨時利用身邊的筆和紙演算設(shè)計。
- 哈哈，樓主我居然和你讀了同一本書。。深圳南山圖書館。
- 喔，太有緣份了，是在南山圖書館。。。 呵呵
- 我沒得這本書，哎..老師要我們寫這本書的讀書筆記。
- 《大道至簡》和《你的燈是亮的嗎》確實思想上是一致的。
我也推薦 《你的燈是亮的嗎》 - 語言沒有會不會，只有喜歡不喜歡
- 寫的亂。