提高系统开发效率的“银弹”——X-series可视化大规模应用开发工具集

子曰，知之为知之，不知为不知，是知也。

知道自己不知道也是一种知道，但作为开发人员，面对一个系统时，无论是开发新功能还是维护老系统，我们更多的是处在一种茫然无助，不知道如何下手，甚至不知道自己不知道的状态中。虽然系统开发的实践已经超过半个世纪了，在各个方面都取得了长足的进步，解决了很多难题，但我们在开发效率方面的提高明显跟不上系统规模的膨胀。虽然各种新想法，新方案虽然层出不穷，但始终都没成为大家心目中的那枚银弹。

本文试图从分析开发人员面临的困难与挑战入手，剖造根因，探索解决之道，最终通过提供工具来落实解决方案。也许没办法提供一枚完美的银弹，但钢弹铁弹也能打败怪物。

一、系统开发面临的挑战

对于一个拥有多年实践经验的开发人员来说，软件开发的本质其实是软件维护，因为任何一个系统从开发的第二天开始，就会面临一个理解的问题，摆在我们眼前的始终是如何理解昨天的系统和构建今天与明天的系统。

理解系统的途径无非是阅读文档和代码。但无论公司大小，只要对开发工作有所积累，都会发现通过文档和代码进行理解存在巨大的困难。虽然是老生常谈，但为了深入理解问题并针对性的提出解决办法，我们还是先花点时间聊聊。

1.1、文档迷宫

首先，人人都讨厌写文档。人的思维的速度是任何事物都无法匹敌的，嘴巴跟不上大脑，手更跟不上。因此我们往往发现找不到文档或即使找到，文档质量也很差。产品经理负责的需求文档可能好点，因为他们必须写，但开发人员负责的设计和说明文档其质量大家心里都有数。

其次，开发本质上是个翻译的过程。从最开始的想法到最终用户看到的实现，中间要经历多次的翻译过程：

需求 --> 设计 --> 代码

哪里有翻译，哪里就有误解。由于各个环节参与的人之间存在概念，惯用语等各方面的差异，存在误解是必然的，不误解是侥幸的。并且由于在各个环节之间的抽象程度不一样，在环节之间还存在细节的增强与丢失。这就是为什么文档往往缺乏关键的实现细节。

常见的情况是很多需求确认的内容会在口头，电话或邮件中表述，但没有反映到文档里面，虽然最初参与沟通和系统实现的人按照这种需求做了，但后继维护的人就无法找到原始的需求来源。

最后，很隐蔽，但很关键的一点是文档之间的无关联性。需求文档与设计文档，设计文档与代码本质是割裂的，没有关联的。任意文档的改动不会引起其他文档的自动同步。

这事实上决定了文档是不可信的。即使找到一些文档，这些文档也都很少反映最新的需求和系统现状。也许最初的文档写的很工整，与实际系统大致吻合，但几个版本以后，文档一般都会变得要么支离破碎，要么结构混乱，最惨的是根本就忘了更新。

这是现实，讨论对错没有什么意义。最终悲催的开发人员只能依赖源码，从源码反推需求。也就是那句著名的“Talk is cheap, show me the code”

1.2、源码泥潭

通过看代码理解系统是没有办法的办法。小公司，小模块里几千，上万行代码的系统我们也许可以这么做，但面对一个百万，千万代码行级别的系统，我们本质上无法通过阅读代码来进行理解的。

经常会听到某某技术公司的CEO/CTO说其会看代码，以表示自己多么的hands-on。我们做个简单的算术，假定一个人1天可以看完1万行代码，100万代码需要近3个月时间，很难想象一个高层人士3个月什么事情也不做，只是看代码，并且代码每天都在变化。靠对细节的观察反推宏观系统，这种思路是错误的。

系统的动态几乎不可能通过人工的静态分析推测出来。看代码只能检查一些很表面的东西，几乎所有的代码检查都以对格式或命名之类的细节争论收场。当然不能说看代码完全没用，在一个很小的团队内部，大家都对系统很熟悉的情况下，这样做可能是有效的；但放到cross team的情况下，代码review最终会变为形式或者一个social activity而已。

当然我们最终还是得看源码的。谈到看代码，大家心里想的一定是能不看就不看，因为大多数的源码真的是惨不忍睹。对于任何一个有点积累的公司来说，到处都是超长的类，超长的方法；超大，超长，超宽的嵌套条件分支；硬编码的对象组装逻辑等等，更别谈各种新兴的AOP和字节码技术埋伏在各种和你眼前的代码完全无关的想不到的角落。这样的源码要么完全让人无法读懂，要么即使看完了也不敢说自己真的明白怎么回事。

系统开发并不仅仅意味着写代码，问题的规模不同，解决的手段也不同。不幸的是我们开发任何规模的系统用的办法都似乎是同一个原始的手段--写代码。对于一个小系统，直接上代码也许没问题，但对于大多数工业级别的系统，由于规模不同，这么做只能是低效的甚至是失败的。

从整个系统的角度来看，代码仅仅是最底层实现的细节。代码可以完成很多事情，但不意味着代码是解决所有开发问题最有效的手段。对于写给人类看的代码来说，代码只适合描述简短的顺序逻辑，分支和嵌套结构。

通过看代码来理解一个系统是最低效的方式，好比一个人试图通过双脚走遍一个森林的每个角落来理解整个森林一样,本质上是不可能完成的任务。

二、解决思路

问题意味着机会，思路决定着出路。如果承认提高系统开发效率的关键在于如何快速高效的理解系统，那么我们的解决问题的方向和判断标准就很明确。

先排除不正确的思路，我认为有如下几个：

1.     堆砌流程。流程越多越痛苦。这个无需多说。真正该做的事是现有流程的简化与自动化。流程本质上跟提高理解系统和构建系统的效率无关。系统开发的主要工作是理解并构建一个可以运行的系统，而不是构建一套工作流程。参与到流程中的时间必然会挤占掉实际开发的有效时间。

2.     开发更多的管理工具。大多数工具做的是和开发无关的周边管理工作，例如编译，持续集成，源码管理，发布等等。同流程一样，管理工具越多，开发工作越艰难。经常发现为了统一目前过多的解决方案，大家头脑一热就又做了一个类似的。往往很多系统之间对关键数据都对不上号。这个道理跟航海时用一个钟表还是两个钟表的问题一致。

3.     贸然引进与目前类似的新语言/框架/标准。公司级别的开发实践和个人的开发实践是两个完全不同概念。个人如同武林高手，多学习新东西是自我成长的必要，艺多不压身，最好成为全才；公司如同军队作战，讲究的是快速培训，快速上手，团队合作，同一标准，简洁高效，对人的要求是中众就行。引入过多的语言/框架/标准会导致对人员要求不必要的提高。因此对公司开发而言必须要对引入新东西保持警惕。如果没有新东西，不符合之前提到的标准，对开发效率没有很大的提高，又或者仅仅只是重复解决已经被现有方法解决了的问题，这种引入就是失败的，只会增大整个系统的复杂度，增加理解的难度，进一步拉低效率。

要构建一个可以快速高效理解的系统，正确的思路主要是为系统构建提供一种简单易懂，无需翻译的方式。其次由于不同领域的模型千差万别，无法通过一个统一的模型来描述，针对不同的问题领域，我们需要合