代码那些事儿---走出软件做坊：三五我的十来条枪 如何成为开发正规军（二十八）

这个是讲软件研发过程管理的系列，目标人群是那些身处研发管理位置或想成为研发管理的人。因此我不但愿这个系列中出现代码，也不但愿出现和某种技术密切相关的代码技巧。

可是没有办法，软件开发过程管理，有个很重要的一环，就是软件代码编写。不编写代码，说的天花乱坠，管理作的再扭，也成为不了软件。

最近blog好友到了上限，因此没法加入好友了。因而就加入了N多QQ网友。大多数刚出道一两年，还有很多在校学生，但愿认识并聊聊，要和我聊设计模式、OO、SOA，还有人建议我去看看OO和UML的书籍。

我确实没有阅读过OO的书籍，我不是一个死钻牛角尖的人。我只是有什么问题，就去找解决问题的方法，能解决个人问题就OK，而不在意我用的正不正宗，也不在意我用的是否是OO。可能它是OO的外壳，可是它实质上多是伪OO，我也不想去深究和区分什么是正宗OO，什么是伪OO。反正能解决个人问题就行。

我首先赶上的问题是代码大流水的问题。一个代码3000多行，数不清的if..else。我实在没法分析出这个代码到底实现了什么功能，它复杂的就像一把瑞士×××，若是×××里面能出来一支小手电也以为不奇怪。这段代码我想它就是这样。我想写这段代码的人必定是在学校作惯了《图书馆管理系统》，一个程序文件中实现了全部的功能。

因此，经历了痛苦，我就一直要求手下的开发人员，一个函数代码行数不能超过一个屏幕。若是超过一个屏幕，就须要来回滚动。一滚动，就容易把思路滚动的走神，乱了，还得回到上面去从新理逻辑。

这种规定，直接致使了一个后果，函数太多了。可是函数间是有关系的。有时候忽然须要增长一个参数，可是此函数已经被其余代码调用了，因而为了省事不改动其余代码（固然，他可能已经忘了再哪些地方都调用到了），他就定义了一个全局变量，在函数之间传。

新的问题有出来了，全局变量的问题。代码在他一我的手里还好说。被维护了好几手，新手对日益复杂的代码已经不太容易理出头绪，但修改任务是有时间限制的，只能在现有理解水平上工做。这位新手看到这个全局变量的命名，感受是本身能用的到，就用了，还给赋了值。意向不到的事情发生了，数据库中进了错误的数据，怎么来的，不知道，看代码，处理的都正确，代码没有问题，也不知道怎么出现的。

因而禁止你们使用全局变量，能藏到多低的可见级别就藏的多深。可是仍然问题依旧。

因而，咱们就把这个全局变量封装成属性，给它赋予读和写的函数。无论有多少个地方调用了它，有谁给它乱赋值，这里掐源头，都作好日志和异常保护校验。

把全部函数，能变成私有的就变成私有的，须要公共供其余人调用的谨慎的放出来。放出来的函数，必定要作好参数的校验，什么空指针，什么没有初始值，什么非法参数值的，尤为是临界值上下边界，都在门口就挡住，根本不往下执行进行业务处理，不然走的越远引发的问题越大。

并且要求每一个函数都要作好本身的内存保护工做，本身函数内建立的就要在函数内释放。每一个函数要作好异常处理和日志记录。

这样，一个样子像OO的类产生了。它可能只遵照了OO所提了封装，它却没有实现OO所提的继承和多态。因此它多是个伪OO，但它确实解决了咱们的问题。

封装了类以后，又一个问题产生了。几个类之间不知怎么的，老是你中有我，我中有你，互相调用了。就好像左右手互搏，弄很差就会把本身给捆起来。

为了堵住这个问题，规定只能单向依赖，若是发现你必须调用另外一个类，另外一个类也须要调用这个类，就以一个类为主，另外一个类开放事件。这也许就是控制反转，AOP的需求吧（我并无深刻研究AOP，我只记得控制反转这个词，好像是为了解决相互依赖关系问题）。“Don't call us, we'll call you”。

