《軟體工程思想》是一本篇幅不大的書，近日重讀一遍。嬉笑怒罵中感受到了一些難以言表的想法，惟有摘錄原文中的妙語，與各位同樂：
我偶爾也擔心此書寫得太膚淺，內容少得可憐。就象乙隻雞在水裡撲騰了幾下，並不能產生美味的雞湯。但是如果您化了幾分鐘時間翻閱本書的任意章節，您馬上就願意再化幾個小時一口氣讀完全書，並且樂得直拍桌子：「好！很好！非常好！」軟體開發過程中的坎坎坷坷，彷彿只是人臉的凹凸不平，用熱水*巾一把就可抹平。讓我們高舉程式主義、軟體工程思想的偉大旗幟，緊密團結在以microsoft為核心的軟體公司周圍，沿著比爾·蓋茨的生財之道，不分白天黑夜地程式設計，把建設有中國特色的軟體產業的偉大事業全面推向21世紀。
軟體供需雙方的代表能在餐桌上談笑風生，歸功於第一線開發人員的辛勤工作。
最早出現的軟體工程模型是線性模型（又稱瀑布模型）。線性模型太理想化，太單純，已不再適合現代的軟體開發模式，幾乎被業界拋棄。偶而被人提起，都屬於被貶物件，未被留一絲惋惜。但我們應該認識到，「線性」是人們最容易掌握並能熟練應用的思想方法。當人們碰到乙個複雜的「非線性」問題時，總是千方百計地將其分解或轉化為一系列簡單的線性問題，然後逐個解決。乙個軟體系統的整體可能是複雜的，而單個子程式總是簡單的，可以用線性的方式來實現，否則幹活就太累了。線性是一種簡潔，簡潔就是美。當我們領會了線性的精神，就不要再呆板地套用線性模型的外表，而應該用活它。
當我們歡度國慶時，要搞清楚祖國遠不止50歲，我們今天享用到的財富還有上下五千年人民的貢獻。
無論是什麼好方法，貴在理解與靈活運用，而不可當成靈丹妙藥，不象「吃了腦**或腦白金，就能使一億人先聰明來」。
我們經常會聽到有經理頭銜的人在高談闊論：「程式設計我不會，做個專案還不easy？派個人去搞系統分析，回頭再叫幾個程式設計師把需求譯成程式，不就ok了嗎？」——不懂英語的人准以為easy和ok是貶義詞。
有人問乙個數學家，乙個物理學家和一名程式設計師：「乙個盒子有幾個面？」
數學家回答說：「有六個面，因為盒子是長方體。」
物理學家回答說：「有12個面，分為6個外表面和6個內表面 。」
程式設計師回答說：「只有兩個面，裡面放電路板和硬碟，外面放顯示器和鍵盤。」
程式經理的選拔是不容草率的事。不象有些事業單位，只要政治口號喊得勤快、能左右逢緣不犯錯誤就可混個領導噹噹。也不象一些官僚機構，只有兩個人的辦公室也要設正主任和副主任。如果碰巧正主任姓傅，副主任姓鄭，還會鬥個沒完沒了。
乙個技術水平較差的人被任命為程式經理真是個悲劇，就象乙個略有權勢的太監，表面上有人對他點頭哈腰，背後卻被人鄙視。
如果程式經理發現有兩個程式設計師趴在機器旁睡覺，不能只對其中乙個大聲吼叫：「你一程式設計就想睡覺，看看人家，在睡覺時都想著程式設計。」
假如能回到中學時代，我希望能把文科學好。那時侯盛傳「學好數理化，走遍天下都不怕」。我讀中學時很無知，鄙視一切文科，現在後悔莫及。高考語文成績54分（只比我的期望值低6分）。寫作文的最高目標就是不逃題，考試前我總是反覆祈禱：我沒幹過壞事，保佑我作文不逃題吧！上大學的第一天我竟然無法用普通話說出「去洗澡怎麼走」，只好晃動澡票與輔導員打啞語。中學的歷史、地理課也被我糟踏了，考試時只會填寫任課老師某年某月某日在我家鄉英勇就義，比誰的成績更接近零分。更讓我沮喪的是，這些行徑都不是我發明的，我頂多是個跟屁蟲而已，一點回憶的自豪感都沒有。
中國經歷了很多打鬥、整人的革命，卻沒有一次趕上工業革命。在如今計算機橫行的形勢下，我們不能再掉隊了。
做專案計畫，如同給乙個待出生的嬰兒寫傳記那樣困難。如果允許專案結束後再寫計畫，那就輕鬆多了，並且可以100% 地準確。
開發人員只有在自己思路清晰時才可能寫出讓別人能理解的程式。程式設計時還要注意不可濫用技巧，應該用自然的方式程式設計。我們的確不知道自己的得意之舉究竟是錦上添花，還是畫蛇添足。就象蒸出一籠饅頭，在上面插一朵鮮花，本想弄點詩情畫意，卻讓人誤以為那是一堆熱氣騰騰的牛糞。
事實上，我可以在5分鐘之內說清楚三年來讀博所做的工作，根本用不著寫100多頁的博士**。我是在臨近畢業時，才發覺自己完全不適合讀博士學位。將來工作後，我一定要好好程式設計，重新做人。
不久前我回到西北那所讀了六年多的大學，驚奇地發現校園裡房前屋後長滿了待收割的小麥！這所大學是從事電子科技的，種小麥幹啥呀？朱總理曾講過：「目前國家糧食充足，再來三年自然災害也不怕。」現在國泰民安，似乎用不著「深挖洞，廣積糧」。我素知學校提創勤儉節約、自力更生，但與其種小麥還不如種蔬菜呢。老同學告訴我，種小麥是為了應付「211」工程（為21世紀選拔100所重點大學）的檢查團，因為「211」工程有較高的綠化指標。偏偏檢查趕在冬天，那時的西北極難長草。我那所大學本來就人多地少，地上一長草馬上就會被談戀愛的學生給折磨死。一到冬天，整個校園就光禿禿一片。用小麥綠化校園可謂千古絕筆，檢查團的那些權貴人士早已五穀不分，豈知所見的「草坪」乃是麥田。
如果可行性分析表明做某件事的成功率是10%，失敗率是90%，倘若該事情的意義非常大，決策者也許會一拍腦袋：「豁出去，幹！」於是這世界就多了乙份極喜與極悲。
聯想集團領導人柳傳志曾說：「沒錢賺的事我們不幹；有錢賺但投不起錢的事不幹；有錢賺也投得起錢但沒有可靠的人選，這樣的事也不幹。」柳傳志為決策立了上述準則，同時也為可以行性分析指明了重點。
如果公司的風水不好，會有很多莫名其妙的管理費。每戳乙個紅豔豔的公章都要化一把鈔票。
有一次我拜訪了北京大學一位研究經濟學的朋友。這個年青人，還是個黨員，竞然這麼說：「我最近在研究國內明星企業的興衰問題，我發現了乙個規律，明星企業一旦被**領導人視察過，它就忘了自己是誰，就會做些走向死亡的蠢事。」
有句名言：「人分四類——人物，人才，人手，人渣。」如果乙個軟體公司裡上述四類人齊全了，那麼最好的分工是讓「人物」當領導，「人才」做第一線的開發人員，「人手」做行政人員，「人渣」負責行賄。
從碩士讀到博士出頭，這六七年時間，真本事沒學多少，倒學會「眼高手低」甚至「弄虛作假」；畢業時驀然回首，發覺青春已被虛度，心靈已呈老態，唯有長嘆短噓，強把自負作自信。
打破水缸的小孩子很多，但並不見得就會有司馬光的業績。
我從實驗室挖來一位聰明絕頂的師弟做技術夥伴（他的頭明顯比我的大，估計其腦容量至少是我1.5倍）。我曾經以師兄的身份為他洗過一雙襪子，他因此覺得我是個好人。
這是廢話，如果投資者都是內行的話，就不用請人分析了。你要寫出讓農民企業家看得懂的可行性分析報告，才叫有水平。
如果客戶本身就懂軟體開發，能把需求說得清清楚楚，這樣的需求分析將會非常輕鬆、愉快。如果客戶全不懂軟體，但信任軟體開發方，這事也好辦。分析人員可以引導客戶，先闡述常規的需求，再由客戶否定不需要的，最終確定客戶真正的需求。最怕的就是「不懂裝懂」或者「半懂充內行」的客戶，他們會提出不切實際的需求。如果這些客戶甚至覺得自己是上帝的爸爸，那麼溝通和協商都會很困難。
據歷史記載，沒有乙個軟體的需求改動少於三次。唯一只改動需求兩次的客戶是個死人。這個可憐的傢伙還是在運送第三次需求的路上被車子撞死的。[cline 1995]
有個外星人間諜潛伏到地球刺探情報，它給上司寫了乙份報告：「主宰地球的是車。它們喝汽油，靠四個輪子滾動前進。嗓門極大，在夜裡雙眼能射出強光。……有趣的是，車裡住著一種叫作『人』的寄生蟲，這些寄生蟲完全控制了車。」
如果您學會了客觀、科學的可行性分析，在作決策時就要果斷，要學習熱戀中的這個年青人——「倒底行還是不行？行就結婚，不行就離婚。」
就象「一切帝國主義都是紙老虎」那樣可以斷定「差的系統設計必定產生差的軟體系統。」所以我們要努力保證系統設計「根正苗紅」，把一切左傾、右傾的設計思潮消滅在萌芽狀態。
「天下西湖三十六，最美是杭州」，千年前蘇*坡大學士對西湖精采絕倫的系統設計，使杭州榮公升為「天堂」，讓後人只剩下讚嘆和破壞的份了。
象人類追求心靈美和外表美那樣，軟體系統也追求（內在的）功能強大和（外表的）介面友好。但隨著生活節奏的加快，人們已少有興趣去品味深藏不露的內在美。如果把unix系統比作是健壯的漢子和婦人，那麼windows系統就象嫵媚的小白臉和狐狸精。
如果不想讓壞事傳播開來，就應該把壞事隱藏起來。為了盡量避免某個模組的行為去干擾同一系統中的其它模組，在設計模組時就要注意資訊隱藏。應該讓模組僅僅公開必須要讓外界知道的內容，而隱藏其它一切內容。
美國也許是世界上醜聞最多的國家，因為它追求民主，不懂得「隱藏資訊」。但美國又是軟體產業最發達的國家，模組化設計的方法都是美國人倡導的，他們應該很懂得「隱藏信
息」。真是前後矛盾，這些美國佬！
在計算機速度日新月異的今天，為什麼還需要高效率的程式？因為我們的雄心與能力是一起增長的，技術進步最快也快不過人們慾望的增長。
當年國民黨的文人為了對抗***的《沁園春·雪》，特意請清朝遺老們寫了一些對仗工整的詩，請蔣介石過目。老蔣看了氣得大罵：「娘希匹，全都有一股棺材裡腐屍的氣味。」
有不少人程式設計時用拼音給函式或變數命名，這樣做並不能說明你很愛國，卻會讓用此程式的人迷糊（很多南方人不懂拼音，我就不懂）。
這好比乙個人在森林裡，看到樹上釘著一塊「危險」的大牌子。但危險到底是什麼？樹要倒？有廢井？有野獸？除非告訴人們「危險」是什麼，否則這個警告牌難以起到積極有效的作用。難以理解的斷言常常被程式設計師忽略，甚至被刪除。[maguire 1993]
我們這一群博士生三年來盡幹些自欺欺人的事，到畢業時學問既不深也不博。個個意志消沉，老氣橫秋。長此以往，總有一天招聘會的大門前將貼出標語「博士與狗不得入內」。
改錯是個大悲大喜的過程，一天之內可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過上萬個程式錯誤，那麼少男少女們不必經歷失戀的挫折也能變得成熟起來。
大學科研機構裡的軟體維護工作恐怕是做得最差的了。幾乎每一批新的研究生都會把畢業生留下的軟體臭罵一通，然後全部推到重做。到他畢業該走時，就輪到別人罵他的工作了。如此輪迴，最終沒有什麼成果留下。
林銳的《軟體工程思想》妙語錄
我偶爾也擔心此書寫得太膚淺，內容少得可憐。就象乙隻雞在水裡撲騰了幾下，並不能產生美味的雞湯。但是如果您化了幾分鐘時間翻閱本書的任意章節，您馬上就願意再化幾個小時一口氣讀完全書，並且樂得直拍桌子 好！很好！非常好！軟體開發過程中的坎坎坷坷，彷彿只是人臉的凹凸不平，用熱水 巾一把就可抹平。讓我們高舉程式...
林銳的軟體工程 讀書心得
林銳的軟體工程書還是不錯的，最近讀完了他的 軟體工程一書，其實是他提出的一套基於 等理論剪裁的 整合軟體開發過程，有不少模版 下面筆記重點的過程，並加以改進之 分四個階段 營銷過程 這個過程主要是產品的立項，創意，與客戶訂合同，投票，宣傳等 產品構思和調研 產品經理負責產品構思，首先要想清楚 產品有...
林銳的軟體工程 讀書心得
林銳的軟體工程書還是不錯的，最近讀完了他的 軟體工程一書，其實是他提出的一套基於 等理論剪裁的 整合軟體開發過程，有不少模版 下面筆記重點的過程，並加以改進之 分四個階段 營銷過程 這個過程主要是產品的立項，創意，與客戶訂合同，投票，宣傳等 產品構思和調研 產品經理負責產品構思，首先要想清楚 產品有...