面子驱动编程

面子驱动编程？这当然是玩笑话。在经历了文档驱动、进度驱动之后，我又遇上了“面子驱动编程”。

首先声明我其实很喜欢我们公司，否则的话不会从毕业到现在一直呆了四年。但世上没有完美的公司，项目中碰到问题是很自然的。

什么是面子驱动？我也是昨天开会后悟出来的。当时小组长（不怕你笑话，我还在干程序员）问我，我负责的模块，权限方面如何设计的。我说根据用户岗位来判断权限。他问，有没有使用现有的权限数据库表（包含角色和资源那种）？我说没有。又问：怎么配置权限？我说写死的。——我就看得出他脸上的黑线条。于是他要我解释。

我的理由是，用户现有的工作方式基本上不会变化，至少在项目生命周期内不会，客户也是明确的说过不需要那么灵活的配置。我曾经做过一个小项目，那个需要登录才能使用的系统，连用户的增删改查都没有，用户照样用得很好。所以我的原则就是在理解用户现状和需求的前提下去掉所有不必要的功能。

我这个模块，用户权限和职务的划分就是基于岗位的。如果我使用了基于角色的权限方式，那么用户在变更岗位之后还要手动更改角色。否则就会造成混乱。这是不必要的麻烦（自动变更角色？想得美，又不是我负责的）。

组长不这么看。他认为权限的配置是“必须的”。其实我这个模块的需求他又不懂，我问他为什么，他只泛泛的说“这样更灵活嘛”。

“灵活性”不是一个褒义词。灵活性是有代价的。通常情况下，一个系统“很灵活”隐含的意义就是：这个系统很庞大，设计很复杂，代码很晦涩，接手这个系统就是你噩梦的开始。最近买的《实现模式》里的说法就印证了我的原则。

另外，追求“灵活性”实际上就是惧怕变更，越是绞尽脑汁想出一些匪夷所思的配置，就越是说明对变更怕得要死。我见过一个系统的用户资料界面，表单中的元素有用户名、编号、拼音、简称、昵称、移动电话1、移动电话2、移动电话3……四个字：雷死我了。

以上说的这些还不是正题。除了害怕变更以外，追求不必要的灵活性还有一个更隐晦的因素：这可以作为在上级面前吹嘘的本钱。上级很喜欢听到“灵活”、“强大”这样的词（虽然仍不及“进度”重要）。能够哄他开心至少能够带来一点长远的好处。

所以有些设计不是完全由用户需求决定的。需求越模糊，“面子驱动”的迹象就越明显。我刚入行那时候也有一段时间沉溺其中，因为别人这么做，我就觉得理所当然的，也吹牛说这个要做的怎么怎么好。结果当用户测试的时候，才明白自己辛辛苦苦捣鼓出来的这点灵活性在用户眼中连个屁都不值，反倒拖累了后续的需求变更。

“面子驱动”这种现象，我想绝非个别的。国人最好面子，不管做什么事情都会有面子的因素在里面。但是在项目中，最好尽量抵制这种影响，以免带来项目范围不必要的扩大。

------------

我的最后回复：

很多回复仍然在强调那些虚幻的“扩展性”和“前瞻性”，似乎我是个目光短浅的技术人员，从来没考虑过这些问题。实际上我不但想过，做过，而且在这上面吃过很大的亏。

有足够经验的开发人员和架构师都会注意到这一点。下面是 ThoughtWorks 软件架构师 Neal Ford 在“演化架构与突发设计”一文中提到的：

“架构与设计的最后一个全局关注点，我将之称为过度的一般性。Java 世界里似乎有一个弊病：通过尝试使解决方案尽可能一般化来过度设计解决方案。这样做的动机十分明显：如果我们构建许多扩展层，我们稍后可以在其上更轻松地构建更多层。但是，这是一个危险的陷阱。因为一般性将增加熵，所以您将破坏在项目初期中通过有趣的方式演化设计的能力。增加过多灵活性将使对代码库的每一次更改都变得更加复杂。

“当然，您不可以忽略可扩展性。敏捷的移动性在决定如何实现功能时很重要：YAGNI（You Ain't Gonna Need It）。这是避免过度设计简单功能的信条。只实现目前需要的功能，在以后您需要更多功能时，可以再进行添加。我看到过某些 Java 项目为了实现一般性和可扩展性，在架构与设计方面使用了大量折衷，最后导致项目失败。这是个令人感到讽刺的教训，因为本来希望尽可能延长项目的生命周期，结果反而缩短了生命周期。了解如何把握可扩展性与过度设计之间的微妙界限十分困难，而且它是我将反复说到的主题。”

某些项目经理提到扩展性和灵活性之类的概念时，他们完全是将项目本身抛开来谈的。毫不客气的说，他们关注项目对自己的价值大大超过项目对客户的价值。我劝这些人扪心自问一下吧。