“过度设计”之真实例子

　　我刚到了一家新公司，公司给我的感觉很不错，不过当开始做第一个项目时便有过度设计的嫌疑，项目不大，基本就实现CURD的功能，用struts2+spring+ibatis+extjs。拿我开发的一个简单的功能来讲，就花了大概一周，如果采用简化的技术，实际上可能只需要一两天。

　　设计太多的分层，以及偶和性太高，添加或修改一个模块太困难了，而且还不知道会不会影响到其它模块。按照项目定义的规范做法，写一个Hello world，创建的代码文件个数必须达到8个！！！！

　　过度分层已经成为过度设计的一个典型。项目经理说，这是另一个项目的架构直接搬过来用的，我们做一下架构上的优化。

　　其实本来就没有什么优化，原来本就是简单的东西，为了显示技术，搞得特复杂。现在所谓的优化，实际上回归质朴而已。

　　记得OSI7层模型就有过度设计嫌疑，可以去看一下现在的教材，都没有用OSI作为例子，尤其没有专门讨论会话层。

　　如何防止过度设计，最好办法就是使用敏捷编程，他的思路就是刚刚好就行，如果有问题，再重构。另外我自己目前的实践方法就是多编程，少设计，好像也能避免。因为当你的任务主要是写代码的时候，你绝不会去写8个类来完成一个helloworld。

　　其实，我所说的就是开发原型，也是《敏捷开发方法》里提到过的方法。

评论

70 楼 xhdwell 2010-09-29  

matt.u 写道

这个其实不应该怪项目经理，这种架构应该算是很典型的Spring+Strtus+IBatis的项目，而且还典型得比较老土。

怪只怪很多搞Java的人跳不出Java思想的圈圈，老是觉得用Java很厉害，要做就做高性能、高扩展性、易维护的应用。所以搞了N多模式和接口进去，导致需要写的东西越来越多。

我也是受害者之一，如果加上单元测试、测试数据还有相关配置的话，的确很恼火。这也是Java的传统文化和限制所制，但我们还是应该好好反思。

多多了解下Rails的思想和Rails like框架，会改变很多人的开发理念的。

可惜Java上面的Rails like框架不多。

SSH、SSI确实老土，但我觉得就现在我们的一些业务系统来说SSH、SSI还是最合理的解决方案。

69 楼 matt.u 2010-09-29  

Java中闻名的框架就那么几个，人家Example这么写，当然很多就跟着这么学了。
目前在跟进Play中，貌似还比较Rails Like。

68 楼 lpn520 2010-09-29  

yangguo 写道

看你是写玩具还是写摩天大楼了。你喜欢的话直接用最原始的方法全部写在一个jsp里面也可以啊，那就更简单了。有兴趣可以看我 web开发的轮回 一文。

哈哈，兄弟，就是这么回事，受教了

67 楼 bonny 2010-09-29  

xhdwell 写道

bonny 写道

呵呵 这个8个文件的设计是比较正常的老式的设计。最近的设计一般都会简化。

helloworld.js这个文件可省，可以写在jsp中，这样减少很多文件，减少很多代码查找和切换快捷键，也减少了http请求数。

service接口可省，直接用实现类即可。这和面向接口设计比较违背，不过多数情况下的确是个累赘。
serviceimpl多数情况下（增删改查）也可以省略掉，action直接调用dao即可。除非有比较复杂的业务操作和多dao关联。


dao可以用泛型简化通用操作，并用代码生成器生成。




这样看来，仅仅需要些的就是jsp  action （serviceimpl） 代码已经非常简化了。

helloworld.js能不能省主要看js的实现是否复杂，我的习惯是分开写，否则JSP会很长，很不好维护。
service接口不能省，他使得业务与控制层完全解耦。
action直接调用dao也不可以，action是control层，主要是负责控制转发的，并不处理业务，如果直接调dao就参与了业务处理，更有可能把事务处理也带进了action中。
分层的好处不在与开发简单，而是便于维护。不要为了开发一时的简便而让你的维护变成一潭没人敢碰的烂泥。

1，一般上，引入了完善的js验证框架的基础上，js代码很少写的很长。如果写的很长，即时你放在一个单独的js文件中，维护依然是个问题，你说呢？

2，sercie接口的存在的确是可以完全解耦，可是有意义么？难道你还想换表现层，或者在不改任何业务层代码的基础上换表现层，我可以告诉你；即时有接口层，你发现先几乎没有一个项目可以做到这点。

在测试方面，没有接口也可以一样测试的很好。

3，dao被action直接调用，我说的是单dao的增删改查，你不要跟我提事务。




