程序=代码+数据
对于这个公式，大家应都很熟悉。如何处理数据有很多技巧，本文站在C#等高级语言的角度，作一些分析。
本文所讲的数据，将所有的常数、变量、对象都视为数据，程序的其余部分视为代码。数据的一个关键属性是数据的表示形式，一般可以区分为程序内定义和持久保存在文件或数据库中两者；这两种表示形式的异同点分析，见下表：
|
项目 表现形式 |
程序内定义 |
保存在文件或数据库 |
|
数据数值的解释 |
相同的逻辑 |
|
|
数据的变更方式 |
变更程序和重新发布 |
变更文件或数据库 |
|
常数的区别对待 |
不会或不常变更的数据 |
经常会变更调整的数据 |
|
变量、对象 |
适宜在程序中定义 |
串化后可保存在文件或数据库 |
很多的软件工程师，经常没有注意两个细节：
一、图方便和简单，将所有的常数写在程序内
例：有一定时备份的程序的时间和存放路径，一般情况下是应使用配置文件；但经常约定为0:00及当前目前下的某个子目录等。
图的是不用写读写配置文件的代码的方便，遇到变更时再改程序了。缺点是通用性差，不灵活，可以骗过外行人，不适合大量分发。
二、处理数据的逻辑将对数据的格式的假设等限死了
最典型的是流程处理中对组织的解释了。经常不使用“角色”和“群组”的数据格式，而是等某人辞职了，在程序中换一个名字，重新发布就是了。增加或删除组织层次， 程序改吧！
合理的组织架构数据，应是不管是人员的变更和层次的增减，都不用改程序，仅在对角色职责的解释变更时或业务逻辑变更时才去改程序，否则将只是数据维护工作而于。
对，数据维护工作！对于很多人的印象可能是“错误数据修改工作”，合理的数据维护工作应是程序的外部环境发生变化所引起的数据一致性配置等工作。
让我们看看，Windows操作系统，Office软件，Vs.net开发工具，oracle数据库等，个性化等配置界面无处不在；博客园的配置项目也非常丰富。回过头来，看看我们自己开发的软件呢？有多少的可配置项目，离最大的可配置还有多远？！
总之，对常数固化在程序中或放在配置文件或数据库，值得慎重决定。很多的软件，通过修改配置，得到很强的生命活力。所谓的创造性中最容易做到的一点，是让通过简单的数据维护，使软件有很强的适应性的程序开发工作。对于企业应用软件的开发工程师，是时候，将数据维护工作让给别人来做了。