四. 从总体上对系统的影响
当编写和修改一个程序的时候，由于一般来说它都是存在于一个更大的系统之中，而不是孤立的单个程序，所以，在编写或者修改完了之后，就必须检查它从总体上对系统的影响。
如果测试代码非常完善的话，这一点当然可以放在可测试性一起，那就是说，需要编写相应的整合测试的代码，并测试通过。然而，在很多情况下，如果没有实行测试驱动开发，并且编写相应的测试代码，这一项还是可以独立出来的。
不由地想到之前曾经修改过的一本程序。当时的需求是这样的：在做了对保单的保全操作之后（主要是新增附加险），在重新打印保单的时候，需要根据具体的情况显示最后缴费日。而此时又分为几种不同的情况，包括保单周年日新增长险、非保单周年日新增长险、保单周年日新增短险和非保单周年日新增短险。当时由于是第一次修改保全方面的程序，所以考虑就欠妥，只顾着达到自己的目的，而没有考虑到对整体的影响。当时我的修改方法是，找到数据库中存储最后缴费日的字段，然后在做保全操作的程序中，在执行相应的操作的时候将最后缴费日置为报表想要显示的日期。在做完之后，报表程序的确是没有问题了。但是在运行了几天之后，财务缴费的程序出现了问题，因为在缴费的时候是根据最后缴费日来判断何时需要产生应收数据的。仔细考虑一下，正是因为没有考虑到一次修改对系统整体上的影响，才导致出现了如此严重的bug。
因此，在进行新的程序编写或者修改原有程序的时候，一定需要做的就是考虑这个程序是否会对系统中的其他模块产生影响，如果有的话，就必须对相应的地方都进行测试，否则就可能产生不必要的麻烦。
另外，还有一个问题在那篇文章中没有提到，就是安全性的问题。如果一个程序没有考虑到必要的安全性问题，那么也不能算是完成了所有的代码。
举例来说，一个用户能够访问不属于自己权限之内的功能，或者程序中有安全漏洞，黑客能够很容易地对其进行SQL注入、OS命令注入、跨站点脚本攻击等等，那样就会给系统带来更多潜在的问题。虽然用户可能会感觉不到，但是信息的泄露和被篡改，对于公司来说风险是非常高的。
陆陆续续写了好多文字，想表达的就是，想要说自己的代码真的完成，需要做的工作真的是非常多。但是，也只有真正完成了的代码，才是高质量的代码，才会节省许多之后维护和修改的工作，也会防范很多潜在的问题。
最后，希望大家在写完一本程序之后，都会自问一声，我的代码真的完成了吗？
p.s. 之前几篇的链接：