也谈普元

偶然间看到一个网友慨叹普元的强大，而开发人员的渺小。
不才刚刚参加工作，也在项目中接触到了普元的EOS。对这个平台的初步印象，就是乱用XML，或者说Spring没做好的结果。同后者相比该平台同时失去了类型的表述。

一部机器要进行装配需要组件和零件，软件应该自上而下，分而治之，这是上个世纪70年代，学者们就达成的共识，所以关于“银弹”神话的唯一结论就是——“没有银弹”。
为什么说EOS是没有做好的Spring？
Spring简化了对象的装配，强调重用，是建立在面向对象基础上的，是建立在敏捷测试基础上的，是建立在强类型基础上的；
而EOS则是建立在面向过程的基础上的，建立在不可测试的基础上的，建立在毫无类型基础上的（全是String）
然而EOS也有很多的优点（据小弟不完全发现）：
1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；
2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。
3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。
综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。
这只是我的个人看法，欢迎大家就此话题讨论。

评论

2 楼 upheart 2008-09-18  

<div class='quote_title'><br/></div>
<div class='quote_div'>
<p>1）EOS固化的开发流程强制一个team从一种易于维护的结构组织Web，包括页面，表示层，逻辑层等等。否则的话就需要一个架构师来做出规约，但仍不易于管理；<br/>2）EOS的画图功能让人耳目一新，从“代码即文档”的哲学出发，这些画图很好地诠释了代码表述的内容和结构，给程序的维护带来便利。<br/>3）相对于OO和J2EE传统开发，EOS易于上手，学习曲线较短。但是这一点有争议，EOS的知识不具备通用性。<br/>综上，根据2-8的关系法则，在某些领域EOS的确有其优点，但是认为EOS完全“解放”了程序员，则是不负责任的说法。<br/>这只是我的个人看法，欢迎大家就此话题讨论。 </p>
</div>
<p>第一点：一个成熟的团队都应该有符合实际的最佳实践，比如你用了spring，他有他的约束和实践，但你要在此基础上根据实际情况在做一些抽象、简化和封装，做一些约束和规范。如果你这些都不愿意做，那可以用EOS之类的产品了，虽然不一定适合，不过对于那些根本没有抽象和管理能力的团队还是有点用的。</p>
<p> </p>
<p>第二点：图如果能作为文档，又能作为可执行代码的一部分，那确实很好。不过不是所有的问题都适合用图来解决，你用一个图来弄个最简单的冒泡排序试试，肯定没有代码的表达能力强。图适合整体的规划而不善长算法和细节。所以EOS中业务层也试图用图来解决，我觉得不太合适。可以试试spring web flow或seam的page flow解决页面流的问题，使用JBPM之类的工具解决工作流的方面，他们都很容易图形化的。</p>
<p> </p>
<p>第三点：我不觉得EOS容易上手，只是可以它的IDE帮你生成了一些简单的东西。稍微一点的问题就不好解决，需要深入学习他的那一套东西。EOS的知识不具备通用性也是不容易学习的一个原因。</p>
<p> </p>
<p>如果EOS适合20%的应用场景那还算是他做的不错，怕的是他在一个应用中只能简化20%的开发，而复杂化80%的部分。</p>
<p> </p>
<p>我的建议是，把买这些工具的钱省下来去请一个有经验有水平的真正的程序员，在实践中培养一个稳定卓越的团队，抽象出一个符号自己实践情况的规范和框架（或对其他的框架进行精简和封装）。</p>

1 楼 ladofwind 2008-09-17  

EOS把业务人员和programmer解藕合了,有点点这个意义