编写职业水准的程序
编写职业水准的程序？是的，一点没错。高质量的或艺术级的程序境界，咱不敢奢望，但要真正从事软件开发行业，职业水准的要求还是应当满足的。
说到职业水准，自然是说对程序有一定要求了。那么，一个程序需要达到怎样的程度，才算是职业水准呢？众所周知，一个程序所具备的质量特征主要有：功能、性能、可靠性、安全性、可用性、可移植性、可维护性。这些质量属性的基本含义可参见《高质量程序设计艺术》（''Code Quality --- The Open Source Perspective''）一书的第一章。这里，根据自己对读到的相关材料的理解，进行了归纳和总结。
1. 程序的正确性
程序是否实现了预期指定的功能？这当然取决于是否精确定义了程序的功能，即对于典型的输入，程序将输出怎样的结果。“精确”这两字听上去很美妙，其实蕴涵了“巨细无遗、婆婆妈妈”之义；另外，这里是“典型”，而不是“所有”。通常“所有”意味着“无限”，而尽管人类对无限有了基本的认识和操作工具，在实践上仍是难以验证的。用某人的话说，无限是上帝的领地，凡人不可进入。
将“所有”化解为“典型”，退而求其次，这是程序开发中采取的首要折衷。程序开发者必须善于折衷和权衡。哎，还没开始，就得面临这般境地，实在让人难以释怀阿！
快速做出一个原型系统，然后不断改进它，精益求精。实现正确性的通用步骤：细致分析问题--->精确定义程序的典型输入输出--->编写测试--->实现代码。最后，用一句著名的话作为正确性的结尾：Firstmake it right, then make it good.
2.程序的性能
应用对程序是否有额外的性能要求？对于某些应用来说，通常是时间和空间上的限制（例如，实时系统对响应时间的苛求，嵌入式系统对存储空间的限制）。程序员大多有一种追求完美的倾向，并且通常以达到更快的速度和更小的内存的实现方案和技巧为荣为傲；其代价是可读性和可维护性相对较差。然而，借用诸多专家的话：过早优化有害无益，因此，除非使用已有成熟算法可以直接获得或不得不达到更好的性能，否则，不必要过早和过度追求性能。
定义程序的可接受性能，并通过算法数学分析和程序测量技术确保一定满足它。
3.程序的可靠性
程序在正常情况下（绝大多数时候）能够良好运行，那么，程序在特定或特殊情况下是否能够依然保持良好地运行，或者保持一定的性能级别？是否有隐藏的微小逻辑错误？
比如对于非法输入的处理；是否可能出现越界错误；不成熟的算法；没有覆盖的代码路径；输出缺失；高负载时能否保持可接受的响应时间和吞吐量等。
4.程序的安全性：
程序在遭受无意的或恶意的攻击时是否能够稳定健壮地运行而不受其扰或者不泄漏重要数据，甚至化解攻击？
安全性和可靠性的重要性是不言而喻的；没有安全性和可靠性，系统就只是一个玩具，企业的信誉也可能因此遭受重大损失。
5.程序的可用性
可用性主要是指程序的外部质量属性，即系统的界面是否实用美观？是否易于使用和操作，符合用户习惯？该软件是否易学易用？很显然，可用性也是非常重要的，特别是涉及与终端用户交互的应用。
6.程序的可维护性
程序排版是否美观易读？所使用思路和算法是否容易理解？程序中的不易理解的部分是否有相应的注释？是否有配套的简洁扼要的文档说明？如何应对所面临的应用中的变化和变动？
7.程序的可移植性
在某个特定平台运行良好的程序能够在另一个平台上良好运行吗？或者使之良好运行所需要做的改变有多大？这里的“平台”可能包括：CPU硬件体系结构、操作系统、编译器与语言特性扩展、GUI界面、国际化和本土化等。
可移植性并非不重要，但基于现实中各种平台之间仍然存在较大的分歧，并且，多数应用可能特定于某种平台，除非系统有明确的可移植性要求，可以放在最后考虑。
8. 程序质量排序：
冰冻三尺，非一日之寒。在现实中，一方面，由于这些质量属性往往是相互冲突相互制约的；另一方面，基于进度、成本及程序员自身编程水平的考虑，往往也不可能使程序达到如此艺术的程度，因此，必须对程序质量属性作出合理的折衷和权衡，作为实际中编程开发的准则。
程序质量排序取决于实际的应用需求。这里根据自己的理解，仅给出一个一般参考：
[1]功能与正确性［使用中的外部属性，可由外部直接感知，敏感程度高，容忍度低］
[2]可接受的性能［使用中的外部属性，可由外部感知，敏感程度高，容忍度低］
[3]可靠性［使用中的外部属性，可由外部感知，敏感程度一般，容忍度很低］
[4]安全性［使用中的外部属性，通常不易感知，敏感程度高，容忍度极低］
[5]可用性［使用中的外部属性，易由外部感知，敏感程度高，容忍度较低］
[6]可维护性［开发过程中的内部属性］
[7]可移植性［使用中的外部属性，可由外部感知，敏感程度较低，容忍度较高］