程序结构中的两点重要元素

 

   编写代码，就目前编写web application程序和web form程序而言，遇到的最棘手的问题，莫过于对程序bug的勘察定位和对程序代码潜在漏洞的排查，而对于刚刚开始编写代码的朋友来说，这两点可能是既知重点，但是仍无从下手。

 

   回想自己刚入公司的时候，也是被安排为公司的一个项目做日志添加工作，也许你会好奇，为什么程序功能结构都基本完工，但是，针对程序的日志功能迟迟没有填充呢？这种事后填补日志功能的做法是否是一种高效正确的思路呢？当时，自己没有想这么多，于是就开始深入程序代码中，原本打算是对每个较大的函数都做下记录（当然指的是出错的时候），当时自己一个比较“天真”的方法是：在调用这些函数的地方，都填补上日志，想要达到的效果就是，一旦发生错误，便能很快地从日志中得知是那个函数发生了错误，同时记录中包括了函数的类，函数名等信息，目的性所谓很明确。想不成，领导并不认同这样的日志思路，因为，在设计程序架构的时候，已经设定了使用try catch的方法对每个函数进行错误捕捉（可能是源于C++编程规范吧），而在领导看来，我们的工作就是在这些try catch中添加记录这些异常的代码就OK了，而其中的代码则完全没有区别，只是通过添加一些特殊的字符串信息，作为定位的依据。

 

    于是，“未将对象的引用应用于正确的对象实例”这类通用错误，就成了跟踪错误的最大杀手，因为很多种情况，很多个地方都会出现这样的问题，而你唯一能够做的就是逐步沿着业务逻辑调试代码，看起来很酷，但其实这样做是非常低效的，尤其是当产品上线以后，出个这样的问题，你是没有办法进行逐步调试的，如何定位问题便成了一件只有非常熟悉代码的人才有可能“推算”出来的“棘手问题”……

 

   后来，领导也意识到这样的定位的确是一大障碍，所以，在我被安排的下一个项目中，特意要求我要使用单元测试，因为使用.NET环境，所以，当时对其中的单元测试功能还学习了一番，只是没有那么多时间来系统学习，后加上自己的懒惰思想，于是在一拖再拖之后，单元测试也流产了，取而代之的是针对每一个细分模块的逐一测试，这显然不是单元测试的精髓……

 

   说来，编写代码也两年有余，日益感到上述所说两方面的压力，尤其是当一个系统非常庞杂的时候。在各种框架日益横行的今天，难道解决单元测试和问题排查就只能通过良好的变成习惯作为重点突破口么（自己目前的看法，可能有很好的思路，还望指正！）？

 

   于是，自己就自己编写代码的这点小经验，根据自己目前处理的项目的情况，设想了一个编程“架构”，以解决上述两大难题，即“三段式”编程，其中就日志记录（即问题排查）已经做了简单实现，可能还有待进一步的修正，下一步是想把单元测试也添加到其中……

 

   除了使用目前网上盛行的一些单元测试，我更偏向于设计出一个能更加“平民”化的测试结构……随时更新中：