高質量自然是程序員的技術追求，也是職業道德的要求。

寧可進度慢些，也要保證每個環節的質量，以圖長遠利益。

人員管理，項目管理，可行性與需求分析，系統設計，程序設計，測試。

軟件開發中的三種基本策略：“復用”、“分而治之”、“優化——折衷”。

進步是應該的，但不進步則是可恥的。

在一個新系統中，大部分的內容是成熟的，只有小部分內容是創新的。

面向對象（Object Oriented）學者的口頭禪就是“請不要再發明相同的車輪子了” 。

將具有一定集成度并可以重復使用的軟件組成單元稱為軟構件(Software Component)。

分而治之是指把一個復雜的問題分解成若干個簡單的問題，然后逐個解決。

優化工作不是可有可無的事情，而是必須要做的事情。當優化工作成為一種責任時，程序員才會不斷改進軟件中的算法，數據結構和程序組織，從而提高軟件質量。

 一些不正確的觀念：
觀念之一：我們擁有一套講述如何開發軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發中遇到的任何問題。
客觀情況：好的參考書無疑能指導我們的工作。充分利用書籍中的方法、技術和技巧，可以有效地解決軟件開發中大量常見的問題。但實踐者并不能因此依賴于書籍，這是因為：（1）現實的工作中，由于條件千差萬別，即使是相當成熟的軟件工程規范，常常也無法套用。（2）軟件技術日新月異，沒有哪一種軟件標準能長盛不衰。祖傳秘方在某些領域很吃香，而在軟件領域則意味著落后。

觀念之二：我們擁有最好的開發工具、最好的計算機，一定能做出優秀的軟件。
客觀情況：良好的開發環境只是產出成果的必要條件，而不是充分條件。如果擁有好環境的是一群庸人，難保他們不干出南轅北轍的事情。

觀念之三：如果我們落后于計劃，可以增加更多的程序員來解決。
客觀情況：軟件開發不同于傳統的農業生產，人多不見得力量大。如果給落后于計劃的項目增添新手，可能會更加延誤項目。因為：（1）新手會產生很多新的錯誤，使項目混亂。（2）老手向新手解釋工作以及交流思想都要花費時間，使實際開發時間更少。所以科學的項目計劃很重要，不在乎計劃能提前多少，重在恰如其分。如果用“大躍進”的方式奔向共產主義，只會產生倒退的后果。

觀念之四：既然需求分析很困難，不管三七二十一先把軟件做了再說，反正軟件是靈活的，隨時可以修改。
客觀情況：對需求把握得越準確，軟件的修修補補就越少。有些需求在一開始時很難確定，在開發過程中要不斷地加以改正。軟件修改越早代價越少，修改越晚代價越大，就跟治病一樣道理。

程序設計是自由與快樂的事情，不要發誓忠于某某主義而自尋煩惱。

失敗的技巧通常是技倆.

開發人員應該意識到：所有的錯誤都是嚴重的，不存在微不足道的錯誤。這樣才能少犯錯誤。

管理的目的是讓大家一起把工作做好，并且讓各人獲得各自的快樂和滿足。當一個組織被出色地領導時，雇員甚至不知道他們已被領導。在項目完成時，他們會自豪地說：“看看我們通過努力取得的成績吧”。所以管理者不能老惦記著自己是一個官，而應時刻意識到自己是責任的主要承擔者。

