书摘几则

书摘几则

IT革命歌曲 - 我有一把新锤子。

http://yishan.cc/blogs/xin/archive/2006/04/28/473.aspx

中速，豪迈地，RAP
(四川话中，‘锤子’好像不是褒义词，当然，
这并不能妨碍我们豪迈的情绪）
我有一把新锤子，问题当成钉子看。
我刚学了屠龙术，猫狗当成龙来宰。

Socket 已经过时了
要用就要用Web Service

当我学会了OO，所有的不OO代码都要重写，因为它们看起来不够OO，
没有对象，创造对象，也要OO。

当我学会了“存储过程”，所有SQL的访问都要重写，
不管原来是怎么实现的，因为“存储过程”可能会快一点。
虽然我们只有200 个用户，但是我要为200万个用户设计。

当我又听说了强类型的数据集，所有SQL 访问当然要重写，
包括“存储过程”，因为它们不够酷，
至于用户的需求，系统的稳定性都可以暂时不管，因为我的类型是最强的！

我有一把新锤子，问题当成钉子看。
我刚学了屠龙术，猫狗当成龙来宰。
【从头反复】

这首歌是《移山之道》的作者邹欣老师在2006年写的，其中某一段写的是我。那会儿学了点新技术，总想在哪儿都能用上，OO、设计模式、强类型数据集，莫 不如此。工作了一年，回想起当时的我，真是汗颜无地。现在人慢慢地冷静下来，对面向对象和设计模式也有了一些反思，这里先录几段书摘，了解一下别人的想 法。

《Better, Faster, Lighter Java》by Justin Gehtland and Bruce A. Tate

2.1.1.2 Design patterns
Treat design patterns like a framework that you purchase. Each one has a cost and a benefit. Like a purchases framework, each design pattern must pay its own way. If you want to embrace simplicity, you can't build in each and every design pattern from the famous Gang of Four book, Design Patterns, by Erich Gamma, Richard Helm, et al. (Addison-Wesley).

True, many design patterns allow for contingencies. That's good. Many Java gurus get in trouble when they try to predict what the future might hold. That's bad. The best rule of thumb is to use design patterns when you've physically established a need, today. You need expertise on your team that can recognize when a given situation is crying out for a particular pattern. Too often, developers buy the Gang of Four book, or one like it, crack it open to a random page, and apply a pattern that has no problem. Instead, it's better to find a difficult problem, and then apply the right pattern in response. You need experts on a team to apply any technology. Design patterns are no exception. In other words, don't impose design patterns. Let them emerge.

2.2.2.4 Design patterns
There's an inside joke among many Java consultants. You can often tell which books inexperienced developers are reading by reading their code. Sometimes, it's the reader's fault. When you read about a technique, you're anxious to try it out. But don't just start coloring on the walls. Use a coloring book first—like a sample application.

Sometimes, the problem lies with authors, who often oversell ideas or solutions. Other times, the problem lies with frameworks. If you want to know what I mean, pick up a book that deals with EJB design patterns. Now, count the number of design patterns that do nothing more than work around EJB features that stink. Or look to the seminal Gang of Four patterns; they are workarounds for problems with C++.

For this reason alone, many influential consultants abhor design patterns. I'm not in that camp. But let the need for a design pattern emerge before you work it into an application. In other words, wait until you have a problem before you look for a solution.

《走出软件作坊》by 阿朱

这是一本靠谱的书。

p. 60，走钢索的人——架构师

有一部分所谓的架构师，技术超深厚，框架堪比Spring之类，但自己一个人闷头写框架不断优化，力竭使用最先进的技术思想，希望把最豪华的设计模式融进去，希望把OSGi融进去，希望把AOP融进去，全无视那些想利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢，还是在满足个人技术幻想呢，还是在实验呢？到底在干吗？价值在哪里？

…………

我手底下有个框架开发员。他的技术渴望很强烈，为了技术难题攻克，可以不吃不睡。并且技术敏感度很强，学习也快。所以当时我感觉他是个程序员的料，就把他拉到我的手下。

但是有个问题，他写出的框架代码，在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹，但是他却给大家N根不同长度不同粗细不同材质的木棍，N个 不同形状不同用途的铁锹头。大家会有N种组合。不仅导致他写代码老超任务期，而且也让使用人感觉没多大帮助。使用起来复杂，而且还得配置这个配置哪个，需 要注意的地方太多。业务开发组的同事就不愿意用，还不如把代码自己直接写死了得了。【陈硕：先写死往往比预留扩展接口更加实用】

超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开发组提供一个功能，但你没有拿出来。就耽误人家进度。你多次拿不出来，人家业务开发组还不如自己开发一个呢，求人不如求己。

我最后警告他：OO、设计模式、接口？！和客户一点都没关系！那客户为什么要给我们钱？老板为什么要给开发部钱？开发部存在的意义在哪里？难道是翻译成代码？就这点意义，还要？凭什么？你的价值在哪里？如果你认为自己技术够牛，那么你必须证明你能很快做出来。如果你认为自己技术够牛，最好能牛到，只提供一个函数就解决了他们的问题。别这个代理类，那个聚合类，这个唯一实例类。最好连参数也没有，大家调用一下写一句代码就OK。【陈硕：函数才是最佳的复用单元】

p. 149~150，代码那些事儿——代码编写规范

……大多数刚出道一两年，还有不少在校学生，希望认识并聊聊，要和我聊设计模式、OO、SOA，还有人建议我去看看OO和UML的书籍。

我确实没有阅读过OO的书籍，我不是一个死钻牛角尖的人。我只是有什么问题，就去找解决问题的方法，能解决我的问题就OK，而不在乎我用的正不正宗，也不 在乎我用的是不是OO。可能它是OO的外壳，但是它实质上可能是伪OO，我也不想去深究和区分什么是正宗OO，什么是伪OO。反正能解决我的问题就行。

…………

这样，一个样子像OO的类产生了。它可能只遵守了OO所提了封装，它却没有实现OO所提的继承和多态。所以它可能是个伪OO，但它确实解决了我们的问题。【陈硕：Object-Based多好啊】

…………

我过去领导过架构组。架构组的人在2002年的时候，疯狂迷上了UML和设计模式，人手一本《COM本质论》和《设计模式》。我手下有一个新手，就处处是类，处处是抽象，处处是封装，处处是分离，尽量使代码高内聚低耦合。但是这样的的代码太麻烦，他花费了大量的时间，他看自己的代码赏心悦目，别人看他的代码云里雾里，不阅读懂《设计模式》就按照常规理解业务的思路去阅读他的代码根本阅读不懂，不知道他为什么这样写代码，怪异的很。本来，这位想达到可维护性，可阅读性，却真正的失去了可维护性、可阅读性。这和我前几天看我的朋友周爱民写的《大道至简》中写到：有人希望拿UML去统一用户和软件设计者。殊不知UML有多难理解，而UML设计者却认为UML可以描述一切。就这个道理，要理解你的代码还要去读懂《设计模式》，这要求太高了吧。

所幸这位新手自己都每次写的累，慢慢的也就懒了，觉得确实需要分离的时候就分离，觉得没什么必要的就懒得做了。用他自嘲的话说就是：被磨平了。其实，依我看，他现在这个代码状态才是刚刚好，即照顾了设计扩展，又照顾了实用。真正的纯OO，纯设计模式，可能只存在于教学和科学，而不在于我们的商业软件开发。我们作为商业开发，强调的是叫座的基础上叫好，所以折中方案是必须的，客户和我们自己两相宜就OK，是否符合正宗，就不在我们的商业开发管理范畴了。

《实现模式》by Kent Beck

【陈硕：这是另外一本靠谱的书，此处转摘据李剑等人的译本。“设计模式”与“实现模式”不同之处在于，前者关注类与类的关系，后者的关注范围限于一个类，即如何写好类的数据成员和成员函数。】

p.23, 第四章 动机

一旦代码以未预期的方式发生变化，人们所曾做出的任何预见都不再是万全之策。人们可能会为了防备将来发生的变化而过早考虑代码的通用性，但如果出现了没有预料到而又势在必行的变化，先前的做法往往就会与现实发生冲突。

p.32, 第五章 类

每层接口都有成本：……并不是接口数量越多软件成本就会越少，只有需要接口带来的灵活性时才值得为它付出成本。所以，既然很多时候并不能提前知道是否需要 接口带来的灵活性，出于降低成本的考虑，在仔细考虑“哪些地方需要接口”的同时，最好是在真正需要这种灵活性时再引入接口。【陈硕：现在的IDE很容易帮我们做到这一点，所以让“面向接口编程”见鬼去吧，一开始就用具体类才是王道。真正需要抽象出接口的时候重构一把就行了。】

尽管我们成天都在抱怨软件不够灵活，但很多时候系统根本不需要变得更灵活。

需求和技术都在以不可预测的方式变化。通过预先思考来弄清软件将来的样子，其效果是相当有限的。

所有这些因素——对灵活性的需要、灵活性的成本、“何处需要灵活性”的不可预测——加在一起让我相信：应该在确定无疑地需要灵活性时，才引入这种灵活性。

【陈硕总结：一开始就上OO、模式，等于找死。】