面子驱动编程

搞面子驱动，某些人可以捞到更多的油水

题目很容易引起大家对社会上追求面子而浪费、并给开发人员带来额外工作量的的不满。
但是内容与此没什么关系。作为一个做了四年开发的程序员，lz应该是公司的技术骨干了，从后边不给项目经理和小组长面子的回答可以看出。但只是将技术研究深入、却不考虑系统的扩展性、可维护性，将一些可以、而且应该灵活配置的参数写死在程序里，这样的人放在哪个项目都是有前瞻性视角的领导所头痛的人物。
且不说不要相信需求不会变化，就说以后谁来维护这段代码，就是个大问题，除非lz永远不离开此公司、记忆力也超强的好。如果在文档里没有对权限机制的详细描述，可能让另一个人来介绍此模块如何进行权限分配和管理也做不到。从这些角度看，lz真的不像是做了几年的技术骨干，倒像个刚出校门没两年、还只是沉迷于代码实现、对分析和设计漠不关心的新手

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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