真正的程序員都有如下秉性：
一、誠實
程序員在學習與工作期間幾乎天天與機器打交道，壓根就沒有受欺騙或欺騙人的機會。勤奮的程序員在調試無窮多的程序Bug時，已經深深地接受了“誠實”的教育。不誠實的人，他肯定不想做、也做不好程序員。
二、簡單——實用主義
目前即使最先進的計算機也不具備智能，程序員的基本工作就是把復雜的問題轉化為計算機能處理的簡單的程序。如果一個問題復雜到連程序員自己都不能理解，他就無法編出程序讓更笨的計算機來處理。所以程序員信奉“簡單——實用”主義。
三、愛憎分明
程序員大都喜歡技術挑戰，不喜歡搞測試與維護。高水平的程序員喜歡與高水平的程序員一起工作，因為他們怕“與臭棋佬下棋，棋越下越臭”。程序員大都厭惡拉幫結派、耍政治手腕。不信，數一數你認識的程序員，有幾個是黨派人士？
四、工作單調但不乏味
有人問編程大師：“程序設計的真正含義是什么 ？”
大師回答說：“餓了的時候就吃，困的時候就睡，只要時機恰當就進行程序設計。”
其實程序員的生活和工作已融為一體，盡管單調卻不乏味，還能獨享孤獨。有詩為證：
                              我編程三日
                              兩耳不聞人聲
                              只有硬盤在歌唱

結論：優秀的程序員沒有理由不讓人喜歡，他們遠比怪僻來得可愛。

微軟公司在選擇經理人員時，總是把他們的技術知識和運用技術去賺錢的能力放在首位。

比蓋曾這樣描述聰明：人聰明人一定反應敏捷，善于接受新事物。他能迅速進入一個新領域，給你一個頭頭是道的解釋。他提出的問題往往一針見血、擊中要害。他能及時掌握所學知識，并且博聞強記，他能把本來認為互不相干的領域聯系在一起使問題得到解決。他富有創新精神與合作精神……

好的程序經理應該具備以下幾個條件：
一、技術水平是程序員隊伍中的最高級別
每個程序員骨子里頭都有一股傲氣，如果你不能技壓群雄，他們就不會聽你指揮。一個技術水平較差的人被任命為程序經理真是個悲劇，就象一個略有權勢的太監，表面上有人對他點頭哈腰，背后卻被人鄙視。
二、能做最多且最難的工作
程序經理編程要快且好。別人要干一天的活，他半天就能做完，這樣才會有精力去搞管理。程序經理應負責系統分析、系統設計這類最難的開發工作，并指導不同水平的程序員把各自的工作做好。如果人手不夠，程序經理要能同時干幾個人的活。
三、有人格魅力
軟件開發是智力創作過程，你不能指望僅通過執行規章制度來產生好的作品。很多軟件公司的程序經理都不是管理專業出身的，他們也不可能為了搞好管理而成天玩弄心機。技術出色的程序經理一般少有心術不正的，所以管理的重點應是“以身作則”、“公正待人”。如果程序經理在上班時趴在桌上睡覺，其他程序員也會這樣干。如果程序經理發現有兩個程序員趴在機器旁睡覺，不能只對其中一個大聲吼叫：“你一編程就想睡覺，看看人家，在睡覺時都想著編程。”
如果管理者沒有人格魅力，就沒有人信服你，團隊就不會有凝聚力，烏合之眾不可能開發出優秀的軟件。
結論：一個有活力的軟件公司的各級經理都不會這樣感嘆，“因為我啥也不會干，所以只好當領導。”

在軟件領域，技術的力量是無窮的，一天之內就可使整個產業發生巨變。

好兵好將都不是天生的，是后天練出來的；既要學會冷靜地分析問題，又要充滿激情地去工作。

等級制度并不限制自由和民主，它能讓自以為聰明絕頂、誰也不服的人們懂得如何合作與奮斗。就象有了一架梯子，每個人才有機會爬上墻頭摘下那向往已久的野花。當梯子散成一堆木棍時，只可能造就幾個賣炭翁。

