前幾日，網上流行一本書，是周愛民的《大道至簡》，我看了名字後不削一顧，名字起得裝模做樣，後來專案經理給我推薦了這本書，併發了電子版本到我的郵箱，再後來，公司裡有人開始討論這本書了，於是引起了我的好奇心，反正打遊戲也是虛度光陰，不如看看這本書寫了些什麼東西。看書那天是深夜了，習慣了晚睡的我，把這本書找了出來，打算做催眠的作用，可是後來我才發現適得其反，越看越精神，一口氣看完的時候都是早上8：00了，辛好第二天是週末，可以大睡一覺。
這是一本關於軟體工程的書，其實以前我看過一本外國的大師級作品《人件》，我看這本書的時候完全是衝著這個大師的名字去看的，但是到現在我幾乎都完全忘了裡面講的是什麼，可能是老外的寫作風格不同，又或者是到了中國的時候翻譯出了問題，總之不和我胃口，但是這本書不一樣，在《大道至簡》裡面大多數章節的開始都要講乙個中國古時候的小故事，並且還要引用原文，作者真是費勁心思，用乙個小故事來引起讀者看下去的慾望，通過故事說明一些道理，然後推導到軟體開發裡面去說明一些現象。整本書都的確是扣了題，每個問題都力求從表象說到實質，說到實質後自然大道就簡單了，從物件導向--->問題思考--->軟體工程，無不體現了這個思想。
其實從書中能夠看出來作者是乙個善於思考的實用主義的人，上面這句話裡面其實就概括了我看這這本書的最大兩個收穫，我想這也是作者要傳達給我們的東西。首先說善於思考，作者從一開始對於他要闡述的每乙個問題，每乙個故事都做了深入的思考，並且把問題的本質抽出來，轉化成簡單，核心的實質性的東西表述出來，這是作者要傳達給我們的第乙個東西，作者可能希望我們能夠看了這本書以後要善於思考，多花時間思考，而不是沒日沒夜的重複寫code。其實，思考不要盲目，要從實際角度出發，舉個例子，在第四章中，作者講了溝通，作者認為客戶和程式設計師之間的溝通，或者客戶和業務公司的溝通，最重要的的是雙方能夠有效的在短時間裡面相互交流到實質性的問題，至於是用c語言表述，還是uml用例圖表述，更或者是用偽**表示都不是問題，作者甚至玩笑的說用甲骨文寫客戶溝通報告都強於uml用例子圖，所以溝通最終是要達到彼此了解的目的，類似於這樣的思想在一本書中都有說明，作者認為解決問題是根本，而現在那麼多技術，那麼多技術名詞，實際上是複雜了問題，當然並不是我們就不要他們，而是我們再使用的時候要看清楚他們的根本，這就是實用主義，一起從解決問題出發。「如同程式設計工具中的編譯器和整合開發環境(ide)一樣，開發中的程式語言，過程中的模型語言都只是一種工具。工具的產生認舊是出於『(軟體)實現』的需要」-----摘之大道至簡。所以思考才是本源，「圍棋的學習有四個階段：記住定式 應用定式 忘掉定式 創造定式」。---摘之附錄。
然而，當我認真仔細的看完這本書的時候(也許我們根本就不該把他定義為書，我個人認為這篇文章僅僅是從思想層面上引導我們我們去學會思考，善於思考以及勤於思考，只是為了更好的說明作者的觀點，以軟體工程這件事為例而已，而書從某中意義上來講，應該是乙個自成體系的東西，所以從這個角度而言我只是把他定義為長篇文章)，所以從這個角度來看，這本書的體系性還不是很強，雖然文章從物件導向--->問題思考--->軟體工程--->思考這個很有敘事性的邏輯來完成作者想要表達的意思，但是敘事性仍然沒有掩蓋體系的瑕疵。最後第八章的時候，作者依然將筆鋒轉到思考這個根本的話題上面來，不過最後一章的描寫顯得太零散，筆隨心出，如果這一部分好好整理一下就好了。
總體來講，這是一篇很值得推薦看的文章。
迷時師度，悟了自度！！！
看了《大道至簡》
無意間在網上翻到這本書，粗粗的看了一遍，有點感觸。可以研究細節，但不能陷入，可以一時陷入，但不能一世陷入。當然，這對技術狂熱者或許是除外的。如果要解決問題，那麼無論何種程式語言，都是一種工具，要做的是對於當前的問題選擇適合的工具。任何一種工具都是在某個情境下才可以區分孰優孰劣。中國的一些理論，很少放...
讀大道至簡
軟體開發 方法 過程 工程 組織 演算法 結構 方法 面向過程 物件導向 過程 瀑布模型 迭代模型 工程 專案管理 進度 成本 質量 組織 體制 組織結構和制度 是乙個向外擴充套件的過程。方法 分，模組化設計 過程 增量迭代，還是瀑布模型 工程 進度 成本 質量 組織 組織結構 制度 舉乙個做生意的...
大道至簡Segment Routing
聽了一下思科服務支援社群的講座，以下為筆記 1.基礎知識 1 igp基礎 ospf和中間到中間系統協議 2 bgp基礎 3 mpls 多協議標籤交換 2.模擬器為ios xrv 6.0.1 3.sr架構基於源路由。節點擊擇路徑，並且引導資料報沿著該路徑通過網路，做法是在資料報頭中插入帶順序的段列表，...