模块化Java：声明式模块化
本文是模块化Java系列文章的第4篇，介绍的是声明式模块化。文中描述了组件如何以声明的方式来定义并组织在一起，而无需让代码依赖于OSGI API。
新闻
微软开发主管临别诤言
作者 Niclas Nilsson 译者 郭晓刚 发布于 2007年11月28日 下午6时54分
Jay Bazuzi曾任C#编辑器的开发主管，现正离开微软。他在离开之前令人惊讶地给旧日伙伴留下了一些尖锐的临别赠言：“OO不是一时三刻的流行”，“用用别人写的代码也不要紧”。
Jay一开头就说：
在我离开之前，想要说说我对微软的软件开发的一些想法。
他的帖子火力集中在他认为改进潜力最大的5个主题：
- 最清晰的代码是最好的。
- OO不是一时三刻的流行。
- 用用别人写的代码也不要紧。
- 用设计来赶走问题。
- 最重要的：我们可以做得更好。
虽然Jay已经掏心掏肺，不过并没有多少人回帖。Alex Barnett觉得这些话在微软关起门来说说就好，但除此之外这个帖子倒是没有出现想象中的口水仗。
可悲的事实是，Jay说的问题并不是微软才有。如果换掉微软的名字，很多公司恐怕都会觉得说的是自己。比如，关于清晰的代码，Jay写道：
微软的大多数开发者都还没有认识到尽力编写清晰的代码能带来多么巨大的价值。有一次我看见有人提交一段代码，他在一个600行的函数里增加了200行。这个函数本就有差不多597行属于太长了。用“Extract Method”方法把函数分成小块；用“Extract Class”方法来驾驭由于前一步骤而霎时间出现的方法数量大膨胀。别停下，还可以继续改进。
谈到缺乏面向对象的思维时，Jay举了近年由于安全原因而处理缓冲区溢出的例子。他们写了很多工具来检查，保证当操纵缓冲区时，总是额外传递了一个参数来代表缓冲区的正确长度。Jay很不满意这种解决方法：
喂，当你发现自己总是将几个数值一同传来传去，为什么不把它们放到一个类里面？先做到这一步就好，多态、继承、封装可以以后再说。
正确处理对象不是易事，重用对象就更难了。微软似乎患上了流传多年的“不是自家发明（Not invented here）”综合症，而且排斥的对象不仅仅是来自微软外部的代码。
目前，Visual Studio代码库里有大约十来种C++ String类的实现，大多数都是从MFC硬改出来的。用这些类已经比把缓冲区传来传去强多了，但是，喂……那些编写类库的家伙可是拿工资全职干这个的（难道不比你干得好）？为什么你还不用STL或者ATL？
不光是C++有这样的问题……在.Net Framework的最初实现中，哈希表的实现我都数不清。同学们！我们还是来点类库吧。
Jay给全世界的开发者们送上的最大礼物，还是他对如何持续提高的讨论。Jay说他曾经担任一个非常没经验的团队的经理，而在一年后，比起工作内容相近的其他更富经验的团队，这个团队的工作效率和代码质量都要更高，而且每次都能按计划完成。
Jay将之归功于团队能够持续地提高自身。他列出了一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
- “要保证这个问题不会再出现，我该怎么做？”
- “要想少出些Bug，我该怎么做？”
- “要保证Bug容易被修复，我该怎么做？”
- “要保持对变化的快速响应，我该怎么做？”
- “要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
查看英文原文：Surprising criticism from parting Microsoft development lead
微软出了点问题
发表人
firefly sen
发表于
2007年11月28日 下午7时44分
Re: 微软出了点问题
发表人
超 陆
发表于
2007年11月28日 下午9时6分
Re: 微软出了点问题
发表人
Xiaogang Guo
发表于
2007年11月28日 下午10时5分
Re: 微软出了点问题
发表人
yi cao
发表于
2007年11月28日 下午10时36分
Re: 微软出了点问题
发表人
Bob Yang
发表于
2007年11月30日 上午1时49分
Re: 微软出了点问题
发表人
Jeffrey Zhao
发表于
2007年11月30日 上午10时47分
个人的一点评论
发表人
Ye Zheng
发表于
2007年11月29日 上午8时57分
啥问题
发表人
Cao Li
发表于
2007年11月29日 下午11时1分
-
我觉得伟大的微软出了点问题，难道是要用静心口服液才能治好？^_^~~~
上面的那位朋友的观点先不说，以一个局外人来看大家对asp.net什么感觉？我是觉得这个东西非常非常非常非常的烂~~简直就是一个大玩具而已。别的不说就问在asp.net中美工在那里？它所鼓吹的几大特点
1. 基于事件的
2. 所见即所得
3. 非常容易使用
……
可是我们看看，基于事件带来的问题~也就是web form的问题，所有的东西都交缠在一起开发者无法灵活的改变~美工设计好的一个非常漂亮的布局或表格之类的到了asp.net中就必须变成那些恶心的控件什么——gridview之类的~是简单使用了可是美工设计的页面变成了丑八怪~
如果是为了解决线性方式带来的问题大家都用ajax了。
面对一个一个新技术微软只能忙与迎战啊~每一个东西都是自己开发它的社区重来就没有红红火火过。这些原因都是由于微软的一些设计是封闭式的架构~比如我们讨厌asp.net想自己开发一个 ~如何办？不好办啊，你还要捎带的会IIS的ISAPI设计~不然你没有办法设计~而且由于asp.net设计的问题根本没有办法有第二种web服务器~~这样社区要是红红火火起来才怪。
我建议微软只制定标准和基础实现把一部分东西是开放式的设计~这样社区火起来以后会发现省了不少钱（原本要自己提供的，现在由别人免费为你做了相同的服务，不省钱省心才怪。）双赢~~^_^。
不知道是不是要为微软送点太太口服液之类的~^_^更年期。 -
Asp.net不等于Web Forms. 就Web Forms来说,它也不是一无是处,不然Java世界搞什么JSF做什么?
讨厌Web Forms,你完全可以用Asp.net 提供了扩展机制(HttpModule, HttpHandler),重新做一套合适的东西.MonoRail正是这么做的;微软自己的MVC框架也是这么做的.这个并不需要使用ISAPI.
没有第二种Web服务器?我自己没有试验过,但是据说,Apache上也能跑Asp.Net(当然,前提是装了.Net Framework,或者Mono). -
JSF在Java世界里也不招人待见。
-
JSF在Java世界里也不招人待见。
暂时而已，因为asp.net和jsf还不成熟，同时因为历史的发展出现了一个偶然因素：ajax。ajax的出现掩盖了asp.net和jsf的光芒，将web编程的重心从服务器端移到了浏览器端。 -
关于这篇帖子，我在自己的blog上发了点感慨。
微软开发主管的临别赠言 -
ASP.NET的开发效率应该是最高的，拖拖控件就OK了，最适合我们这种代码民工们用
-
冷静一点看待这个问题,其实HTML本身的缺陷不容忽视,在这样的协议面前,能做好确实不是易事,目前的框架都没有可以完整解决WEB开发的所有问题,都有长有短.MS只是提供了N种方法的一种.其有些思想还是值得借鉴和学习的。
但是社区的问题,我比较同意你的观点,微软的确比较封闭,我也不喜欢这点，而且在微软的框架里面做一件事，有X种方法，面对的是MSDN几个G的文档，不过我的确佩服做微软平台的开发人员…… -
您对于ASP.NET的评价说明您还不了解ASP.NET，或者人云亦云，或者得了ASP.NET腐败强迫症，呵呵。
8 条回复
关注此讨论 回复