可是代码稳定性的问题仍然没有很好解决，测试组也找出了许多BUG，可是一到客户那里运行，仍是出了很多BUG。怎么本身运行的时候找不到呢？

因而，咱们在版本测试的时候、第一个版本小规模放给典型客户的时候，都加了断言。一旦软件出现问题，就当即记录日志，并进行软件中断，而不让错误继续错乱的不按咱们预想的代码流程走下去。不少年前，我就惊讶于某公司的软件的质量，怎么折腾操做都没有问题，我经常给个人手下拿这个例子来反衬你们的代码质量。直到我有时随便乱点，竟然软件中断退出了，报了一个错误号，我一会儿想通了，它用了断言。断言阻止了错误的继续扩散，不让恶果之鞭长袖善舞。因而，我要求开发人员常常性使用断言，不少过去悄然发生的错误，测试员只运行可执行程序没法捕捉到，如今都能明确的捕捉到，在测试阶段就尽量的消灭了那些过去没法明示的BUG。

我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就到处是类，到处是抽象，到处是封装，到处是分离，尽可能使代码高内聚低耦合。可是这样的的代码太麻烦，他花费了大量的时间，他看本身的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为何这样写代码，怪异的很。原本，这位想达到可维护性，可阅读性，却真正的失去了可维护性、可阅读性。这和我前几天看个人朋友周爱民写的《大道至简》中写到：有人但愿拿UML去统一用户和软件设计者。却不知UML有多难理解，而UML设计者却认为UML能够描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求过高了吧。

所幸这位新手本身都每次写的累，慢慢的也就懒了，以为确实须要分离的时候就分离，以为没什么必要的就懒得作了。用他自嘲的话说就是：被磨平了。其实，依我看，他如今这个代码状态才是刚恰好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于咱们的商业软件开发。咱们做为商业开发，强调的是叫座的基础上叫好，因此折中方案是必须的，客户和咱们本身两相宜就OK，是否符合正宗，就不在咱们的商业开发管理范畴了。

这位新手还写了大量的注释。在每一个源代码文件头都写上几月几号，XX建立的，这个原代码文件主要是干什么的，还多此一举的写上版权全部，公司名称。好像这个代码要开源，或者可能会被其余公司窃取了好代表公司版权。甚至每一个函数都写了注释，每一个参数是什么意思，每一个参数可能出现的值表明什么意思，都写的一清二楚。长此以往，也懒的维护了。代码改动了，参数扩展了，参数状态值有了变化，注释说明却没有跟着改动，让后来看代码的人老误解，还不如不写这些注释。

我告诉他：作事不能走极端。要么全写注释，要么不写注释，都是不对的。我只在我认为要当心的地方，或者我本身都以为很难理解懂的地方我才写注释。不然，我本身均可能会过段时间理解错了。若是某段代码我看看就能看懂，我就不写注释了。我们作企业管理软件，深刻技术又没有，只要代码能把复杂的业务处理描述的逻辑思路清晰就OK。虽说理解能力不一样，我能快速理解了的未必有新手可以理解，可是你看看个人代码你就明白了。

这位新手去看个人代码去了。个人代码几乎没有什么难度技术，但代码也是看上去很舒服。他发现了如下几个关键点： 1 代码风格统一，从命名含义，到大小写，到缩进，都一致。每一个源代码文件都一致，确实出于一人之手。许多程序员，光本身的代码就有好几种风格，有时心情好，有时心情很差，有时头脑清醒，有时没有休息好，有时敷衍，有时多此一举，有时急躁，从代码就能看出来。而个人代码就像稳定运行天天如一日的机器，好似每一个源代码都是在同一天敲的。这就叫发挥稳定。这几天要开奥运会了，运动员每天重复练同一个动做，把每一个环节都练的精益求精，其目的就是为了在大赛紧张的压力下也能发挥稳定。人在压力下，很是容易发挥失常。若是人老处于这种压力下训练，那么大赛就像日常同样了。

