企业应用架构的设计--是面面俱到还是仅仅提供基础服务

有2种思路。

一种是尽可能地将能隐藏的东西隐藏起来，将能封装的功能封装起来，提供给developer的只是一些傻瓜级的API。程序员可发挥的空间很小，比如甚至都不需要知道数据库表。

另外一种是选择好合适的技术架构，做好基础设施的搭建，比如异常处理，权限，工作流。只提供简单的封装，程序员有足够的灵活度。

显然，前者的情况，程序员会比较没有动力。优势是系统的核心程序员无法触及，相对安全。有不少公司都是这种情况，程序员的流动性相当高，不过老板也不在乎。

而后者的情况，程序员会有较高的积极性，容易成长，团队的融合会比较不错。更加符合敏捷的思路。但也许产品或者项目的规模大了后，会导致失去控制。

也许还是应该具体情况具体分析吧 ！

评论

24 楼 lee5593 2007-05-24  

引用

软件不是个人单打独斗,而是一个工程,如果能够学习到更多的工程思想,对自己的成长更加的有利

这句话我到最近才有深刻的体会

23 楼 cherami 2007-05-19  

第一种也不是绝对的导致程序员没有积极性,如果足够的努力,你可以从那个框架学习到很多东西,也可以思考它到底有没有不足的地方.
一句化,进步取决于自己,而不是取决于你在一个什么样的公司.

个人感觉第一种情况对程序员,对公司都更好.
软件不是个人单打独斗,而是一个工程,如果能够学习到更多的工程思想,对自己的成长更加的有利.

22 楼 Godlikeme 2007-04-28  

底层是一个快速开发的技术架构，
是所用技术的集成封装，例如spring+hibernate+webwork+osworkflow+jbossrule+quartz,
在此之上封装一个业务模型，
以实现业务逻辑快速实现。

技术架构封装应该是越简单越好，避免重复发明轮子，技术的替换代价，学习成本，维护成本也低。
至于业务模型，不知道，发现抽象通用的业务模型是mission impossible,

21 楼 抛出异常的爱 2007-04-28  

pupi 写道

确实很难把握这个度。
即使是在某一领域，第一种方案也有自己的问题。
比如普通开发人员和架构的设计者之间就会有一道鸿沟。
另外，前面的朋友也提到了，其实架构本身的维护需要更高级的人才。而且这部分人才升值只怕更快。
还有就是这种架构用一段时间，可能就会过时，又需要花大力气重新开发，并且重新培训。

哪有什么过时的技术？
如果合公司没人会，而且 不能提高效率就不要 架构
如果招到的人都会新的技术，那么转型用的时间与金钱都会少很多。

20 楼 sunnyshuhai 2007-04-28  

这要根据架构设计的目标来判断，1）如果框架的应用范围很广比如通用架构如.NET Framework, 那就应该只提供基础功能给用户。2）如果框架的应用领域很具体比如工作流什么的，就应该提供比较具体的服务。不过这是相对来的。

19 楼 pupi 2007-04-27  

确实很难把握这个度。

即使是在某一领域，第一种方案也有自己的问题。

比如普通开发人员和架构的设计者之间就会有一道鸿沟。

另外，前面的朋友也提到了，其实架构本身的维护需要更高级的人才。而且这部分人才升值只怕更快。

还有就是这种架构用一段时间，可能就会过时，又需要花大力气重新开发，并且重新培训。

18 楼 lkfnn 2007-04-27  

BirdGu 写道

Godlikeme 写道

BirdGu 写道

为什么不先讨论一下第一种框架的可行性呢？

如果是专注某一应用领域的解决方案的公司，那么第一种框架是有可能的。但如果是要针对多种应用领域，通用而又傻瓜......现在有这样的框架存在吗？

我们还是讨论某一应用领域的通用框架的可能吧

如果是专注于某一个应用领域，那就是要尽量往商品化软件的方向靠，尽量增加可以复用的东西。如果不是一开始就走商品化的路，那也一定要沿着项目——解决方案——商品这样的路走。这恐怕是每一个这样的公司都会追求的方向。

走这样的道路大家都知道，最难的是如何把握好过渡的问题。
很多时候并不是方略的错误，而是时机选择的错误。

17 楼 lkfnn 2007-04-27  

pupi 写道

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

利润会不会快速增长不只取决于企业内部，还要看市场环境，如果市场环境好，当然你的假设就是对的，如果市场环境很萎靡那么公司并不愿看到员工成长太快，而事实上根本就不会成长的太快。

16 楼 BirdGu 2007-04-18  

Godlikeme 写道

BirdGu 写道

为什么不先讨论一下第一种框架的可行性呢？

如果是专注某一应用领域的解决方案的公司，那么第一种框架是有可能的。但如果是要针对多种应用领域，通用而又傻瓜......现在有这样的框架存在吗？

我们还是讨论某一应用领域的通用框架的可能吧

如果是专注于某一个应用领域，那就是要尽量往商品化软件的方向靠，尽量增加可以复用的东西。如果不是一开始就走商品化的路，那也一定要沿着项目——解决方案——商品这样的路走。这恐怕是每一个这样的公司都会追求的方向。

15 楼 Godlikeme 2007-04-17  

BirdGu 写道

为什么不先讨论一下第一种框架的可行性呢？

如果是专注某一应用领域的解决方案的公司，那么第一种框架是有可能的。但如果是要针对多种应用领域，通用而又傻瓜......现在有这样的框架存在吗？

我们还是讨论某一应用领域的通用框架的可能吧

