我看《大道至簡》 

        前幾日，網上流行一本書，是周愛民的《大道至簡》，我看了名字后不削一顧，名字起得裝模做樣，后來項目經理給我推薦了這本書，并發了電子版本到我的郵箱，再后來，公司里有人開始討論這本書了，于是引起了我的好奇心，反正打游戲也是虛度光陰，不如看看這本書寫了些什么東西。看書那天是深夜了，習慣了晚睡的我，把這本書找了出來，打算做催眠的作用，可是后來我才發現適得其反，越看越精神，一口氣看完的時候都是早上8：00了，辛好第二天是周末，可以大睡一覺。

       這是一本關于軟件工程的書，其實以前我看過一本外國的大師級作品《人件》，我看這本書的時候完全是沖著這個大師的名字去看的，但是到現在我幾乎都完全忘了里面講的是什么，可能是老外的寫作風格不同，又或者是到了中國的時候翻譯出了問題，總之不和我胃口，但是這本書不一樣，在《大道至簡》里面大多數章節的開始都要講一個中國古時候的小故事，并且還要引用原文，作者真是費勁心思，用一個小故事來引起讀者看下去的欲望，通過故事說明一些道理，然后推導到軟件開發里面去說明一些現象。整本書都的確是扣了題，每個問題都力求從表象說到實質，說到實質后自然大道就簡單了，從面向對象--->問題思考--->軟件工程，無不體現了這個思想。

      其實從書中能夠看出來作者是一個善于思考的實用主義的人，上面這句話里面其實就概括了我看這這本書的最大兩個收獲，我想這也是作者要傳達給我們的東西。首先說善于思考，作者從一開始對于他要闡述的每一個問題，每一個故事都做了深入的思考，并且把問題的本質抽出來，轉化成簡單，核心的實質性的東西表述出來，這是作者要傳達給我們的第一個東西，作者可能希望我們能夠看了這本書以后要善于思考，多花時間思考，而不是沒日沒夜的重復寫code。其實，思考不要盲目，要從實際角度出發，舉個例子，在第四章中，作者講了溝通，作者認為客戶和程序員之間的溝通，或者客戶和業務公司的溝通，最重要的的是雙方能夠有效的在短時間里面相互交流到實質性的問題，至于是用c語言表述，還是UMI用例圖表述，更或者是用偽代碼表示都不是問題，作者甚至玩笑的說用甲骨文寫客戶溝通報告都強于UMI用例子圖，所以溝通最終是要達到彼此了解的目的，類似于這樣的思想在一本書中都有說明，作者認為解決問題是更本，而現在那么多技術，那么多技術名詞，實際上是復雜了問題，當然并不是我們就不要他們，而是我們再使用的時候要看清楚他們的更本，這就是實用主義，一起從解決問題出發。“如同編程工具中的編譯器和集成開發環境(IDE)一樣，開發中的編程語言，過程中的模型語言都只是一種工具。工具的產生認舊是出于‘(軟件)實現’的需要”-----摘之大道至簡。所以思考才是本源，“圍棋的學習有四個階段：記住定式 應用定式 忘掉定式 創造定式”。---摘之附錄。

     然而，當我認真仔細的看完這本書的時候(也許我們根本就不該把他定義為書，我個人認為這篇文章僅僅是從思想層面上引導我們我們去學會思考，善于思考以及勤于思考，只是為了更好的說明作者的觀點，以軟件工程這件事為例而已，而書從某中意義上來講，應該是一個自成體系的東西，所以從這個角度而言我只是把他定義為長篇文章)，所以從這個角度來看，這本書的體系性還不是很強，雖然文章從面向對象--->問題思考--->軟件工程--->思考這個很有敘事性的邏輯來完成作者想要表達的意思，但是敘事性仍然沒有掩蓋體系的瑕疵。最后第八章的時候，作者依然將筆鋒轉到思考這個根本的話題上面來，不過最后一章的描寫顯得太零散，筆隨心出，如果這一部分好好整理一下就好了。

     總體來講，這是一篇很值得推薦看的文章。

     迷時師度，悟了自度！！！

