中国设计人员的悲哀

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

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

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

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

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

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

评论

58 楼 redhat 2011-05-05  

Mirima 写道

雖然題目有點大，不過書寫的很用心，有些章節可以直接拿來給新人上課了

只是不清楚lz是想普及還是想要深入。

如果是要普及，我覺得還不夠順，章節的內容和順序還要調整，以適合閱讀

如果是深入，就像在書中寫的
“通过这一章的学习，我相信大家对于基本的单例模式已经有了一个比较充分的认识。其实我们这章讨论的是在同一个JVM中，如何保证一个类只有一个单例，如果在分布式环境中，我们可能需要考虑如何保证在整个应用（可能分布在不同JVM上）只有一个实例，但这也超出本书范畴，在这里将不再做深入研究，有兴趣的读者可以查阅相关资料深入研究。 ”


不偏激就沒有人回應， 再次謝謝lz的工作。

請繼續努力，共勉

如果一个书籍什么都有，那比四库全书还多，要精简，抓住主要的，理解了单例模式，在学点j2ee的知识，对于分布式单例会理解起来很简单，我这里不想讲解j2ee的知识普及

57 楼 redhat 2011-05-05  

skzr.org 写道

看到此问反响强烈16小时有6页了<br><br>楼主说出了不少人的心情也触动了太多人的利益<br><br>建议楼主看看卡耐基《<span style="color: #ff0000; font-size: medium;">人性的弱点</span>》相信你会大有收获的

 

恩，不错，是希望大家能对技术仍能保持追求，不要以为“人性弱点”而放弃改正这些弱点的机会。

56 楼 redhat 2011-05-05  

jianpc 写道

准备看看这本书，希望书中能有更多平民化的代码，而不是泛泛而谈。

完整的 代码在附件里，但是为了书籍本身的精简，我拿出主要的代码部分讲解，可以结合附件查看完整的代码

55 楼 george 2011-05-05  

称赞 一下楼主，请问你的UML图示是用什么软件画的？PowerDesigner?

54 楼 hawelina 2011-05-05  

我觉得楼主的用意还是好的，也是为了中国的IT水平的发展作了一些忧思而已，不想着进步，是永远不会进步的。
我觉得喷来喷去没有必要，到不如把精力用在如何提高水平上不是更好吗？

53 楼 skzr.org 2011-05-05  

<p>看到此问反响强烈16小时有6页了<br><br>楼主说出了不少人的心情也触动了太多人的利益<br><br>建议楼主看看卡耐基《<span style="color: #ff0000; font-size: medium;">人性的弱点</span>》相信你会大有收获的</p>
<p> </p>

52 楼 jianpc 2011-05-05  

准备看看这本书，希望书中能有更多平民化的代码，而不是泛泛而谈。

51 楼 lancelotly 2011-05-05  

现在国内行情是技术要服务于业务，如果技术不能很直观反映出生产性的增长，利润的增长，老板不会鸟你的。在国内专注技术的待遇都不甚理想，国内永远是业务值钱。

50 楼 yata_84 2011-05-05  

CaryGao 写道

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

嗯，中国的现实确实如此，老板只在乎你的项目能否挣钱，其余的一概不管。

49 楼 Mirima 2011-05-05  

雖然題目有點大，不過書寫的很用心，有些章節可以直接拿來給新人上課了

只是不清楚lz是想普及還是想要深入。

如果是要普及，我覺得還不夠順，章節的內容和順序還要調整，以適合閱讀

如果是深入，就像在書中寫的
“通过这一章的学习，我相信大家对于基本的单例模式已经有了一个比较充分的认识。其实我们这章讨论的是在同一个JVM中，如何保证一个类只有一个单例，如果在分布式环境中，我们可能需要考虑如何保证在整个应用（可能分布在不同JVM上）只有一个实例，但这也超出本书范畴，在这里将不再做深入研究，有兴趣的读者可以查阅相关资料深入研究。 ”


不偏激就沒有人回應， 再次謝謝lz的工作。

請繼續努力，共勉

48 楼 soft_xiaohui 2011-05-05  