把技術水平分為四級，第一級最低，第四級最高。第一級技術水平的程序員主要考核編程基本功，要求質量合格（他們主要來自剛畢業的大學生）。第二級技術水平的程序員編程質量要高，做過幾個軟件項目，有數年的工作經驗，并能指導新手的工作。第三級技術水平的程序員主要考核系統分析與系統設計的能力，要求其技術有足夠的深度和廣度。第四級技術水平的程序員是成功的軟件產品的設計師，他不僅技術超群，并且能使技術轉化為有價值的商品。
把管理（這里僅指軟件業務的管理，不考慮行政事務）水平也分成四級。第零級最低，第三級最高。第零級管理水平的人沒有管理職務，就是普通員工。第一級管理水平的人是開發小組的組長，可帶領幾名程序員工作。第二級管理水平的人是項目經理。第三級管理水平的人決定某些產品是否要開發，以及如何去占領市場。

當我們在工作中碰到挫折時，先要冷靜地分析問題（事出有因哪），找出問題的內因與外因。內因是最主要的，應該予以最先解決。

“迷信”是傻子碰到騙子的結果。

為了不讓自己“傻”，善良的人們應該用腦子去多學一些知識，努力讓自己來把握命運，不要急著把一生托給某個人或某個組織。

上天不可能賦于一個人太多的優點，以致于他沒有表示謙虛的余地。

我們在求學時可能太功利太挑剔，導致知識結構非常單薄，只怕到了晚年也成不了大器。當程序員擅長技術時，還要時刻留意彌補自己并不擅長的非技術才能。揚長補短才能提高綜合素質。

人是最有價值的資源。

進度安排并不見得一定要符合邏輯順序。應盡可能地先做技術難度高的事，后做難度低的事。也就是辛苦在前，輕松在后。

里程碑就象心靈的燈塔，使忙碌的人群不混亂，不迷失方向。

人在做一件事情時，由于存在很多不確定的因素，一般不可能100% 地達到目標。假設平常人做事能完成目標的80%。如果某個人的目標是100分，那么他最終成績可達80分。如果某個人的目標只是60分，那么他最終成績只有48分。

如果沒有高目標，人的墮落就很快。如果沒有“零缺陷”的質量目標，也許缺陷就會成堆。

軟件是如此的靈活，如果沒有規范來制約，就容易因無序的喜好而導致混沌；但規范如果太嚴密了，就會扼殺程序員生機勃勃的創造力。

簡潔是一種美!

每當我們沉迷于短期利益不思進取時，應該好好回憶童年時代那些偉大的抱負，給自己一些激勵。

“人分四類——人物，人才，人手，人渣。”

我曾得到很多炫目的榮譽，但學生時代的榮譽只是一種鼓勵，并不是對我才能和事業的確認。

“當你沒法扶一個人上馬時，也許應該拉他下馬”------李敖

為什么軟件系統分析員的工資要比普通程序員高？就是因為需求分析困難嘛。

如果您學會了客觀、科學的可行性分析，在作決策時就要果斷。

系統設計的優劣在根本上決定了軟件系統的質量。

文學中有科學，音樂中有數學，漫畫中有現代數學的拓撲學。漫畫家可以“幾筆”就把一個人畫出來，不管怎么美化或丑化，就是活像。為什么？因為那“幾筆”不是別的，而是拓撲學中的特征不變量，這是事物最本質的東西。               -------楊叔子

體系結構是軟件系統中最本質的東西。

  內聚（Cohesion）是一個模塊內部各成分之間相關聯程度的度量。耦合（Coupling）是模塊之間依賴程度的度量。

技術進步最快也快不過人們欲望的增長。

對象（Object）是類（Class）的一個實例（Instance）。

醫生可以把他的錯誤埋葬在地下了事，但程序員不能。我們必須要學會測試與改錯，并且把測試與改錯工作做好。

測試并不僅是個技術問題，更是個職業道德問題。

測試只能證明缺陷存在，而不能證明缺陷不存在。

改錯是個大悲大喜的過程，一天之內可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。

程序中的錯誤只有開發者自己才能找出并改掉。如果因畏懼而拖延，會讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。

編程大師曾說：“哪怕程序只有三行長，總有一天你也不得不對它維護。”