今天的人文堅持

——余秋雨講演稿摘選

在自已家的后院挖一個池塘，引文化之水，來滋潤全家，一眼望去，碧波蕩漾，很像樣子。

我與中國大陸一些文人的最大分歧在于，我認為人文堅持的第一原則是善良，他們認為是政治。

對于各色各樣的偽座標，只能有一個回答，那就是：出走。

出走的第二個方面，是掙脫生命的歸并狀態和分類狀態。

以出走來體驗自己的生命，是為了關愛世間的諸多生命。

被提醒者未必會去尋找屬于他們自己的小島，但他們可能會在日常生活中增加一點寧靜的深度。

讀書

忘了在哪一天，當我終于明白了自己的生命具有不被各種概念事先限定的自由，明白了自己手上，每時每刻都緊握著改變生命質量的權利。那么，我的決斷力就產生了。

沐浴春風，我們為差異而欣喜

我們的生命，很可能一直處于卑微狀態之中，互相搔擾，共同降低。要提升生命的質量，首先必須超拔自己的環境，開拓生命的空間。

超拔和開拓的途徑，就在我們身上，一是用眼睛，二是用腳步。用老話來說，就是“讀萬卷書，行萬里路”，但還要補充一句新話，那就是：“在書和路的中間，為了找到生命的真實，而苦苦思索。”

閑話ERP

功能全面導向還是面向客戶導向？答案當然是后者

《JOEL說軟件》

www.joelonsonware.com

那些有軟件項目方面做得成功的稀有人物當中，有許多人有有機會將自己積累的經驗傳給下一代之前，就很富有并隱退到養魚場垂釣去了。

與此同時，似乎許多軟件開發組織已經遠遠走出了JOEL測試的范疇，而進入復雜的官僚政治動脈化苦斗之中。

如果向上走得更遠的話，作為抽象哲人的你將會沒有氧氣可用的。有時候，聰明的思想家就是不知道適可而止，從而建立起一種包羅萬象的荒謬的宇宙頂級抽象畫面。這些畫面雖然盡善盡美，但就是沒有任何實際的含義。

我把這些人叫做太空架構師，讓他們編寫代碼或者設計程序是非常難做到的，因為他們不會停止對體系結構問題的思考。說他們是太空人，是因為他們所處的層次是如此之高，而超出了有氧氣的空間，我真的不知道他們是如何呼吸的。他們傾向于在真正大型的公司里供職，這種公司能夠供養許多身份極高而對具體業務沒有什么貢獻的非生產性人員。

或許這就是開啟生產效率之門的鑰匙：開了頭就好了。

它花費了我另外15年的時間才意識到，開火與運動的原則就是你如何在現實生活中把事情辦成的策略。你每天都得向前移動一點點，代碼是否蹩腳與充滿故障而沒人想要它是無關緊要的。只要你向前移動而不間斷地編寫代碼與修復故障，時間就會站在你一邊。

代碼編寫不是一般意義上的生產活動。它并不總是居于人員素質的范疇（盡管它可能是），而是一種設計行為。設計指的是一方能夠讓價值提升比經費添加要快的朦朧地界。

就拿一個很小的例子來說，UNIX文化的核心價值被Raymond稱為“沉默是金”，即一個切實成功實現用戶要求的程序，倒是應該什么內容也不輸出。

同樣，UNIX文化很欣賞以文本形式提供的程序。

我經過多年了解到的一件事情是，如果你問人們的問題越多，那么他們越不大可能回答你。

我們會傾聽客戶的聲音與品嘗自己的狗食而致力于改進我們的產品并集中精力關注商業需求，而不是在全國飛來飛去以募集更多的風險投資。

