《三国演义》中浓墨重彩描述的大多是武将的勇力以及谋士的计策和辩才。花笔墨称赞阵法精妙、器械发明奇巧的寥寥可数。但若是能进入篇章的，就一定是惊世之作。令人印象深刻的有曹仁的八门金锁阵、诸葛亮的八卦阵、刘晔的霹雳车以及诸葛亮后期发明诸葛弩和木牛流马。其中八卦阵被吹嘘的神乎其神，甚至刘备兵败后，诸葛亮用几块破石头布个阵就差点整死陆逊。
演义中的逻辑破绽很多，八卦阵真有这么神奇，诸葛亮只要在蜀国各处咽喉都用石头摆个阵，不就可以轻松搞定国家防御？诸葛弩如果那么牛B，干脆每人一把，两军交战立马打机关枪一样“突突突”，还不瞬间统一三国？稍加推敲立刻破绽百出。古往今来没有一样东西可以亘古不变，管理学中有一句话说的特别好“唯一不变的就是变化”。然而，在软件设计与开发中，我们常常违背规律地寻找着“八卦阵”和“诸葛弩”。
在教学和开发过程中，我常常会听到学生或有人谈论这些问题： “哪种语言最好？”，“我应当学什么语言？”，“用SSH架构把”，“这个项目一定要用XXX框架”。我的回答是：任何开发语言都一样，没有最好的语言，只有最适合某一项目的语言；任何语言的思想都一样，思想是内功、语言是招式；框架如果能帮助快速开发和提高可维护性就用，否则弃之。作为一个项目管理者而言，任何一个项目的本质思考顺序应该是：经费、维护、功能、性能。
首先是经费，“不以盈利为目的的企业都是在耍流氓”。一个项目如果只有十万的经费，你TM又要用ORACLE，又要负载均衡，又要跨平台，你不是找茬是干什么？这就好比1块钱买了个包子，质问老板馅里面为什么没有鲍鱼海参一样可笑。本文重点不在此，略过不提，关键谈谈八卦阵和诸葛弩给我的启示。
-
八卦阵与系统框架
阵法在很多地方和系统框架非常相似。每个人在阵法中都有特定的位置，需要做指定的动作，就好像采用了某种框架后，需要按特定的方式进行编程一样。曾经很长一段时间，我都在思考，如何把24设计模式好好地用到项目中；如何把structs2作为团队开发必须遵守的准则；如何在项目中用好SSH。结果发现一件可悲的事情，框架越高级，维护成本越高，而且随着时间的推移，人员的变动，项目的维护越来越无法持续。
这就好比八卦阵，纵观整本《三国演义》，懂这个阵法的人有那么几个，但只有诸葛亮一个人能用好。这就好比公司里有一个巨牛无比的技术大拿，设计了一套巨牛无比的框架，然后训练公司的一群技术小兵通过框架开发项目。技术小兵上手快，开发简单，往往一行代码就可以实现高级功能，开发出来的项目无论在稳定性还是性能效率方面也都异常出色。但如果需求有变动，框架级的修改只有这个大拿才有能力改的了。作为公司的老大，你敢用这个框架吗？如果是一锤子买卖的项目，我会用。但是核心项目，我肯定是不敢。因为大拿会跳槽，会生病，会请假，会出各种各样的意外。一旦大拿不在，关系到公司命运的核心项目就会垮掉。作为项目经理，我要的是所有技术人员都能进行代码的维护，或至少在不超过1个月的培训后，能够对项目的代码进行维护。太复杂、维护成本太高的框架我会直接无视。这就好比，诸葛亮五丈原身死之后，《三国演义》中再也没有出现八卦阵一样。
这方面血的教训很多，特别是做管理信息系统，一个领导一个想法，一个领导一个需求。曾经有一个铁路系统的集中监控系统，顶层设计和请了一个巨牛无比的技术大拿来做，设计了一个异步的4层结构，跟踪一个消息兜兜转转十几个类文件跳跃，导致后期根本无法维护。结果推倒重来，用最简单的方法进行串行设计，性能下降很多，但整个项目维护使用了7年。
所以，我现在的一个准则是：只有在70%的技术成员都能掌握某一框架的时候，才能利用这个框架进行开发。
相比"八卦阵"，我更喜欢"诸葛弩"。
-
诸葛弩与控件和调用接口
如果把阵法比作系统框架，诸葛弩就像是封装好了的控件或功能接口，功能单一（快速射箭），操作简单（扣动扳机即可）。我不需要知道这个功能是怎么实现的，只管知道怎么去用就好。
而在使用框架时，往往会碰到过度设计的问题。好比我需要一把拖把，控件就是提供了一把成形拖把，我只要拿他去拖地就好。而过度设计时，提供的则是：木棍类、布类、铁丝类，需要程序员再去把木棍、布、铁丝组装成一把拖把。然后还兴致勃勃地夸耀，这个木棍类还可以用在扫把功能上；布类甚至可以单独成为一个抹布功能。对于这种设计，我只想说“去你大爷的”。
所以，在大多数项目中，我都会要求项目teamleader做好功能封装，最好能封装成特定功能的控件。只要告诉调用者方法名是什么，需要传什么参数即可。同时，尽量结构简单，能不自定义类的尽量不自定义类。为的就是所有人都能对代码进行维护。项目的可维护性高于一切！