事实上我觉得维护最大的问题不是分层清晰，而是要别人理解你的设计；这个是次要的问题。一个人一个想法，终究会乱的。

分层清晰，只是让别人更容易理解你的设计和想法，大家保持一致，更容易理解和交流。

66 楼 xhdwell 2010-09-29  

lpn520 写道

xhdwell 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

确实，以前javaeye上有篇文章说的就是别老骂别人的代码烂，说的很在理。在你没完全理解别人设计的思路之前千万不要妄下结论。别人这么设计是有他的道理的，只是有些原因你还不能理解。你在没有完全理解前就说他过度设计只能说你学的还不够。再过2年你就不会这么说了。

兄弟，哪句看到我骂人了

没说你骂人啊。我说以前有个帖子的标题是《别老骂别人的代码烂》。不是在说你骂人。

65 楼 webee 2010-09-29  

我也遇到雷同的问题，不仅如此，那个包啊多的可绕地球两圈了！看了我真晕，更晕的是，每个包下面就一两个文件，咱也不好说，反正他认为这样非开符合“标准”啦！

64 楼 lpn520 2010-09-29  

matt.u 写道

这个其实不应该怪项目经理，这种架构应该算是很典型的Spring+Strtus+IBatis的项目，而且还典型得比较老土。

怪只怪很多搞Java的人跳不出Java思想的圈圈，老是觉得用Java很厉害，要做就做高性能、高扩展性、易维护的应用。所以搞了N多模式和接口进去，导致需要写的东西越来越多。

我也是受害者之一，如果加上单元测试、测试数据还有相关配置的话，的确很恼火。这也是Java的传统文化和限制所制，但我们还是应该好好反思。

多多了解下Rails的思想和Rails like框架，会改变很多人的开发理念的。

可惜Java上面的Rails like框架不多。

对啊，现在一些项目，其实可以设计的非常简化， 大家如果看过《敏捷软件开发》就知道了， 不应该一直沉迷于老的设计方案， 社会在进步，技术也在进步， 从以前的机器码到现在的高级语言编程， 这就是一种进化的过程

63 楼 yangguo 2010-09-29  

看你是写玩具还是写摩天大楼了。你喜欢的话直接用最原始的方法全部写在一个jsp里面也可以啊，那就更简单了。有兴趣可以看我 web开发的轮回 一文。

62 楼 IcedCoffee 2010-09-29  

bonny 写道

ggpp224 写道

同学，我就是用Extjs的，不过从来不会把js代码写在html或者jsp中，还有你准备把所有的js写在一个文件里？我真怀疑你们以前团队是怎么开发出来的和项目是怎么维护的。

extjs这样做很合理，因为思想已经非常接近CS了。不过传统的web开发还是写在一起比较好。


extjs我也做了一年呢。

这些都是前台的东西和整个架构关系不大...
重点是lz说后面的service和dao都可以不要了..

61 楼 lpn520 2010-09-29  

IcedCoffee 写道

ggpp224 写道

同学，我就是用Extjs的，不过从来不会把js代码写在html或者jsp中，还有你准备把所有的js写在一个文件里？我真怀疑你们以前团队是怎么开发出来的和项目是怎么维护的。

不用再跟他解释了..就是个新手..

明显不是把所有的JS写在一个文件只，我们会把一些用JS封装的组件写在JS的，而是把业务写在JSP文件中， 因为JSP文件里没有任何的HTML代码，首先要搞清楚项目，我们这个就是个管理系统，实现 添加删除修改查询 的功能。

60 楼 matt.u 2010-09-29  

这个其实不应该怪项目经理，这种架构应该算是很典型的Spring+Strtus+IBatis的项目，而且还典型得比较老土。

怪只怪很多搞Java的人跳不出Java思想的圈圈，老是觉得用Java很厉害，要做就做高性能、高扩展性、易维护的应用。所以搞了N多模式和接口进去，导致需要写的东西越来越多。

我也是受害者之一，如果加上单元测试、测试数据还有相关配置的话，的确很恼火。这也是Java的传统文化和限制所制，但我们还是应该好好反思。

多多了解下Rails的思想和Rails like框架，会改变很多人的开发理念的。

可惜Java上面的Rails like框架不多。

59 楼 xhdwell 2010-09-29  

bonny 写道

呵呵 这个8个文件的设计是比较正常的老式的设计。最近的设计一般都会简化。

helloworld.js这个文件可省，可以写在jsp中，这样减少很多文件，减少很多代码查找和切换快捷键，也减少了http请求数。

