面子驱动编程

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

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

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

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

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

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

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

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

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

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

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

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

我的最后回复：

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

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

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

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

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

评论

44 楼 ccxw1983 2009-02-22  

你要是去搞房地产，建好房子了，给我留一套把。我就喜欢精简好用的，实惠啊。

43 楼 kadvin 2009-02-21  

楼主有点太技术化了。
等哪天你做了Team Leader的时候再回过来看这个问题。
对于一个维护多个项目的Team而言
多个项目之间的一致性有时候也很重要。
站在长期的角度，一个Team关于权限，出现若干个实现方案
对于未来的人，更加是一个噩梦；
不使用现有的东西，自己搞一套，也是对公司财产的浪费。

42 楼 风雪涟漪 2009-02-21  

楼主心里明白一些事情就可以了。但在公司做事情并不是那么简单。
引用：
    关于面子：其实小组长问我的时候，项目经理也在边上听。最后是我坚持这样做，他们也不能把我怎样。

既然他是你的组长，我就认为他是你的领导。对待领导的任务，可以认为，要给他的是选择题，而不是只有一种方案。

这件事你可以给他两套技术方案。让他选择。并分析两套方案的优劣，让他自己选。这样会不会好些？

公司技术假民主的问题。。大家技术可以讨论。但最后一定要有人拍板。可以看出来公司长期养成的这种技术民主风气有点过。你的坚持，你的领导也没啥办法。

41 楼 pipilu 2009-02-20  

项目组长在分配任务时也应该跟开发人员交流一下想法：期望的结果、建议的实现方法。
别等人家做完了，再给推倒重来。太劳民伤财了。

40 楼 houniao 2009-02-20  

在中国应该是“关系驱动编程”

39 楼 黑暗浪子 2009-02-20  

个人认为，如果公司有一个有关权限管理的成品，大可以扩展这个component来适应lz的客户的需求。adapt，template，command都可以来帮助楼主实现这个需求。
松耦合啊，松耦合～～
不要把代码写的太死哦，这样以后维护你代码的人要对你腹诽多多，你会整天打喷嚏怀疑有人在“想”你了。
呵呵。

38 楼 salonely 2009-02-20  

晕爆了,这和面子有什么关系...
如果你有一个灵活的,可配置的模块,是可以轻易融入其他项目的.
ZF面子工程很多这不假,但那始终是别人的事情,作为程序员我想我们应该对自己的作品抱着精益求精的态度吧....

不说了,大道理了.总之我觉得平时对自己要求高是好事

37 楼 lotin_2001 2009-02-20  

ZF的项目都是做的玩的，只有有页面他们能交差就可以，根本没什么人用。项目对他们的意义就是评科技奖和吃回扣

36 楼 yiding_he 2009-02-19  

看了大家的回复，我感觉有些东西可能没说清楚。我这里补充一下：

关于面子：其实小组长问我的时候，项目经理也在边上听。最后是我坚持这样做，他们也不能把我怎样。

关于权限：现有的权限管理是一个单独部署的模块，而岗位变更，又是第三个模块里面的。绩效对它们只能读取。一旦“重用”了这套权限，那么岗位变了以后，用户还必须进入权限管理，将这个人的角色改掉。更重要的是，管理岗位变动的用户很可能不是管理角色的那位用户。一旦两边不通气，事情就麻烦了，而我一点办法都没有。绩效模块涉及很多员工，这些员工岗位调动比较频繁，所以我直接选择岗位而不是角色。希望大家以后碰到这样的模块化项目千万别设计成这种样子。

关于变化和灵活性：不错，用户说的不能尽信。所以我也是在充分了解用户的基础上作出判断的。根据用户的岗位来决定权限，这也是灵活性。把权限的判断交给岗位还是交给角色，对绩效模块来说没有本质的区别。至于将来怎么改，谁也料不到，所以还不如花点精力把现有的东西写得清晰一点。另外，还是有人有这种误解：好像我是在牺牲代码质量。这完全把我的态度理解反了。——功能灵活就表示代码质量高吗？

关于规范和标准：规范和标准不能代替设计。特别是模块的业务逻辑设计，编码规范怎么管得了。

我们不像那些大公司，我是需求设计连编码一起做的。我个人觉得这样还好，既长经验，又省得心里没底。

我做需求的那个用户，态度相当好，宁等三分不急一秒。一来他自己就是要用这个系统，二来他也知道我不是为了做完交差，而是真心实意的希望这个模块能给他们带来便捷。

仔细一想，这也算是一种面子驱动哈……

35 楼 xiaoZ5919 2009-02-19  

面子驱动 很形象   
为了 面子 可以把“很烂的东西 说成 很灵活的东西 ”

34 楼 jiayouyx 2009-02-19  

晕。典型的，典型的，没有设计。这些问题都是因为没有前期的设计。

我就郁闷了，怎么设计交给了程序员？？？需求都没有搞清楚就可以开发？而这些需求还得由程序员来设计？

33 楼 jim19770812 2009-02-19  

说的有道理，角色确实是可以写死的。

我一般的做法是把角色写死在数据库里，不提供给用户修改。

而针对于角色的权限配分是可以由用户来设置的。

32 楼 bigbighead 2009-02-18  

楼主，我的观点和你不太一样。
1.别太相信客户的话
  客户的需求他说不会变，就真的不会变吗？
2.从设计角度讲，前面有几位兄弟已经说得挺多的
  从代码重用与设计重用的角度，一开始就把权限模块做成通用可配置的，是很不错的。
  可以灵活应对客户各种的变更(某客户说：“小伙，我想在这里多加一点东西”)
  实施的时候，也非常方便
  假如有变更的话，配置后就可用，无需测试(现在写死的，测试是少不了的，万一有bug，那个痛苦只有自己知道)
3.说一点你那个小组长的“面子”
  其实这里跟面子一点关系都没有，真的，呵呵
4.这一点说多了，呵呵，可能不该说
  如果楼主在设计方面不下点功夫，再过四年，您可能还在做程序员
  无法升到做系统设计或者更改层面的事咯

31 楼 jef 2009-02-18  

想解决问题还是想发牢骚？
问题的实质是什么？
设计不足？过度设计？公司的面子？业务人员面对客户时的谈资？

30 楼 zhang_zling 2009-02-18  

说的的确是事实

29 楼 toostupid 2009-02-18  

反正做B/S系统，
权限控制，I18n, 这些我觉得自然就应该有的，而且人力成本并不高。
在ruby on rails下，一个勉强可以用的权限控制费了我几个小时而已(可能很多人还嫌我太慢)。 当然如果用户要求到 某个column某个record的安全性能我暂时还没想好怎么做。

28 楼 allenny 2009-02-18  

是不是过渡设计还不好说，一定程度的灵活性还是需要的，你真的无法保证需求铁定不会变。

27 楼 vampire423 2009-02-17  

jnduan 写道

yiding_he 写道

有些设计不是完全由用户需求决定的。需求越模糊，“面子驱动”的迹象就越明显。

太深刻了，看完后发现，我参与的项目就是一个大大的ZF的面子工程。

同志们，开发一个系统，不能仅仅是照本宣科完成客户的需求，还应该由业务专家领头，从用户角度出发，设想他日后可能的变动和升级，在设计上做适当的准备，或是作为附加的亮点功能提供给客户，为自己的软件在客户心目中多加点分..

26 楼 jcrjia 2009-02-17  

正在进行中....

25 楼 fflame 2009-02-17  

LZ的小组长不是以前一直合作的吧？如果是一直合作的，这个问题应该不会提出……

另外，小组长，这个职位的概念是啥……