编程是一门艺术吗
作者的观点：水平高到一定程度后，干啥事都能感受到“艺术”，编程也不例外。但在技术行业，人们通常认为“艺术”是随心所欲、不可把握的东西。如果
程序员都把编程当成“艺术”来看待，准会把公司老板吓昏过去。
大部分人开发软件是为了满足客户的需求，而不是为了自己享受。本书（《高质量程序设计指南——C++/C语言》）提倡规范化编程。规范化能够提高质量与效率，最具实用价值，尽管它在一定程度上压抑了“艺术”。编程艺术是人们对高水平程序创作的一种感受，但只可意会，不可言传，不能成为软件公司的一个指导方针。
编程时应该多使用技巧吗
作者的观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中使用太多的技巧，可能会留下错误隐患，别人也难以理解。一个局部的优点对整个系统而言是微小的，而一个错误则可能对整个系统是致命的。我建议用自然的方式编程，不要滥用技巧。我们有时的确不知道自己的得意之举究竟是锦上添花，还是画蛇添足。就像蒸出一笼馒头，在上面插一朵鲜花，本想弄点诗情画意，却让人误以为那是一堆热气腾腾的牛粪。
小时候读的《狼三则》故事启示我们，失败的技巧被讽刺为“伎俩”。当我们编程时无法判断用的是技巧还是伎俩的情况下，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，不是卖弄出来的。
换更快的计算机还是换更快的算法
如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？
作者的观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑。若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误并延误进度。
技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。类似的争议还有：是买现成的程序，还是彻底由自己开发？技术人员和商业人士常常会有不同的决策。
错误是否应该分等级
微软的一些开发小组将错误分成以下4个等级（Cusumano, P354～P355）。
一级严重：错误导致软件崩溃。
二级严重：错误导致一个特性不能运行并且没有替代方案。
三级严重：错误导致一个特性不能运行但有替代方案。
四级严重：错误是表面化的或是微小的。
作者的观点：将错误分等级的好处是便于统计分析，仅此而已。但上述分类带有较重的技术倾向，并不是普遍适用的。假设某个财务软件有两个错误：错误A使该软件死掉，错误B导致工资计算错误。按上述分类，错误A属一级严重，错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了，将会使老板或员工遭受经济损失。而错误A只是使操作员感到厌烦，并没有造成经济损失。再例如航空软件操作手册写错了，按上述分类则属四级严重，但这种错误可能导致机毁人亡，难道还算微小吗？
开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。只有这样才能少犯错误。
一些错误的观念
错误观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。
作者的观点：好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这有如下两个原因。
（1）在现实中，由于工作条件千差万别，即使是相当成熟的软件工程规范，也常常无法套用。
（2）软件技术日新月异，没有哪一种标准能长盛不衰。祖传秘方在某些领域很吃香，而在软件领域可能意味着落后。
错误观念之二：我们拥有充足的资源和经费，可以买最好的设备，一定能做出优秀的软件产品。
作者的观点：大公司经常有这样的心态。良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人或者是一群勾心斗角的聪明人，难保他们不干出南辕北辙的事情。
错误观念之三：如果进度落后于计划，可以增加更多的程序员来解决问题。
作者的观点：软件开发不同于传统的农业生产，人多不见得力量大。如果给落后于计划的项目增添新手，可能会更加延误项目，原因如下。
（1）新手会产生很多新的错误，给项目添麻烦。
（2）老手向新手解释工作及交流思想都要花费时间，使实际开发时间更少。
所以精确地制定项目计划很重要，不在乎计划中的进度看起来有多么快，计划要恰如其分。
错误观念之四：只要干活小心点，就能提高软件的质量。
作者的观点：软件开发是一种智力创作活动，世上最小心翼翼、最踏实的程序员未必就能开发出高质量的软件来。程序员必须了解软件质量的方方面面（称为质量属性），一定要先搞清楚怎样才能提高质量，才可以在进行需求开发、系统设计、编程、测试时将高质量内建其中。
软件质量属性之间并非完全独立的，而是互相交织、互相影响的。因此，程序设计中要同时兼顾几个质量属性，使程序达到整体最优。要把质量属性牢记在心，这样才能在程序设计时一次性地编写出高质量的、错误较少的代码来，同时也可以减轻查错和调试的负担。
经典的软件工程书籍厚得像砖头，或让人望而却步，或让人看了心事重重。请宽恕作者的幼稚，本章试图用聊天、说理的方式来解释软件工程的道理。软件工程的观念、方法和规范都是朴实无华的，平凡之人皆可领会，但只有实实在在地用起来才有价值。我们不可以把软件工程方法看成是诸葛亮的锦囊妙计—在出了问题之后才打开看看，而应该事先预料将要出现的问题，控制每个实践环节，防患于未然。
研究软件工程永远做不到像理论家那样潇洒：定理证明了，就完事儿。
