面子驱动编程

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

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

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

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

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

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

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

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

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

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

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

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

我的最后回复：

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

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

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

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

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

评论

104 楼 terryh 2009-11-29  

yiding_he 写道

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

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

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

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

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

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

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

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

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

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

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

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

我的最后回复：

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

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

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

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

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

过渡设计!

103 楼 PetriNet 2009-11-24  

我们的则是香港人驱动编程（头儿都是香港人），呵呵，香港人很自大，不懂技术，又非常喜欢忽悠概念，唉

102 楼 taochenpfj 2009-11-07  

哈哈，你们是小组长的面子，我们公司直接上升到管理级

101 楼 zcq100 2009-10-23  

怎样的设计才既灵活而且又不过度？

100 楼 yiding_he 2009-10-19  

jeff312 写道

yiding_he 写道

jeff312 写道

liusu 写道

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

事实是，LZ不应该站在他自己的角度上看这个问题，显然你程序员做出来的东西是公司的不是你的（业余时间搞出来的开源项目另说），对产品的评估当然也必须站在公司的角度来做。显然，一个被你写死了的功能对于公司来说是不可接受的，把公司的项目或产品绑架在你个人身上怎么可能被公司接受。

我没那么不负责任吧。难道不是我的我就不管了？你哪里看出来这个东西绑在我身上了？现在我已经跳槽了，那东西交接得好好的，几个月来没人因为设计上的问题找我。

我没说过你是不负责任的人呀，但万一交接不好人家回来找你，你又很负责任，岂不是累死自己？
前面说过，没有看到具体实现，不可能判断到底是小组长过度设计还是LZ写得太死，我只是从小组长的角度来看这个问题，并且认为他的担忧有足够的道理，你可能对自己的设计很有信心，但不能强求所有的人对你那么有信心。
我见过交接做得差的，结果非常非常的糟糕，作为小组长，这种担忧绝不是多余的，你如果已经当上了小组长，很快就会明白了。

要从小组长的角度看问题，那就四个字：用人不疑。你担心可以，你提建议可以；但你想插手，这事情的性质就不一样了。另一方面，“过度的一般性”真的能解决问题吗？在这里个例子里，权限设计同用户工作方式不一致的弊病已经显现出来了，不能再走下去。

99 楼 jeff312 2009-10-19  

yiding_he 写道

jeff312 写道

liusu 写道

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

事实是，LZ不应该站在他自己的角度上看这个问题，显然你程序员做出来的东西是公司的不是你的（业余时间搞出来的开源项目另说），对产品的评估当然也必须站在公司的角度来做。显然，一个被你写死了的功能对于公司来说是不可接受的，把公司的项目或产品绑架在你个人身上怎么可能被公司接受。

我没那么不负责任吧。难道不是我的我就不管了？你哪里看出来这个东西绑在我身上了？现在我已经跳槽了，那东西交接得好好的，几个月来没人因为设计上的问题找我。

我没说过你是不负责任的人呀，但万一交接不好人家回来找你，你又很负责任，岂不是累死自己？
前面说过，没有看到具体实现，不可能判断到底是小组长过度设计还是LZ写得太死，我只是从小组长的角度来看这个问题，并且认为他的担忧有足够的道理，你可能对自己的设计很有信心，但不能强求所有的人对你那么有信心。
我见过交接做得差的，结果非常非常的糟糕，作为小组长，这种担忧绝不是多余的，你如果已经当上了小组长，很快就会明白了。

98 楼 yiding_he 2009-10-18  

jeff312 写道

liusu 写道

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

事实是，LZ不应该站在他自己的角度上看这个问题，显然你程序员做出来的东西是公司的不是你的（业余时间搞出来的开源项目另说），对产品的评估当然也必须站在公司的角度来做。显然，一个被你写死了的功能对于公司来说是不可接受的，把公司的项目或产品绑架在你个人身上怎么可能被公司接受。

我没那么不负责任吧。难道不是我的我就不管了？你哪里看出来这个东西绑在我身上了？现在我已经跳槽了，那东西交接得好好的，几个月来没人因为设计上的问题找我。

97 楼 jeff312 2009-10-16  

liusu 写道

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

事实是，LZ不应该站在他自己的角度上看这个问题，显然你程序员做出来的东西是公司的不是你的（业余时间搞出来的开源项目另说），对产品的评估当然也必须站在公司的角度来做。显然，一个被你写死了的功能对于公司来说是不可接受的，把公司的项目或产品绑架在你个人身上怎么可能被公司接受。

96 楼 songze39 2009-10-15  

我们现在也在做你所说的面子工程,但是还是有必要性的.不同的项目都共用了,能减少很多开发量.

95 楼 liusu 2009-10-15  

看了讨论发现LZ真郁闷， 对牛弹琴嘛

不是有那个境界一说，

看山是山，
看山不是山
然后看山又是山。

Lz一直强调他是在第三层得基础上来讨论的，结果很多人一直劝LZ要看的远一点，要看到第二层去。

94 楼 yiding_he 2009-10-14  

最近又碰到一个项目，不过是一个网站而已，竟然要用到 JBoss ESB

93 楼 Max_1106 2009-10-11  

稍微大点的公司都这样
项目都是做为上面看的
项目在短时间内赶出来了，领导有面子了，这就是绩效啊，说明领导管理有方
说明领导可以在年底多拿点钱
具体实施的程序员类，就累的要吐血了，有的时候一个功能用户根本不会那么使用，费用做出来，做到后面都没办法维护了，真是无语

92 楼 勉勉强强 2009-10-07  

满足需求，但防止镀金。又一个案列～

91 楼 jerry_shen 2009-10-05  

我就不明白了，一个权限系统有这么复杂吗，我丢出去的带权限系统的小东西也都是数据库驱动，带界面和单向加密密码的。真没多少工作量。

90 楼 jeff312 2009-09-30  

说实话，单从LZ的表述上看，很难看出是小组长正确还是LZ正确。不过我是做产品的，想来想去，还是觉得做成可配置较好。

LZ说，“用户现有的工作方式基本上不会变化，至少在项目生命周期内不会，客户也是明确的说过不需要那么灵活的配置”。实际上这是不可能的，你根本无法预测用户的工作方式到底会不会变，用户总是很nasty，千万别以为他说不会变就真的不会变，到时候他真的变了，你们全都要死 —— 换句话说，如果你那时已经走了，你的同事包括那位可能还没走的小组长，全都要死。你写好的这个模块，到那时价值完全是零，所有工作都只能从头再来，而重头再来，意味着你花费不少心思清理掉的bug又都会一个个地跑回来，甚至再带上十个八个新的。

其实说起来，即使用数据表配置权限模块也有粗细之分，刚开始可以不用太复杂字段太多，但大体框架总该有的。

89 楼 poson 2009-06-25  

记得以前写了一个小管理，只有只有几百K。因为文件太小，老大还叫我加点图片进去，让exe文件的体积大一点。。。

88 楼 green_land 2009-06-25  

仔细想想有时情况还真是这样的

87 楼 BaSaRa 2009-04-16  

扩展性是要看项目而言的，太多的扩展性完全没必要，项目就是项目，又不是产品

适合这个工程，做到一定扩展性的就可以了

PS：面子驱动这个名词不错

86 楼 elfmtian 2009-03-31  

没有办法 谁叫我们是社会注意特色国家呢，一个系统搞的维护比应用还大，还冗余，你说能怎么办。用户用的都麻烦。不过灵活性的代价真的很大

85 楼 hepeng421 2009-03-23  

作为一个系统，需要一个比较实用的权限模块是必要的。