不要讓電子郵件程度或者IM客戶程序處于激活狀態。如果你需要，可以每小時檢查一次電子郵件，但就是不要讓它總是處于運行狀態之中。

如果是一個核心業務函數，那個不管它是什么，都要自己去做。

開辦一家公司？你有一個非常重要的決定要做，因為它關系到你要做的所有其他事情：不管你做其他任何事情，你絕對需要搞清你的處境如何，并相應地調整要做的每件事情，否則禍將至矣。

要是你打算進入一個尚不存在現成競爭者，鎖定與網絡效應的市場，那么最好采用Amazon。

Amazon公司不管什么時候都絕對需要用金錢為時間讓路。

正如我們已經說過的那樣，即使只消除一個進入市場的障礙時，人們就會像潮水一樣涌進來。生活將會好起來，直到別人以汝之道還治汝之身為止。

《掀起XBOX的蓋頭：微軟掀起一場娛樂革命的計劃內幕》

《Opening the Xbox: Inside Microsoft's Plan to Unleash an Entertainment Revolution》

我不是在說.NET沒有什么新內容，而是在說.NET根本就沒有什么內容。

“幻星”的閃光面

你看到了吧，像.NET白皮書這樣的含糊不清的文檔資料的閃光面在于，它們就是一種羅爾赫氏測驗。人們實際上是帶著預先具備的想法去讀這些文檔的，而既然文檔里的如此含混，因此他們就會認為微軟公司在重申他們的想法。

Dave,你太信任他們了，同你比較起來，他們顯得太不仗義了。他們玩的是那種精神交流熱線與報紙占星的騙術。通過向你灌輸不著邊際而毫無意義的空洞理念。你落入他們設下的讓你相信他們能與你進行心靈交流的圈套。

微軟公司制造了自己的萬有引力，通常的規則對他們不起作用。

JOLE測試

1、使用源控制機制嗎？

2、能一步完成連編嗎？

3、每天都做連編嗎？

4、有故障信息數據庫嗎？

5、在編寫新代碼之前修復故障嗎？

6、有最新的進度表嗎？

7、有規格說明書嗎？

8、程序員擁有安靜的工作環境嗎？

9、你用到了你資金能力內可買到的最好工具了嗎？

10、有測試人員嗎？

11、新聘人員在試用期寫代碼嗎？

12、進行走廊可用性測試嗎？

令人遺憾的是，這個時代里，還有太多的人考慮問題還是政治優先。

放棄理想，才能成就現實。

去繁就簡，更要言之有物。

如何改進閱讀的體驗？

使用編號或者符號列表、畫面、圖表、表格，與許多空白的目的在于使閱讀過程顯得“輕松”一些。

博客意義：現代焦灼的心靈，在于恰合人心。

《人月神話：軟件工程散記》

《東軟迷碼——在不平衡規律中向國際化奮進的“大象軍團”》

Neusoft  

Beyond Technoloyg  超越技術的應用智慧

追求個人與社會的共同發展

對人的重視恰恰就是對企業自身負責

我一進你們的園區，就感覺到一種活力，一種生機，一種希望，一個民族必須要有創造性的思維，才有希望。我們的國家需要像你們這樣的一群年輕人，我們民族的希望寄托在你們的身上。——溫家寶

這讓人聯想到一位學者講過的話，相應的產業要有相應的文化作支撐。

為了在企業解決方案領域獲得應有的競爭位置，我們首先注意到中國的企業在實施信息侖過程中最具挑戰的一環就是顧問咨詢隊伍的缺乏，我們經常聽到一句話就是：“我們的企業如果不上ERP就是等死，如果上了ERP就是找死。”實際上，在這個環節中，我們缺少了一個環節，那就是一個強有力的顧問和服務隊伍，能夠真正把技術變成客戶所需要所喜歡的解決方案。

《笛聲何處》

這種與西方戲劇的嚴謹結構判然有別的松散彈性結構，體現了東方美學瀟灑無羈的獨特神韻，也是中國戲曲有趣的生命狀態。

