小张第三把火是编程规范和标准，提出了比较好的编程规范，完全符合业界的标准。这也是技术总监一直强调的事情。

　　公司的元老早期都是写C出身的，在采用面向对象的编程工具时，所有的编程规范仍然沿用C的风格，包括各变量的命名和参数的格式；而早期的同事也因多年潜移默化，认同并继承了这样的编程风格，使得所有的源代码看上去都有些不伦不类，难读懂，自然更不易维护了。有些老总初期写的程序，连他本人现在都不好理解，更不用说新同事了。

　　小张参考他以前所在公司的编程规范和标准，严格要求项目组成员按其标准执行。因为小张之前所在的是个大公司，有很好的架构，所有的程序填鸭式地照搬就可以了。而我们公司还处于发展中阶段，技术框架和底层没有那么高的水准。

　　但小张的思想还停留在之前那家公司，规定编程人员原则上不能修改编程标准格式和规范，如果要增加其中任何一个实体的一个方法或属性，都得向小张提出申请。于是编写程序时，难免会遇到很多底层无法支持的东西，而不断和小张讨论，最后按小张的要求将原本二三十行的程序扩了一倍多，代码繁杂。

　　小张这样的管理方式，理论上是相当不错的，可实际工作中，其直接下属当着小张的面向笔者抱怨，说其编程规范不实用。打开源代码让笔者看，笔者也很意外，一些非常简单的程序因为要采用标准的格式，变得繁琐复杂。

　　比如，数据库表中的每个字段都作为一个参数，编写一行代码。要知道之后的核心业务中，我们的主表就有近百个字段，一套软件的表对象都在百张之上，近万行的代码都要复制粘贴再修改，工作非常枯燥且无聊，难保不出错。

　　笔者当场提出，为何不在底层用递归的方式编写程序，解决每个字段都占用一行代码这种非常无效的编程方式，同事回答说这不符合小张的标准。

　　小张的这第三把火，应当说是烧进了管理层的心里，但执行时却忽视了一线的编程人员。因为程序在结构上变得整齐、严谨、规范、直观、易读懂、易维护，但程序编写和调试时却非常低效，代码多了好几倍，容易出错，跟踪麻烦和低效。同样，编程的时间比正常的工作进度慢了一倍以上。因为小张的固执，不少核心级同事以各种借口逐步淡出了项目组，程序编写没有了核心员工的参与。