首先表明我是个编码快两年的小鸟。对设计模式的了解主要是在使用的spring，struts，hibernate，ibatis这些框架上。最近开发效率严重下降了，不是我对知识的不熟悉，也是我考虑的太多了，每每实现一个功能，发现其实代码其实和别的代码实现差不多，自己还要重新写基本一样的代码就很纠结其中，希望实现代码重用，或许这就该用到楼主所说的设计模式了。另外我对设计模式的书籍了解很少，在学校时老师推荐了<java与模式>这本书籍，很厚，在工作中一直没去翻，不知楼主认为这本书怎样？

47 楼 yangyi 2011-05-05  

redhat 写道

skyuck 写道

最近一段时间我在重构公司的产品，已经将一些设计模式溶于到项目中。

再接再厉，但是，没那么简单，过半年或者一年之后，再看看你的代码，是否避免了重复，你是否忘掉了模式再说，当你觉得模式不再那么重要的时候，你的OO就基本掌握了，eric evans的书籍非常好，可以看看，有助于您忘掉模式，而追求根本！

这个我同意，为学日益，为道日损。
ps 楼主我知道您是前辈，您的功力也比我强，我给您投良好，不要再回我了

46 楼 animalfishyu 2011-05-05  

我很赞成楼主的说法，从我本身来看，搞java这个行业快2年了，现在也还是坚持走技术路线，因为在我看来，所谓的项目经理太多了，而牛X的程序员太少，但是个人比较浮躁，很多东西都是为了完成工做而去做，并没有去做深层次的研究，仅限于表面，有时会想，我是不是也去转管理！？确实自己太浮躁了，也很希望和楼主交个朋友，多向楼主请教，好好净化一下自己的浮躁

45 楼 junlas 2011-05-05  

投lz良好

虽然lz说的是这样，但是<b>并不能改变现状</b>，社会是复杂的，反而有人觉得你是打击别人来提高自己。

44 楼 jansel 2011-05-05  

感同身受，CN IT的大环境如此了

1:周围编码的人大多都是几年的？

2:编码超过3年的人大多都在干什么？

3:周围的专家夸夸其谈的有多少？

不说了 顶LZ BS那些投隐藏的

43 楼 redhat 2011-05-05  

skyuck 写道

最近一段时间我在重构公司的产品，已经将一些设计模式溶于到项目中。

再接再厉，但是，没那么简单，过半年或者一年之后，再看看你的代码，是否避免了重复，你是否忘掉了模式再说，当你觉得模式不再那么重要的时候，你的OO就基本掌握了，eric evans的书籍非常好，可以看看，有助于您忘掉模式，而追求根本！

42 楼 czwlucky 2011-05-05  

redhat 写道

CaryGao 写道

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

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

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

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

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

首先感谢楼主的共享精神！
还没有仔细拜读楼主的书，不敢妄做评论。楼主这里提到的大量使用PL/SQL实现逻辑的例子我也听到有人喜欢这样的做法，不过我也是持怀疑态度，任何一项技术都不可能是完美的，都需要和其他技术结合起来去完成一项工作，各自发挥特长才可以做到相得益彰。我和朋友在讨论这样的问题时，有一个现象是产生赞同使用PL/SQL完成业务逻辑的根本原因，就是大家发现现实中很少出现“切换”不同类型数据库，所以才会采取这样的做法。至少，在同一公司内很少会出现从oracle切换到db2的做法。不过，这里楼主说到的是另一家公司要使用这个系统，而数据库不是同一类型。也许有人会说，这种情况是很少会发生的，我们的系统只是一家公司使用，不会出现第二家，这样的认为会是真的吗？从楼主举的例子来看，这样的认为是错误的。

41 楼 achun2050 2011-05-05  

严重同意楼上的说法，我发现我快得了模式病，虽然有时可能多写出来几个类，但是整个系统的扩展性高内聚低耦合特性表现的淋漓尽致，iteye的牛人很多，好书一定要共享，LZ的书值得一读，我不是托，因为我刚入门OO。。。

40 楼 lkj107 2011-05-05  

国内的书籍有种二到贩子的感觉，所以技术的不看国内的，就是翻译过来的也有很多离谱的

39 楼 redhat 2011-05-05  

zhaoxin1943 写道

楼主不要丧气噻。
我已经下下来了，刚看完那本    设计模式解析(第二版)
等再有时间会看你这本的。

这本书籍不错，也在我的推荐书里，平心而论，这本书给我启示不少。