14 楼 抛出异常的爱 2007-04-17  

BirdGu 写道

为什么不先讨论一下第一种框架的可行性呢？

如果是专注某一应用领域的解决方案的公司，那么第一种框架是有可能的。但如果是要针对多种应用领域，通用而又傻瓜......现在有这样的框架存在吗？

你说的那叫银弹。。。。出了的话我第一个转行。。。

13 楼 BirdGu 2007-04-17  

为什么不先讨论一下第一种框架的可行性呢？

如果是专注某一应用领域的解决方案的公司，那么第一种框架是有可能的。但如果是要针对多种应用领域，通用而又傻瓜......现在有这样的框架存在吗？

12 楼 抛出异常的爱 2007-04-16  

pupi 写道

任何的老板都会选择max((收入-成本)/成本）的这个公式的，但是问题在于，在作出选择之前，收入，成本这两个数值是老板并不知道的。

收入是由销售部作的年度估计

成本是人员的成本（高程价格高，低程价格低）+可遇见成本（软件没什么源材料要采购。。。所以只有工具成本）

有些公司的收入不稳定

11 楼 pupi 2007-04-16  

任何的老板都会选择max((收入-成本)/成本）的这个公式的，但是问题在于，在作出选择之前，收入，成本这两个数值是老板并不知道的。

10 楼 抛出异常的爱 2007-04-15  

gigix 写道

hurricane1026 写道

pupi 写道

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

如果你是个狗窝，你就算培养出凤凰也养不活凤凰。越是培养人，就越是流动大。这个道理很简单。那些能给高工资的企业无一例外是可以在某个领域获得高额利润的企业。。。只有他们养的起。
对于所有的公司老板来说。max（收入-成本）才是追求。对于自己公司不同定位当然带来了对人员的不同需求。

max((收入-成本)/成本)
实际上还应该考虑风险耐受力在里面。

公式太精典了收藏之

小公司不作框架封装是由于
1找不到好的人才，
2浪费时间。
一个项目一笔钱。
下个项目指不定还作不作这个行业呢
用通用框架浪费小
所以用通用框架。

大公司的活动地盘大多在一个区域内，
所以有足够的时间与精力来作专用框架

9 楼 gigix 2007-04-15  

hurricane1026 写道

pupi 写道

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

如果你是个狗窝，你就算培养出凤凰也养不活凤凰。越是培养人，就越是流动大。这个道理很简单。那些能给高工资的企业无一例外是可以在某个领域获得高额利润的企业。。。只有他们养的起。
对于所有的公司老板来说。max（收入-成本）才是追求。对于自己公司不同定位当然带来了对人员的不同需求。

max((收入-成本)/成本)
实际上还应该考虑风险耐受力在里面。

8 楼 Godlikeme 2007-04-15  

前一种情况的问题在于，框架的成熟程度、学习曲线、和框架的维护成本。需要一个核心团队（2－3）个人维护、完善这个框架，培养新人。项目大了，多了，感觉成本降下来了。可是真的有这么通用的框架可以适用这么多项目么？rob 说，检验框架的标准是能够快速实现业务。业务肯定是丰富多样的，所以在这一点上，对通用框架值得怀疑。

后一种情况的问题在于，撞车保险。team走了人，做的这块东西就很可能大改、彻头彻尾的。由于技术的通用性，找两个替换的人还是容易的，可就是以前设计的东西很难继承下来。

前一种情况同样面临如何维持核心团队的问题，而且核心团队出现问题，比后一种更难解决。

7 楼 robbin 2007-04-15  

pupi 写道

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

一个公司的商业模式决定了这个公司会寻找什么样的人才。

对于ThoughtWorks这种以咨询收费方式做项目的公司来说，它的利润远远高于国内的项目公司，同时承担的风险很小。这种运营模式就要求他需要不断寻找高水平的程序员包装成咨询师赚取高额利润。对于招聘的程序员创造的高额利润来说，给程序员多点工资实在不算什么。

但对于国内很多项目公司来说，行业竞争的加剧导致项目的利润非常单薄，同时风险很高，项目周期不确定性拉长，需求随意变更，项目回款困难都导致了公司必须不遗余力的压低公司运营的成本，从而需要招聘大量低工资程序员来完成工作。

6 楼 pupi 2007-04-15  

本质上，公司最宝贵的财富还是人。

现在更多的公司是找不到合适的人，担心自己公司的开发人员成长太快而导致人力成本过高，听起来实在有些荒唐。也许存在这样的公司和老板，但会不会有点算计过头了？

按照楼上的意思，像thoughtworks这样的公司的人力成本是要增加很快的，但是利润会更快地增长呀。

5 楼 抛出异常的爱 2007-04-14  

pupi 写道

抛出异常的爱 写道

这个好处是老板不希望看到的。。。。效率，可用度，银弹，人员成本才是老板喜欢的。

可是人总是不停地走，人力资源的成本也不可忽视的。就算封装得再棒，熟悉和使用还是需要时间的。老板不在乎，不代表问题不存在。

你如果会的多了，是否会走的更有理？
用第二种方式公司每年成本的增长是非常快的
而第一种方式下人力成本很低，而增长也慢，
业务量增长快时公司有能力快速转型。。。。

第一种方式常常会被用在外企，
第二种方式常常会被用在创业类的小公司中。

程序员的成长对于一个公司来说不一定是好事。

ＰＳ：大多数老板不傻。。那么大多数老板不在乎的事也必有他不在乎的道理。