昆曲藝術在其繁榮期的演出方式與我們日常習見的話劇、歌劇演出方式有本質的區別，它并不刻意制造舞臺上的幻覺幻境，而是以參與某種儀式的方式與實際生活駁雜交融。

只有在層戀疊嶂之中，才有巍賬的高峰。

“不到園林，怎知春色如許！”

這種復雜的文化現象和美學現象，從藝術上說，體現了藝術構件對于藝術構架的獨立性，藝術途徑對于藝術目的的獨立性；從思想上說，則體現了氣節、意志、人生風貌對于政治目的的獨立性。

《桃花扇》

孔尚任的這種裁斷和鼾，都是為了實現一種意向：渲染出一種真實而又濃重的歷史氣氛，借以體現出一種江河日下的歷史必然。

但在理性上，作者又明晰地知道，在江河日下的整體局勢下，善良的許諾是無用的和無益的。于是，他就表現了這么一個飲食著大量美好內容必然破滅的過程。高水平的悲劇，并不是一定要觀眾面對著一對情人的尸體而涕淚交流，而是要觀眾在一種無可執拗的歷史必然面前震驚和思索。

時代發展的趨向，首先向第一流的藝術家發出了朦朧的通知。

他們的超逸的態度，評判著歷史功過，交流著離亂之感。

《桃花扇》錯綜復雜的歷史過程，眾多而各別的人物形象，吞吐萬匯的大容量結構，深沉而蒼茫的歷史感嘆，組合成了一種驚人的恢弘氣概。恢弘中籠罩著悲涼，恰似薄暮時分群山間沉重鳴響的古鐘，嗡嗡锽锽。

《打魚沙家》的藝術容量是如此之大；它就以一個蒼老的漁夫和一個嬌憨的女兒，以一幅春江舟行圖，以幾句哽哽咽咽的叮嚀，渲染出了反抗封建專制的英雄們的悲壯美。顯然，這種悲壯美，屬于荒江茅舍，屬于民間，屬于無數草澤英雄。

中國古代戲劇文化史，在地方戲曲的洪流中結束。光輝的傳奇時代所制造的傳奇劇目，已大多化作折子戲，與各種地方戲劇目混為一體了。因此，傳奇時代，也就悄悄地消失在地方戲的汪洋大海中。

什么是愛情

有一天，柏拉圖問老師蘇格拉底什么是愛情？老師就讓他先到到麥田里去，摘一棵全麥田里最大最金黃的麥穗來，期間只能摘一次，并且只可向前走，不能回頭。 

　　柏拉圖于是按照老師說的去做了。結果他兩手空空的走出了田地。老師問他為什么摘不到？ 

　　他說：因為只能摘一次，又不能走回頭路，期間即使見到最大最金黃的，因為不知前面是否有更好的，所以沒有摘；走到前面時，又發決總不及之前見到的好，原來最大最金黃的麥穗早已錯過了；于是我什么也沒摘。 

　　老師說：這就是“愛情”。 

　　之后又有一天，柏拉圖問他的老師什么是婚姻，他的老師就叫他先到樹林里，砍下一棵全樹林最大最茂盛、最適合放在家作圣誕樹的樹。其間同樣只能砍一次，以及同樣只可以向前走，不能回頭。 

　　柏拉圖于是照著老師的說話做。今次，他帶了一棵普普通通，不是很茂盛，亦不算太差的樹回來。老師問他，怎么帶這棵普普通通的樹回來，他說：“有了上一次經驗，當我走到大半路程還兩手空空時，看到這棵樹也不太差，便砍下來，免得錯過了后，最后又什么也帶不出來。” 

　　老師說：“這就是婚姻！” 

　　人生就正如穿越麥田和樹林，只走一次，不能回頭。要找到屬于自己最好的麥穗和大樹，你必須要有莫大的勇氣和付出相當的努力。

《軟件開發的科學與藝術》

微軟公司華人專家鼎力之作

