中国设计人员的悲哀

最近写了一本书，免费放在网上（http://redhat.iteye.com/admin/blogs/1007884）供大家讨论，两个星期过去了，没有任何人反馈。作者翻看了中国人写的几本关于设计模式的书籍，感慨万千，有的没有参考书籍和文献，有的一些概念完全讲错了（例如IoC，老是只和实例化撤在一起），几乎清一色没有严谨论述，不知道看完对OO能理解几分，和国外的几本书籍相去甚远。

难道中国技术设计人员都如此浮躁？那些OO的大师们，没有一个是没有经过数十年如一日的历练才造就的，中国人都想在一两年或者甚至一个下午把设计模式和OO搞懂，是太聪明了还是太愚昧了？

大家看到技术，往往向技术扑过去，觉得会使用spring,Android就很了不起，可惜看看写的代码，就明白他们还没有理解为什么，也不知道真正能作什么就开始，实用这些技术写的代码，避免重复和扩展性，可伸缩性始终是个遥不可及的神话。

唉，浮躁的社会，每一个技术人员学习两年开发和技术都想爬向管理，我们中国永远不会出现和理解像martin同学，eric evens同学，eric gammar同学等这样的人才。设计方面的经验和技巧，对OO的领会和运用，岂是两三年就能弄懂的！

没事歪歪了几句，惹得多数开发人员不高兴了，先在这里诚挚地道歉了！

发现大家多数都在评论我的书籍，我只是感慨现状而已，至于我的书籍，我觉得最适合的人群是：
1.重复代码照样出现，而且时间总是你和老板的理由。
2.多个模式间你不知道如何选取，感觉都可以。
3.并且你在开发中对模式仍然念念不忘，为了使用模式而设计，不是自然而然由内而发。
4.仍然自负的告诉客户，我们做的就是这样，你的需求无法实现。
5.最后，扪心自问下：什么是OO，OO带给你的什么，你在设计中如何使用OO的，它的封装和粗粒度给你带来了什么，如果这些你懂得话，那你没必要看我的这本书籍了，因为我就是想让大家知道什么是OO，而不是设计模式。
6.如果觉得你现在解决的问题最麻烦的是给领域问题建模，而不是模式，因为你是由内而发，使用/创造模式的，根据问题来的，那么，你的水平高于本书的水平，这里有兴趣我们可以做其他讨论。

发了总觉得有点不妥，再道歉！

这标题打击面也太大了，改一下比较好，像您的书里的知识虽然有用，说实话也没有超出google的范围，和原创性的原理，方法，工具比，还是不及的。单从软件工程的角度也是这样，比如Martin Fowler同学，Eric Evans同学，Eric Gammar同学。当然即使是他们也不需要迷信。为什么呢？因为软件工程属于工程管理的范畴，并不是纯粹的数学逻辑，没有完全的对与错，只是一些方案或方法论的集合

看来你没有仔细看完书籍，虽然讲的全是老掉牙的设计模式，我承认任何人讲这些设计模式都是拿前人总结的那23个在说，“网上可以搜到？” 这句我颇有异议：
1.诚然讲的是老掉牙的设计模式，我从OO的眼光来看它们，我没发现每一个和别人写的相同，包括我分析问题的方式。
2.我扩展了一些设计模式，不管是讲解还是把它们综合，比如像State模式，给出了Enum方式的State模式，我认为你都没办法把它们抄回来。
3.我在文章的结尾对OO设计的看法，请问您，这些您去哪里抄写去，哪里可以google到？

请不要读GoF写的23个模式设计，就告诉他们：“你们写的我们早就可以找到，因为你们就是把我们大家OO开发的一些解决方案综合起来，我们大家早就告诉你们四个人了！”

中国人写书的悲哀在于，要么把别人的书完全抄过来做些低级的修改，要么总是臆想别人写书就是把书抄过来，随便做些低级的修改。

中国目前的大环境下,浮躁是必然的趋势,技术人员无论在待遇还有地位上都得不到重视.你谈论的设计模式很好很优雅,但是现实的情况是你没有办法把牛刀用在杀鸡上.很多公司不需要所谓多么优雅的代码设计,这就好像你在落后的乡村硬要推广你的别墅高尚生活.国外的技术氛围很好,但你没看到人家起步比我们有多早,很多东西需要时间的积累.

其实我们现在最缺的就是这类技术人才，记起我们很久之前做过的一个项目，使用贫血模型设计复杂领域的问题，早就得结果就是service写了一些逻辑，然后大量的逻辑写在pl/sql上，号称是速度快了，但是，花了那么大的代价维护，加之重复的代码，拿出1/10的钱花在硬件上完全可以解决所有问题（当然没有测算过，一个函数使用pl/sql是快了,但是几万个pl/sql写的逻辑真的比java实现的逻辑快吗？如果一两个处理数据出了问题，我们可以专门为其实现更快的方式——使用pl/sql，这里不再讨论），后来另外一家公司要我们的代码，但是要使用DB2，结果就是根本不可能使用，因为我们大概500左右核心的pl/sql包，有人拿了其中2个packages做重写，写了2个礼拜才重写完，里面的错误不计其数。

相信现在这样的代码在电信/金融保险等领域出现很多（使用贫血模型，大量逻辑都是pl/sql或者其他存储过程实现的）。

国外没有看见在60-70年代，大多数开发人就想做个管理人员发大财，只是我们目前确实太浮躁了。

另外，你说的对，杀鸡用牛刀，其实不是杀鸡用牛刀，是杀牛用牛刀，但是老板不懂，往往告诉你，那是鸡，不是牛。

楼主说得好，我要把楼主写的设计模式分析下下来好好学习学习，我做J2EE的，我觉得设计、架构才是J2EE的核心，不过我菜鸟，估计没法给楼主提什么建议。

首先我要为楼主的行为叫好，虽然不大卖座，但还是非常积极的行为的。

关于浮躁，不想多说，中国的大环境如此。

我花了40多分钟，过了一下楼主的书。发表一下个人愚见。好的地方就不多说，说一下我认为不大好的地方：

1.做为设计的老鸟，我想大家多多少少都读过设计模式的书。但大多数设计模式的书都是比较泛泛，缺少实际项目中的例子，不好理解。而比较好的java设计模式的书，毕定是head first design pattern.搭配head first ooad来看，是提高内功的比较好的方法。从你的书中，我也看到很多head first系列的影子，想必你也一定研究过。那么你这本比之head first design pattern,有什么出彩之处？

2.你加入了很多新的东西，比如什么泛型、enum、hibernate注解、ioc、aop等新的内容。好的方面是有新的东西，但坏的方面也比较明显，容易显得太杂，设计这种东西，还是简单点，容易理解的好。毕竟东西一多，人容易分心，吸收的思想反而不好。

3.还是缺少实际开发中的例子，国外的很多书也是如此，不单你的。一切都没有比落地的代码更能说明设计模式的思想。毕竟设计的人，都是有多年工作经验的人，怎么也看过一些设计的书的，没有代码融会贯通，很难往上提高层次。至于工作几年，没什么经验的人来说，就更加难理解，很容易陷入泛泛。我认为设计这种东西是这样的：codding-阅读-应用-思考，反复以上。

4.很多牛人，看不上楼主写的东西。菜鸟初哥又不大关注。所以出现了不卖座的现象。

厚积而薄发，与楼主共勉！

这软文写的太简单了点吧

 

 说的实在啊！