硬编码

硬编码对于程序员来说都不陌生,只是个很简单的概念,但是它却常常出现在N多程序中.
在开发的时候,开发人员有时候图方便,赶进度,或者想不到更好的方法,只好将某些业务逻辑固定死,常见如下判断
if (a == "拟制中")
{
 ....
}
也许好一些的会用数字代替 比如用个"02"代替,也许程序跑个1两个月甚至一两年都没问题
但是需求更改或者用户环境变化了,那问题就会暴露,而且影响是明显的.
比如用户改成英文环境了,变量a的值变成了英文字符串"drafting",那么这个判断就不成成立了,如果这个判断是涉及到流程,这一步出错,程序再往下走也就是一错再错.也许有人说,不用字符串判断,改成数字就可以避免,但是也许某天这个数字跟其他业务逻辑发生重叠,那还是没实现根治,解决方法我相信大伙都明白,其实只是简单的设置一个变量保存常量,比如
string Drafting = "拟制中",
if (a == Drafting)
{
 ....
}
那么a的值改了,相应修改drafting的值,哪怕是a变成英文,也可以事先改变好Drafting的值,这样简单处理,即可实现编码更改的无缝兼容,让编码变"软"了.当然前提是在开发的时候就做好.

再比如某些系统设计到人员权限等信息,某某单据必须让管理员甲审核,开发时管理员是甲,但是不久甲离职或调动了不当管理员了,但是系统审核的单据信息还是发给甲,如果甲的人员信息还保存在数据库中,程序还能跑,而实际上HR会毫不留情的删除掉甲的信息并且不通知开发人员.这样程序还继续执行的话,要么抛个空指针异常,要么抛个范围溢出异常,影响后续流程.而事实上,只要设置一个管理员标记,或者动态给个方法获取管理员,也就省了后续麻烦

当然硬编码的现象并不是仅仅出现在逻辑判断中,比如javascript,如果写的脚本仅仅能在IE运行,那么也就成了典型的硬编码了,诸多现实的例子就不举例了.所以,对于程序员来说,硬编码好比是程序的硬伤,追根到底不仅编码人员有责任,设计人员也因改意识到根据用户需求展开可扩展的设计.