service接口可省，直接用实现类即可。这和面向接口设计比较违背，不过多数情况下的确是个累赘。
serviceimpl多数情况下（增删改查）也可以省略掉，action直接调用dao即可。除非有比较复杂的业务操作和多dao关联。


dao可以用泛型简化通用操作，并用代码生成器生成。




这样看来，仅仅需要些的就是jsp  action （serviceimpl） 代码已经非常简化了。

helloworld.js能不能省主要看js的实现是否复杂，我的习惯是分开写，否则JSP会很长，很不好维护。
service接口不能省，他使得业务与控制层完全解耦。
action直接调用dao也不可以，action是control层，主要是负责控制转发的，并不处理业务，如果直接调dao就参与了业务处理，更有可能把事务处理也带进了action中。
分层的好处不在与开发简单，而是便于维护。不要为了开发一时的简便而让你的维护变成一潭没人敢碰的烂泥。

58 楼 bonny 2010-09-29  

ggpp224 写道

同学，我就是用Extjs的，不过从来不会把js代码写在html或者jsp中，还有你准备把所有的js写在一个文件里？我真怀疑你们以前团队是怎么开发出来的和项目是怎么维护的。

extjs这样做很合理，因为思想已经非常接近CS了。不过传统的web开发还是写在一起比较好。


extjs我也做了一年呢。


另外我觉得楼主的确是个新手，质疑也是在没有理解原有设计。但是他提出的解决方案其实已经非常接近rails等非常现代的设计了。

57 楼 IcedCoffee 2010-09-29  

lz想回归大自然，把所有代码写进jsp就可以了...

56 楼 IcedCoffee 2010-09-29  

ggpp224 写道

同学，我就是用Extjs的，不过从来不会把js代码写在html或者jsp中，还有你准备把所有的js写在一个文件里？我真怀疑你们以前团队是怎么开发出来的和项目是怎么维护的。

不用再跟他解释了..就是个新手..

55 楼 ggpp224 2010-09-29  

同学，我就是用Extjs的，不过从来不会把js代码写在html或者jsp中，还有你准备把所有的js写在一个文件里？我真怀疑你们以前团队是怎么开发出来的和项目是怎么维护的。

54 楼 lpn520 2010-09-29  

xhdwell 写道

jasph77 写道

构架师 自然有架构师考虑。。
要不然人家怎么坐上这个位置，你还是一个普通的程序员。
架构师也是个人，他的架构必然也有不完美地方。

最讨厌那种，整天说这个不好、那个行，自己又没解决方案。

确实，以前javaeye上有篇文章说的就是别老骂别人的代码烂，说的很在理。在你没完全理解别人设计的思路之前千万不要妄下结论。别人这么设计是有他的道理的，只是有些原因你还不能理解。你在没有完全理解前就说他过度设计只能说你学的还不够。再过2年你就不会这么说了。

兄弟，哪句看到我骂人了

53 楼 云和山的彼端 2010-09-29  

楼主，跳一回槽就明白了。用到Spring的项目，至少一半都是这么做的。

52 楼 bonny 2010-09-29  

WWQQ 写道

我们的还好 后台CTO一人搞定 ， 你想要什么数据 他用JSONArray 返回给你， 然后页面的设计 数据的填充 效果的展示 想怎么弄就怎么弄。 玩转JS 呵呵

这个设计倒是很有新意。非常喜欢。业务、关联数据等的处理你们框架有什么更好的解决办法么？还是老办法？

51 楼 lpn520 2010-09-29  

xhdwell 写道

lpn520 写道

wangking717 写道

真想看看那个HELLOWORD分8个的代码，让我见识一下。

让你见识一下传说中的8个文件：

前端
helloWord.jsp                //页面文件，不用说了
helloWord.js                 //javascript文件

Struts的Action，就叫动作层吧
HelloWordAction.java         //Action类文件，客户端请求到这个类上

业务层
HelloWordService.java        //业务接口， 还用了一套传说中的“面向接口编程”
HelloWordServiceImp.java     //业务实现类，实现上面定义的接口

DAO层
HelloWordDao.java            //数据操作类，关于HelloWord业务的数据操作都在这里
HelloWord.java               //HelloWord表的ORM的对象
HelloWord.xml                //HelloWord表操作的SQL语句，ibatis的sqlmap

看了这个结构觉得已经很简单了啊。是最正常的分层啊。兄弟，建议你多学点设计思想。就不会问这样的问题了。

我只能说这是一个广泛的分层，至少已经用了10年了吧，10年前可能没这么多框架，那是合理的，但现在这么多框架干嘛的，不就为了让你简化开发，那为么框架用起来了，而设计的思路却还是跟10年前一样呢