2个人代码竟然能看出业务流程。函数数量均衡，不像他的代码函数太多，跟踪跳转的很累，也乱了头绪。函数长度也正好在可理解阅读范围内。并且有一个流程控制函数，把流程处理环节串了起来。细深刻跟踪某一环节，又发现了更细的流程。每一个函数都看起来简单，但总体来看，却实现了复杂的功能。他问我是怎么作到的？我说，个人心中只有业务，业务和代码，我认为只是英语和汉语的区别，表达的是同一个思路。而在你心中，业务是DOC上的文字，代码是你的技术表现，你老须要把业务和代码映射拧在一块儿，我则不须要。业务流程如何，个人代码流程就是如何。

3因为个人程序都是小函数组成的，都有明确报错，因此错误很容易找到，即便出错，也扩散不大，都是小bug，对系统总体没有大影响。

他还对个人开发方法不理解，问我为何要让你们从后台往前台开发，他很不习惯这种方法。他过去开发都是先用开发工具拖拽控件画出界面，而后一个按钮一个按钮的处理业务代码，须要什么字段就在数据库里设计什么表加什么字段。

我问他：你为何要这样作？

他说：我不理解需求，没法凭空想象，只能先画出来界面，而后有了直接感受后就在开发中理解业务，边开发边理解。

我问他：那你之前有详细设计说明书没有？

他说没有。

我又问他：那你之前有人单独设计数据库和开发业务处理中间件组件么？

他说没有。

我说，问题就在于此。你没有详细设计说明书，因此你看不到一个形象的东西，而我们如今至少有PPT画的业务界面，也有输入要求说明，也有数据增删改查说明，也有业务描述说明。并且数据库，一个中大型应用，性能、稳定性、可扩展性，都在于数据库的设计和中间件的设计，若是每个程序员都要从数据库设计到中间件组件开发到前端客户端开发，那么要想保证这个软件的统一总体质量，那有多难。每一个程序员须要懂得多少的技术知识才能达到统一的质量要求。因此，让不一样技术高度的人作不一样难度的事情，把重要的事情掌握在高素质的人的手中，这样质量就不会跑偏到哪里去。企业管理软件，不外乎是数据的增删改查。数据库的视图和存储过程，已经屏蔽了复杂的表之间的关系，提供了统一的业务实体视图和业务实体的增删改操做。这样中间件组件就容易处理业务实体间的流程，到了客户端，就只剩下数据的输入和输出了，真正成了终端。

我还常常进行代码复查工做。发现有人的代码出现坏迹象，我就让他整改重构本身的代码。不然，定了规范，光喊口号让你们遵照规范又不检查又不惩罚，谁爱遵照规范？

在代码复查的时候，我常常能发现思路局限、想法绕弯、实现缺少扩展性可变性、缺少优化、判断有遗漏有风险的代码。我都一一给他们指出，而且告诉更好的方法应该是如何如何。

不少网友都问到如何培养开发人员、培训开发人员、提升开发人员技术。我过去所在的公司是每一个周五都不按期召开技术培训会。可是慢慢的也流于形式了。我我的感受，技术培训会是个好事，但最终达到的效果多是增强了团队的凝聚力和和谐力，有利于团队建设，可是技术提升，并无给开发人员在实际工做中有应用。由于你们听了也就听了，会一散实际工做中仍然照旧本身的思惟习惯，很难落实下来。

经过代码复查，这就是真真实实的代码，这就是你们最实在的工做成果和每天接触的东西，颇有真实性，不脱离，有针对性。经过这种方法，达到了你们对本身平常写代码的技术技能的提升。这就是我对程序员的培训方法。

管理是什么？有网友老跟我讨论企业管理、企业文化、盈利模式、执行力、忠诚度。我不是很喜欢这些空洞抽象的主题，讨论完了也没法解决实际细节问题。而企业的运做，偏偏在于每一步的成功，最终汇合成最终目标的实现，没有脚下的每一步前进，再好的设想也是空想。

管理，就在细节当中。

代码高手，也在于细节当中。

质量、进度、成本、目标、折中，这就是核心。写代码，作管理，道理同样。