全面總結軟件開發思想，深入解析軟件開發過程

新產品的產生過程

（1）新產品項目的提議

（2）市場分析預測

（3）技術可行性分析

（4）產品研發實施步驟

（5）高層論證和審批

（6）項目確立和執行

（7）產品開發

微軟的產品團隊原則

小型并具有多功能的團隊

角色互相依賴并分担責任

具有深厚的技術和商業敏銳性

關注于完成產品

有明確的工作目標

用戶積極參與

共享產品遠景

人人參與設計

努力從過去的產品中學習

共享產品總體管理和決策

所有團隊成員都在同一個地方工作

大團隊的工作方式類同于小團隊

People are most productive working in small teams with tight budgets, time deadlines, and the freedom to solve their own problems. 

人們在那些具有嚴格的預算和時間限制，并且能夠自由地解決他們自己問題的小團隊中工作時將更富有生產力。

——比爾·蓋茨

在微軟的產品團隊中，權威僅僅來自于知識，而不是來自于職位。

各個團隊的角色及主要目標

產品管理：確定產品的遠景，獲取并確定用戶的需求，開發并維護商業安全，滿足用戶的需求

項目管理：制定開發功能規范，在團隊內進行溝通和協商，維持產品進度并報告產品狀態，保證能夠盡快盡好地在產品約束條件下發布產品

軟件開發：開發出滿足設計規范和用戶要求的產品

軟件測試：開發測試策略和計劃，保證在解決了所有已知問題后再發布產品

用戶培訓：保證使用文檔要全部很清楚地寫出來，提高用戶使用產品的技能，保證大多數用記都能夠充分利用產品的功能

后勤管理：保證產品能夠平穩地發展

微軟軟件開發的過程模型

1、指導原則：

軟件的開發過程是由目標驅動的，而不是由具體任務驅動的

開發過程的各個里程碑（Milestones）都是顯而易見的

基于版本的發布

進度表是基于風險驅動來制定的

依靠完全的團隊合作來完成

嚴格管理，保證質量

2、開發過程原則

在制定進度表時，要明白我們要面對的是一個不確定的將來

通過有效的風險管理使不確定性因素達到最少

定期的編譯和快速的測試來使產品的穩定性和可用性達到最佳

產品的開發周期要快速

通過創造性來實現功能的改進而不增加資源

建立固定的進度表

使用小團隊來并行工作，以達到最多的同步點

將一個大的產品分割成一些易于管理的、可以在幾個月之內完成發布的小部分

要避免任何不必要的功能擴展

使用概念證明（Proof-of-Concept）的技術原型來做開發前的測試

要本著零缺陷的態度（一般來說，一個軟件產品不可能沒有缺陷，這里的零缺陷是指產品發布時沒有影響產品功能和使用的缺陷）

在階段回顧時要集中于功能和產品的改進，而不是挑任何人的過失

產品開發團隊的主要組成部分

1、產品管理團隊Product Management Team

需要清楚地知道用戶的需求，并詳細地給出定義

我們要確保新產品能夠為我們帶來利潤

控制用戶的期望值

設計產品的特性和進度表

負責管理市場、推銷以及公共關系

2、項目管理團隊Program Management Team

操縱著產品的開發過程

管理產品的細節

促進團隊內部的交流和商議

保證產品的開發進度

控制全局，并做出一些折中決定

3、軟件開發團隊

具體說明物理設計的功能

4、軟件測試團隊Software Testing Team

測試管理Test Management 一致性測試 Compliance Testing

配置測試Configuration Testing 集成測試Integration Testing 強力測試 Stress Testing

承担的角色：盡量找出所有的BUG、寫出測試規范和測試計劃

微軟軟件開發過程的階段

1、想法和意圖的批準里程碑Vision/Scope Approved Milestone

2、產品計劃的通過里程碑Project Plan Approved Milestone

3、范圍完成/第一次使用里程碑Scope Complete/First Use milestone

