編程是一門藝術嗎
作者的觀點：水平高到一定程度后，干啥事都能感受到“藝術”，編程也不例外。但在技術行業，人們通常認為“藝術”是隨心所欲、不可把握的東西。如果
程序員都把編程當成“藝術”來看待，準會把公司老板嚇昏過去。
大部分人開發軟件是為了滿足客戶的需求，而不是為了自己享受。本書（《高質量程序設計指南——C++/C語言》）提倡規范化編程。規范化能夠提高質量與效率，最具實用價值，盡管它在一定程度上壓抑了“藝術”。編程藝術是人們對高水平程序創作的一種感受，但只可意會，不可言傳，不能成為軟件公司的一個指導方針。
編程時應該多使用技巧嗎
作者的觀點：就軟件開發而言，技巧的優點在于能另辟蹊徑地解決一些問題，缺點是技巧并不為人熟知。若在程序中使用太多的技巧，可能會留下錯誤隱患，別人也難以理解。一個局部的優點對整個系統而言是微小的，而一個錯誤則可能對整個系統是致命的。我建議用自然的方式編程，不要濫用技巧。我們有時的確不知道自己的得意之舉究竟是錦上添花，還是畫蛇添足。就像蒸出一籠饅頭，在上面插一朵鮮花，本想弄點詩情畫意，卻讓人誤以為那是一堆熱氣騰騰的牛糞。
小時候讀的《狼三則》故事啟示我們，失敗的技巧被諷刺為“伎倆”。當我們編程時無法判斷用的是技巧還是伎倆的情況下，那就少用?！顿u油翁》的故事又告訴我們“熟能生巧”，表明技巧是自然而然產生的，不是賣弄出來的。
換更快的計算機還是換更快的算法
如果軟件運行較慢，是換一臺更快的計算機，還是設計一種更快的算法？
作者的觀點：如果開發軟件的目的是為了學習或是研究，那么應該設計一種更快的算法。如果該軟件已經用于商業，則需謹慎考慮。若換一臺更快的計算機能解決問題，則是最快的解決方案。改進算法雖然可以從根本上提高軟件的運行速度，但可能引入錯誤并延誤進度。
技術狂毫無疑問會選擇后者，因為他們覺得放棄任何可以優化的機會就等于犯罪。類似的爭議還有：是買現成的程序，還是徹底由自己開發？技術人員和商業人士常常會有不同的決策。
錯誤是否應該分等級
微軟的一些開發小組將錯誤分成以下4個等級（Cusumano, P354～P355）。
一級嚴重：錯誤導致軟件崩潰。
二級嚴重：錯誤導致一個特性不能運行并且沒有替代方案。
三級嚴重：錯誤導致一個特性不能運行但有替代方案。
四級嚴重：錯誤是表面化的或是微小的。
作者的觀點：將錯誤分等級的好處是便于統計分析，僅此而已。但上述分類帶有較重的技術傾向，并不是普遍適用的。假設某個財務軟件有兩個錯誤：錯誤A使該軟件死掉，錯誤B導致工資計算錯誤。按上述分類，錯誤A屬一級嚴重，錯誤B屬二級嚴重。但事實上B要比A嚴重。工資算多了或者算少了，將會使老板或員工遭受經濟損失。而錯誤A只是使操作員感到厭煩，并沒有造成經濟損失。再例如航空軟件操作手冊寫錯了，按上述分類則屬四級嚴重，但這種錯誤可能導致機毀人亡，難道還算微小嗎？
開發人員應該意識到：所有的錯誤都是嚴重的，不存在微不足道的錯誤。只有這樣才能少犯錯誤。
一些錯誤的觀念
錯誤觀念之一：我們擁有一套講述如何開發軟件的書籍，書中充滿了標準與示例，可以幫助我們解決軟件開發中遇到的任何問題。
作者的觀點：好的參考書無疑能指導我們的工作。充分利用書籍中的方法、技術和技巧，可以有效地解決軟件開發中大量常見的問題。但實踐者并不能因此依賴于書籍，這有如下兩個原因。
?。?）在現實中，由于工作條件千差萬別，即使是相當成熟的軟件工程規范，也常常無法套用。
?。?）軟件技術日新月異，沒有哪一種標準能長盛不衰。祖傳秘方在某些領域很吃香，而在軟件領域可能意味著落后。
錯誤觀念之二：我們擁有充足的資源和經費，可以買最好的設備，一定能做出優秀的軟件產品。
作者的觀點：大公司經常有這樣的心態。良好的開發環境只是產出成果的必要條件，而不是充分條件。如果擁有好環境的是一群庸人或者是一群勾心斗角的聰明人，難保他們不干出南轅北轍的事情。
錯誤觀念之三：如果進度落后于計劃，可以增加更多的程序員來解決問題。
作者的觀點：軟件開發不同于傳統的農業生產，人多不見得力量大。如果給落后于計劃的項目增添新手，可能會更加延誤項目，原因如下。
?。?）新手會產生很多新的錯誤，給項目添麻煩。
（2）老手向新手解釋工作及交流思想都要花費時間，使實際開發時間更少。
所以精確地制定項目計劃很重要，不在乎計劃中的進度看起來有多么快，計劃要恰如其分。
錯誤觀念之四：只要干活小心點，就能提高軟件的質量。
作者的觀點：軟件開發是一種智力創作活動，世上最小心翼翼、最踏實的程序員未必就能開發出高質量的軟件來。程序員必須了解軟件質量的方方面面（稱為質量屬性），一定要先搞清楚怎樣才能提高質量，才可以在進行需求開發、系統設計、編程、測試時將高質量內建其中。
軟件質量屬性之間并非完全獨立的，而是互相交織、互相影響的。因此，程序設計中要同時兼顧幾個質量屬性，使程序達到整體最優。要把質量屬性牢記在心，這樣才能在程序設計時一次性地編寫出高質量的、錯誤較少的代碼來，同時也可以減輕查錯和調試的負擔。
經典的軟件工程書籍厚得像磚頭，或讓人望而卻步，或讓人看了心事重重。請寬恕作者的幼稚，本章試圖用聊天、說理的方式來解釋軟件工程的道理。軟件工程的觀念、方法和規范都是樸實無華的，平凡之人皆可領會，但只有實實在在地用起來才有價值。我們不可以把軟件工程方法看成是諸葛亮的錦囊妙計—在出了問題之后才打開看看，而應該事先預料將要出現的問題，控制每個實踐環節，防患于未然。
研究軟件工程永遠做不到像理論家那樣瀟灑：定理證明了，就完事兒。
