一位同事做了一个供开发调用的打印控件，是先由开发人员编辑报表格式模版，以xml格式保存，然后将表格数据填入xml文件，最后将此xml文件解析出来提供打印或者转档成excel文件。而在他demo时被我等“用户”指责无法满足复杂报表的打印要求。考虑到控件能够满足大部分需求，而且手头的工作太多，他便将控件放到source safe上，供有“特殊需要”的人修改使用。
经过多次交涉未果，作为最迫切的用户，我只好get下代码，接手改进工作。很快我便发现这些代码是非我所能理解的。由于封装太差，我不得不努力看懂几乎每一行代码，而长达几页的switch...case和if…else语句，以及众多神秘的数字常量，都让我感觉更像是“密码”而非“代码”。
一个星期之后，我只改进了转档速度慢的问题（原来每画一个单元格都要创建一个GDI对象，现在简单用一个单体类解决）。但更关键的复杂表格线的绘制还没有头绪，反而觉得越改越乱。我再次体会到了封装和代码风格以及注释的重要性，这些在构建过程中反复强调的问题对代码的扩展和维护有着非常重大的影响。尤其是当开发人员变动和维护周期很长的情况下，程序员在紧张的进度下的偷懒和取巧行为会很大影响到后期的成本。没有review和正式检查，紧张的进度，不断更改的需求，很容易滋生低劣的代码。而要彻底改变这一状况，牵涉到项目管理和员工素质等各方面的问题，决非一日之功。