4、發布里程碑Release Milestone

想法和意圖批準里程碑

提出一個長遠目標Long-Range Vision

制定短期的目標Shorter-Range Scope

新產品的機會和風險Opportunities and Risks

假設Assumptions

約束Constraints

項目資源Project Resources

時間和工作強度Time and Effort for Planning Phase

產品計劃的通過里程碑

項目陳述Project Deliverables

功能和優先級Features and Priorities

項目風險Risks

發布日期Ship date

商業要求Business requirements

產品功能規范Functional Specification

產品計劃Project plan

產品進度表Project schedule

范圍完成/第一次使用里程碑

功能規范化 All features built to special

使用和估計產品Using and evaluating the product, even if testing is not complete

用戶試用Customers using the product for the first time under beta conditions

基礎要求的配置Deployment of infrastructure required for first use

配置計劃細節Deployment plan details

發布階段

測試計劃Test Plan、發布內部版本1Internal Release 1、發布內部版本2Internal Release 2、

發布內部版本n Internal Release n、發布Alpha版本、發布各Beta版本、發布候選版本Release Candidates、發布包裝好的正式產品Golden Release這幾個階段

產品穩定和所有問題的解決Product stability and resolutionof all issues

用戶接受產品Customer acceptance of the product

轉移長期管理和支持的所有權Transfer of ownership for long-term management and support

關注下一版本Change in team focus to the next release

寫好代碼的十個秘訣

一般來說，一流代碼都具備以下特性：

1、穩定可靠Robustness

2、可維護并簡潔Maintainable and Simple Code

3、高效Fast

4、簡短Small

5、共享性Reusable

6、可測試性Testable

7、可移植性Portable

十大秘訣

1、百家之長歸我所用Follow Basic Coding Style

2、取個好名字Use Naming Conventions

3、凌波微波，未必摔跤Evil goto's Maybe Not...

4、先發制人，后發制于人Practice Defensive Coding

5、見招拆招，滴水不漏Handle The Error Cases: They Will Occur!

6、熟習劍法刀術，所向無敵Learn Win32 API Seriously

7、雙手互搏，無堅不摧Test, but don't stop there

8、活用斷言Use, don't abuse, assertions

9、草木皆兵，不可大意 Avoid Assumptions

10、最高境界，無招勝有招Stop writing so much code

軟件測試方法和輔助工具

1、覆蓋性測試Coverage Testing

單元測試Unit Test

功能測試Function Test

提交測試Check-in Test

基本驗證測試Build VerificationTest

回歸測試Regression Test

2、使用測試Usage Testing

配置測試Configuration Test

兼容性測試Compatibility Test

強力測試Stress Test

性能測試performance Test

文檔和幫助文件測試Documentation and Help File Test

Alpha和Beta測試Alpha and Beta Test

(1)白盒測試While Box Testing

(2)黑盒測試Black Box Testing

接受性測試Acceptance Testing

Alpha/Beta測試

菜單/幫助測試Menu/Help Testing

發生測試Release Testig

回歸測試Regression Testing

RTM測試Release to Manufacture Testing

功能及系統測試Function&System Testing——規范驗證Specification Verification、正確性Correctness、可用性Usability、邊界條件Boundary Condition、性能Performance、強力測試Stress、錯誤恢復Error Recovery、安全性Security、兼容性Compatibility、軟件配置Configuration、軟件安裝Installation

手工測試Manual Testing、自動測試Automation Testing

保證軟件功能的定義有意義Make sure the feature definitions make sense

學會說不Learn to say "no" if you strongly feel so

項目經理定義的規范也是可以改變的PM's spec is changeable, too

堅持正確的看法Insist what is right

職業化Professionalism

向項目經理和開發人員反饋Give PM/Dev feedbacks 

[新一篇] 評《臺灣首任巡撫劉銘傳》

[舊一篇] 中國智慧-微軟亞洲研究院院長話題摘