69,371
社区成员
发帖
与我相关
我的任务
分享工作感想
最近一年都在做一个Framework。经理对这个Framework的雄心很大，我也就做得很郁闷。总觉得方向出了问题。工作之余写了一篇感想，大家提提意见。
We all know the aim of any software framework is to reuse source code, to avoid reinventing the wheel. The original intention to construction a framework is always good, but the result is dramatically different. Why?
I think this depends on the constructer's ambition. More stylized is the work for which they try to construct a single reusable framework, more likely the framework will succeed. Those constructer who are relatively conservative, that is, who focus their effort on a relatively narrow domain will much likely achieve their object.
For example, the orignial aim of MFC team of Microsoft is to construct a framework for OS independent application of wide range. Thus the first version is too complex and somewhat useless. Then they narrow the object to provide a framework for Document-View applicaiton tied to Win32 platform, and the framework becomes the one we see today, which succeeds. Even though, many MFC developers must go around (note unlike tooltip, developers using framework can not simply do not use a feature, they must do go around) some useless functions provided by MFC in their developement. This shows even holding a conservative assumption it is very difficult to assure every pieces of your effort on reusibility can really benifit your users.
On the other hand, framework construction, or more generically, source code reusibility is an object that sometimes impossible to be achieved only by tools on the same level, in paticular the object is tend to cover wide-range applications. This is much like things in mathematical field. When you want to prove a theory about integers, you must use proven theories of real numbers. In computer engineering, to gain reusiblity of a certain level, building right tools from the underlying level is sometimes neccessary.
For example, to gain the reusiblity of database-object mapping was impossible if you only dealt with existing programming language before a fully dynamic programming language that supports rich runtime type information and dynamic class loader, such as Java, was invented. Thus if those work had not been done by Sun, defining a language, defining the corresponding platform, implementing the runtime enviornment, implementing the compiler would be the necessary work for the constructer. By the way, even though, J2EE's CMP is far from perfect.
Another example is that, to gain the resuibily of algorithm was impossible if you only dealt with existing programming language before the invent of advance notion and language feature, such as iterator and C++ template. Before STL was invented, many those thought algorithm was so stylized that they can be implemented in a single framework failed or result in ugly framework. On the other hand, even today, after 4 years of latest C++ standard published, no compiler can fully implement template features. This shows two points:
1. People ofter underestimate the necessary of work to build fundemental principle and tools.
2. People often underestimate the difficulty of work to build fundemental principle and tools.
According to the above examples, we can find another very important fact which administrative stuff of software team dislike. While innovation like a framework often bases on adequate fundamental effort, such fundamental effort is often contributed by irrelevant organizations independently over many years. More the object is innovativet, more likely that is the case. One organization, in particular one has market stress, is unable to provide all fundamental tools of different aspects, such as mathematical theory, language feature, hardware feature, and so on. Only those projects for reusiblity whose aim is relatively conservative can be accomplished by a single organization in a pratical timeframe.
We all know the aim of any software framework is to reuse source code, to avoid reinventing the wheel. The original intention to construction a framework is always good, but the result is dramatically different. Why?
I think this depends on the constructer's ambition. More stylized is the work for which they try to construct a single reusable framework, more likely the framework will succeed. Those constructer who are relatively conservative, that is, who focus their effort on a relatively narrow domain will much likely achieve their object.
For example, the orignial aim of MFC team of Microsoft is to construct a framework for OS independent application of wide range. Thus the first version is too complex and somewhat useless. Then they narrow the object to provide a framework for Document-View applicaiton tied to Win32 platform, and the framework becomes the one we see today, which succeeds. Even though, many MFC developers must go around (note unlike tooltip, developers using framework can not simply do not use a feature, they must do go around) some useless functions provided by MFC in their developement. This shows even holding a conservative assumption it is very difficult to assure every pieces of your effort on reusibility can really benifit your users.
On the other hand, framework construction, or more generically, source code reusibility is an object that sometimes impossible to be achieved only by tools on the same level, in paticular the object is tend to cover wide-range applications. This is much like things in mathematical field. When you want to prove a theory about integers, you must use proven theories of real numbers. In computer engineering, to gain reusiblity of a certain level, building right tools from the underlying level is sometimes neccessary.
For example, to gain the reusiblity of database-object mapping was impossible if you only dealt with existing programming language before a fully dynamic programming language that supports rich runtime type information and dynamic class loader, such as Java, was invented. Thus if those work had not been done by Sun, defining a language, defining the corresponding platform, implementing the runtime enviornment, implementing the compiler would be the necessary work for the constructer. By the way, even though, J2EE's CMP is far from perfect.
Another example is that, to gain the resuibily of algorithm was impossible if you only dealt with existing programming language before the invent of advance notion and language feature, such as iterator and C++ template. Before STL was invented, many those thought algorithm was so stylized that they can be implemented in a single framework failed or result in ugly framework. On the other hand, even today, after 4 years of latest C++ standard published, no compiler can fully implement template features. This shows two points:
1. People ofter underestimate the necessary of work to build fundemental principle and tools.
2. People often underestimate the difficulty of work to build fundemental principle and tools.
According to the above examples, we can find another very important fact which administrative stuff of software team dislike. While innovation like a framework often bases on adequate fundamental effort, such fundamental effort is often contributed by irrelevant organizations independently over many years. More the object is innovativet, more likely that is the case. One organization, in particular one has market stress, is unable to provide all fundamental tools of different aspects, such as mathematical theory, language feature, hardware feature, and so on. Only those projects for reusiblity whose aim is relatively conservative can be accomplished by a single organization in a pratical timeframe.
...全文
请发表友善的回复…
发表回复
dave0037 2002-11-22
- 打赏
- 举报
Oh 这真是精采，关注中
shantian 2002-11-11
- 打赏
- 举报
呵呵。见识了世面，偶先收藏，有机会在看看。
gemingxiaojiang 2002-11-11
- 打赏
- 举报
难道是人有多大胆，地有多大产吗？ 客观规律！！！！！！！
middle 2002-11-10
- 打赏
- 举报
to mrbeaver():
我对所谓“量力而为”也是非常悲观的。请看我的倒数第二段。
我对所谓“量力而为”也是非常悲观的。请看我的倒数第二段。
hbolive 2002-11-10
- 打赏
- 举报
呵呵，开开玩笑啦~~~
middle 2002-11-10
- 打赏
- 举报
to hbolive(紫月亮):
非常谢谢你的批评，不过我希望能够更加具体一些。但是这又涉及了另一个问题。如果太具体，太往语法上靠的话，就会连说英语的人都觉得罗嗦了。比如您的原话：
你的文章怎么这么多语法错误？？
^^^^^^^^^ 这句话里就没有谓语，如果初学汉语的外国人一定会发现，但是你我反而认为很自然。对吗？:-)
非常谢谢你的批评，不过我希望能够更加具体一些。但是这又涉及了另一个问题。如果太具体，太往语法上靠的话，就会连说英语的人都觉得罗嗦了。比如您的原话：
你的文章怎么这么多语法错误？？
^^^^^^^^^ 这句话里就没有谓语，如果初学汉语的外国人一定会发现，但是你我反而认为很自然。对吗？:-)
mrbeaver 2002-11-10
- 打赏
- 举报
当涵盖的方面增多时，成本会更快的膨胀，我觉得其实并不是不可以做大
关键是量力而为
关键是量力而为
hbolive 2002-11-10
- 打赏
- 举报
天！！老兄：你的文章怎么这么多语法错误？？
musictornado 2002-11-10
- 打赏
- 举报
up!!!
mark@@@
mark@@@
middle 2002-11-10
- 打赏
- 举报
谢谢各位，尤其谢谢unrealimage(幻影的咖啡)的译文。:-)
我发现即使翻译自己写的东西也够难的。如果你一天到晚读的都是英文文档，自然而然考虑问题的时候头脑里也是英文。:-) 有时候顺手就用英文写了，而且我希望能够有一天能够让经理看到。
我非常为中文的优美而自豪，但是也为英文排版和中文排版在美观上的差异而忧虑。我想语言——不论是计算机语言还是自然语言——都是工具。中文固然优美，但是有时候不免被某些人——有时甚至是大多数知识分子——变成了孤芳自赏的艺术品。这也是B.S.的观点：“很多优秀的软件甚至都是由不那么优美的语言写成的”。同样适用于计算机和自然语言。
我发现即使翻译自己写的东西也够难的。如果你一天到晚读的都是英文文档，自然而然考虑问题的时候头脑里也是英文。:-) 有时候顺手就用英文写了，而且我希望能够有一天能够让经理看到。
我非常为中文的优美而自豪，但是也为英文排版和中文排版在美观上的差异而忧虑。我想语言——不论是计算机语言还是自然语言——都是工具。中文固然优美，但是有时候不免被某些人——有时甚至是大多数知识分子——变成了孤芳自赏的艺术品。这也是B.S.的观点：“很多优秀的软件甚至都是由不那么优美的语言写成的”。同样适用于计算机和自然语言。
ginger2 2002-11-10
- 打赏
- 举报
mark !
ToUpdate 2002-11-10
- 打赏
- 举报
UP!
middle 2002-11-09
- 打赏
- 举报
构建任何软件框架的目的都是重用源代码，以避免重复别人做过的工作。这一初衷总是好的，但是得到的结果却有天壤之别。原因何在呢？
我认为这取决于构建者的目标定的有多高。当人们试图为某种工作创建一个单一的、可重用的软件框架时，这种工作越是高度的模式化，软件框架的构建也就越容易成功。那些野心比较小的、相对保守的构建者更容易获得成功，因为他们将自己的精力集中在范围较窄领域里。
例如，微软公司的MFC小组队的最初目标是构建一种独立于操作系统的、可以用于开发大多数应用软件的框架。这导致了最初版本的MFC过于复杂，甚至用处不大。因此，他们降低了目标，使自己的开发工作针对文档-视图结构的应用程序，并且使之仅仅能够运行在Win32平台上，这就是我们今天看到的MFC，一个成功的框架，但是即便如此，很多用MFC开发应用的程序员还是必须在工作中绕过(与普通类库的使用不同，使用框架的开发者不能简单的放弃一个功能，他们必须付出努力绕过去)MFC提供的一些用不到的功能。这说明了即使能够在开发框架的时候采取一种保守务实的观点，你仍然无法保证你对可重用性所作的每一份努力都能够真正的让用户获益。
另一方面，框架的架建设，或者更一般的说，源代码重用这种目标有时是仅仅依赖同一层次的工具无法达成的。当希望达成具有革命性的目标的时候更是如此。这非常象在数学领域的事情。当你想要证明一个关于整数的定理论时，你必须使用关于实数的理论。在计算机工程方面，获得某种水平的reusiblity，在其下一层构建有用的工具有时是必不可少的。
例如，关系数据库和对象的映射工作在有些人看来是高度模式化的（几乎任何一个刚参加工作的人都干过这种工作）。但是即便是这样的工作，在象Java这样的具有强大的RTTI和动态类装载器等特性的全动态语言诞生之前，要为其构建一个可重用的构架也是几乎不可能的。如果Sun公司没有做这些工作工作：定义一种语言，定义相应平台，实现运行环境， 实现编译器，那么这些工作将是软件框架的构建者无法回避的。 顺便说一下，即使在Java平台早已被实现的今天，J2EE的CMP也远非完美。
另一个例子，希望为算法构建可重用框架的设想也不可能在某些新的理论和语言特性——例如iterator和C++模板——发明之前变成现实。STL发明之前，那些认为自己能够构建这样的框架的人或者失败、或者构建出丑陋的框架。另一方面，即使今天，在最新C++标准出版四年之后，仍然没有编译程序能完全实现全部模板特征。这说明了两个问题：
1.人们常常低估准备基础理论和工具的必要性。
2.人们经常低估准备基础理论和工具的难度。
根据上述例子，可以得出一个非常重要的大多数软件开发管理人员不喜欢的事实。有时候，需要不同组织在各自独立的研究领域奋斗多年，其成果才有可能促成某种革命性的软件框架的诞生。很多具有革命性的事物（不限于计算机业）的出现正是符合这一论断的。对于这种工作，一个组织，尤其是那些面对市场压力的组织，没有能力准备所需的各方面的基础工具，例如数学理论、语言特型、硬件功能，等等。只有那些相对保守的软件框架才有可能被一个组织在可行的期限内完成。
那么，如果真的被要求构建一个软件框架的时候，我们需要注意一些什么呢？用一句话总结，就是：我们必须将最初设想的目标严格而谨慎的降低。最初的设想往往模糊而不切实际。我们必须让它更加具体、更加便于操作。而且，我们必须承认，人们在预测方面的能力不象很多人想的那么高，所以我们无法事先说清楚我们“正好”能够做哪些工作。这就造成了两种可能：第一，我们高估了自己，因此一事无成；或者，我们低估了自己，只发挥出部分的能力，但是在这种情况下，我们的工作没有白费，工作成果仍然有机会逐渐演化到我们真正能力的极限。
还是举个例子，在C++之前，很多面向对象语言的设计者高估了自己。导致的结果是为业界留下这样的印象，OO编程是无用的玩具。与此相反，C++的设计者是保守的。他的最初目标不过是为C引入Simula的代码组织机制。经过长时间的演化，C++最终成为了一种mult-paradigm的语言。如果它的设计者当初更加雄心勃勃一点，他就可能无法发现其他程序员真正需要的并且同时他自己真正能够实现的语言。
我认为这取决于构建者的目标定的有多高。当人们试图为某种工作创建一个单一的、可重用的软件框架时，这种工作越是高度的模式化，软件框架的构建也就越容易成功。那些野心比较小的、相对保守的构建者更容易获得成功，因为他们将自己的精力集中在范围较窄领域里。
例如，微软公司的MFC小组队的最初目标是构建一种独立于操作系统的、可以用于开发大多数应用软件的框架。这导致了最初版本的MFC过于复杂，甚至用处不大。因此，他们降低了目标，使自己的开发工作针对文档-视图结构的应用程序，并且使之仅仅能够运行在Win32平台上，这就是我们今天看到的MFC，一个成功的框架，但是即便如此，很多用MFC开发应用的程序员还是必须在工作中绕过(与普通类库的使用不同，使用框架的开发者不能简单的放弃一个功能，他们必须付出努力绕过去)MFC提供的一些用不到的功能。这说明了即使能够在开发框架的时候采取一种保守务实的观点，你仍然无法保证你对可重用性所作的每一份努力都能够真正的让用户获益。
另一方面，框架的架建设，或者更一般的说，源代码重用这种目标有时是仅仅依赖同一层次的工具无法达成的。当希望达成具有革命性的目标的时候更是如此。这非常象在数学领域的事情。当你想要证明一个关于整数的定理论时，你必须使用关于实数的理论。在计算机工程方面，获得某种水平的reusiblity，在其下一层构建有用的工具有时是必不可少的。
例如，关系数据库和对象的映射工作在有些人看来是高度模式化的（几乎任何一个刚参加工作的人都干过这种工作）。但是即便是这样的工作，在象Java这样的具有强大的RTTI和动态类装载器等特性的全动态语言诞生之前，要为其构建一个可重用的构架也是几乎不可能的。如果Sun公司没有做这些工作工作：定义一种语言，定义相应平台，实现运行环境， 实现编译器，那么这些工作将是软件框架的构建者无法回避的。 顺便说一下，即使在Java平台早已被实现的今天，J2EE的CMP也远非完美。
另一个例子，希望为算法构建可重用框架的设想也不可能在某些新的理论和语言特性——例如iterator和C++模板——发明之前变成现实。STL发明之前，那些认为自己能够构建这样的框架的人或者失败、或者构建出丑陋的框架。另一方面，即使今天，在最新C++标准出版四年之后，仍然没有编译程序能完全实现全部模板特征。这说明了两个问题：
1.人们常常低估准备基础理论和工具的必要性。
2.人们经常低估准备基础理论和工具的难度。
根据上述例子，可以得出一个非常重要的大多数软件开发管理人员不喜欢的事实。有时候，需要不同组织在各自独立的研究领域奋斗多年，其成果才有可能促成某种革命性的软件框架的诞生。很多具有革命性的事物（不限于计算机业）的出现正是符合这一论断的。对于这种工作，一个组织，尤其是那些面对市场压力的组织，没有能力准备所需的各方面的基础工具，例如数学理论、语言特型、硬件功能，等等。只有那些相对保守的软件框架才有可能被一个组织在可行的期限内完成。
那么，如果真的被要求构建一个软件框架的时候，我们需要注意一些什么呢？用一句话总结，就是：我们必须将最初设想的目标严格而谨慎的降低。最初的设想往往模糊而不切实际。我们必须让它更加具体、更加便于操作。而且，我们必须承认，人们在预测方面的能力不象很多人想的那么高，所以我们无法事先说清楚我们“正好”能够做哪些工作。这就造成了两种可能：第一，我们高估了自己，因此一事无成；或者，我们低估了自己，只发挥出部分的能力，但是在这种情况下，我们的工作没有白费，工作成果仍然有机会逐渐演化到我们真正能力的极限。
还是举个例子，在C++之前，很多面向对象语言的设计者高估了自己。导致的结果是为业界留下这样的印象，OO编程是无用的玩具。与此相反，C++的设计者是保守的。他的最初目标不过是为C引入Simula的代码组织机制。经过长时间的演化，C++最终成为了一种mult-paradigm的语言。如果它的设计者当初更加雄心勃勃一点，他就可能无法发现其他程序员真正需要的并且同时他自己真正能够实现的语言。
gmwang 2002-11-09
- 打赏
- 举报
不错
Ace17 2002-11-08
- 打赏
- 举报
昏///。。。。
unrealimage 2002-11-08
- 打赏
- 举报
哥们不要e问手不料
Laney 2002-11-08
- 打赏
- 举报
学习中
unrealimage 2002-11-08
- 打赏
- 举报
我们全部知道任何软件框架的目的将新使用源码，避免重新发明这个车轮。 原先的意图在建设一种结构总好，但是结果戏剧性不同。 为什么？ 我认为这取决于constructer 的雄心。 更多格式化是适合他们努力建造单个可回收结构哪个的那些工作，更可能结构那儿成功将。 谁是相对保守的那些constructer，即，谁使他们的努力聚焦在上一相对狭窄领土将非常可能取得他们物体。 例如，微软公司的MFC 队的orignial 目标将建造OS 宽的范围的独立的应用的一种框架。 因此第一个版本太复杂和有一些没用。 然后，他们缩小目标提供给applicaiton 把站台系给Win32，并且结构成为我们今天看见，这成功的这一个的资料意见的一结构。 即使，很多MFC 开发者必须到处走动( 与tooltip 不同注意到，使用框架的开发者不能完全不使用一个特征， 他们必须确实到处走动) 在他们的developement 里MFC 提供的一些没用的功能。 在reusibility 上向每你努力的保证困难的保守假定的这几次演出能真的benifit 你用户。 另一方面，框架建设，或者更一般， 源码reusibility 一目标有时不可能取得只以工具在相同水平上，在物体的paticular 倾向于盖住宽范围的应用的。 这非常象在数学领域的事情一样。 当你想要证明关于整数的一个理论时，你必须使用证明的实数的理论。 在计算机工程方面，获得某种水平的reusiblity，从这基础的水平中建造正确的工具有时是neccessary。 例如， 对获得数据库的reusiblity 目标映象不可能你只经营现有程序语言在支持富有的运行时间类型信息和动态的种类loader 的一动态程序语言完全之前如果， 象爪哇那样，被发明。 因此太阳没做那些工作，确定一种语言，确定相应平台，实现运行时间enviornment， 实现编译程序将是constructer 的必要工作。 顺便说一下，即使， J2EE 的CMP 不完美。 另一个例子，获得那些resuibily 的算法的不可能你只经营现有程序语言在之前发展观念和语言特点发展观念和语言特点发展观念和语言特点发明， 例如iterator 和C++ 模板。 STL 发明，那些想法算法他们可能在失败或者导致结构丑陋的一单个结构内实现才格式化的很多。 另一方面，即使今天，在4 年最新C++ 标准出版之后，没有编译程序能完全实现模板特征。 这显示两个点： 1.人们常常低估工作的必要建造fundemental 原则和工具。 2.人们经常低估工作的困难建造fundemental 原则和工具。 根据上述例子，我们能找到另一个软件队中的管理的材料不喜欢的非常重要的事实。 在革新喜欢的时候，一种框架经常基于足够的基本的努力，为很多年独立不相关组织经常献出这样的基本的努力。 更多的物体是innovativet，更可能情况是如此。 一个组织，尤其那个有市场压力，不能提供不同的方面的全部基本的工具，例如数学理论，语言特点， 硬件特征，等等。 只目的是相对保守的人的reusiblity 的那些工程可能在一个pratical 时间框架被一个单个的组织完成。
unrealimage 2002-11-08
- 打赏
- 举报
翻译翻译如下
参考用
翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用
参考用
翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用翻译翻译如下
参考用
unrealimage 2002-11-08
- 打赏
- 举报
我们全部知道任何软件框架的目的将新使用源码，避免重新发明这个车轮。 原先的意图在建设一种结构总好，但是结果戏剧性不同。 为什么？
我认为这取决于constructer 的雄心。 更多格式化那些工作适合他们努力建造单个可回收结构哪个，更可能结构那儿成功将。 谁是相对保守的那些constructer，即，谁使他们的努力聚焦在上一相对狭窄领土将非常可能取得他们物体
我认为这取决于constructer 的雄心。 更多格式化那些工作适合他们努力建造单个可回收结构哪个，更可能结构那儿成功将。 谁是相对保守的那些constructer，即，谁使他们的努力聚焦在上一相对狭窄领土将非常可能取得他们物体
加载更多回复（21）
