随笔-14  评论-25  文章-1  trackbacks-0
 
18世纪的贝叶斯定理成为Google计算的新力量--zt from http://www.code365.com/web/122/Article/17927.Asp

from http://www.code365.com/web/122/Article/17927.Asp


Thomas Bayes，一位伟大的数学大师，他的理论照亮了今天的计算领域，和他的同事们不同：他认为上帝的存在可以通过方程式证明，他最重要的作品被别人发行，而他已经去世241年了。

18世纪牧师们关于概率的理论成为应用发展的数学基础的一部分。

搜索巨人Google和Autonomy，一家出售信息恢复工具的公司，都使用了贝叶斯定理（Bayesian principles）为数据搜索提供近似的（但是技术上不确切）结果。研究人员还使用贝叶斯模型来判断症状和疾病之间的相互关系，创建个人机器人，开发 能够根据数据和经验来决定行动的人工智能设备。

虽然听起来很深奥，而这个原理的意思--大致说起来--却很简单：某件事情发生的概率大致可以由它过去发生的频率近似地估计出来。研究人员把这个原理应用在每件事上，从基因研究到过滤电子邮件。

在明尼苏达州大学的网站上能够找到一份详细的数学概要。而在Gametheory.net上的一个Bayes Rule Applet程序让你能够回答诸如“如果你测试某种疾病，有多大风险”之类的问题。

贝叶斯理论的一个出名的倡导者就是微软。该公司把概率用于它的Notification Platform。该技术将会被内置到微软未来的软件中，而且让计算机和蜂窝电话能够自动地过滤信息，不需要用户帮助，自动计划会议并且和其他人联系。

如果成功的话，该技术将会导致“context server”--一种电子管家的出现，它能够解释人的日常生活习惯并在不断变换的环境中组织他们的生活。

“Bayes的研究被用于决定我应该怎样最好地分配计算和带宽，” Eric Horvitz表示，他是微软研究部门Adaptive Systems & Interaction Group的高级研究员和分组管理者。“我个人相信在这个不确定的世界里，你不能够知道每件事，而概率论是任何智能的基础。”

到今年年底，Intel也将发布它自己的基于贝叶斯理论的工具包。一个关于照相机的实验警告医生说病人可能很快遭受痛苦。在本周晚些时候在该公司的Developer Forum（开发者论坛）上将讨论这种发展。

虽然它在今天很流行，Bayes的理论并不是一直被广泛接受的：就在10年前，Bayes研究人员还在他们的专业上踌躇不前。但是其后，改进的数学模型，更快的计算机和实验的有效结果增加了这种学派新的可信程度。

“问题之一是它被过度宣传了，” Intel微处理器实验室的应用软件和技术管理经理Omid Moghadam表示。“事实上，能够处理任何事情的能力并不存在。真正的执行在过去的10年里就发生了。”

Bayes哑元
Bayes的理论可以粗略地被简述成一条原则：为了预见未来，必须要看看过去。Bayes的理论表示未来某件事情发生的概率可以通过计算它过去发生的频率来估计。一个弹起的硬币正面朝上的概率是多少？实验数据表明这个值是50%。

“Bayes表示从本质上说，每件事都有不确定性，你有不同的概率类型，”斯坦佛的管理科学和工程系（Department of Management Science and Engineering at Stanford）的教授Ron Howard表示。

例如，假设不是硬币，一名研究人员把塑料图钉往上抛，想要看看它钉头朝上落地的概率有多大，或者有多少可能性是侧面着地，而钉子是指向什么方向的。形状，成型过程中的误差，重量分布和其他的因素都会影响该结果。

Bayes技术的吸引力在于它的简单性。预测完全取决于收集到的数据--获得的数据越多，结果就越好。另一个优点在于Bayes模型能够自我纠正，也就是说数据变化了，结果也就跟着变化。

概率论的思想改变了人们和计算机互动的方式。“这种想法是计算机能够更象一个帮助者而不仅仅是一个终端设备，” Peter Norvig表示。他是Google的安全质量总监。他说“你在寻找的是一些指导，而不是一个标准答案。”

从这种转变中，研究获益非浅。几年前，所谓的Boolean搜索引擎的一般使用需要把搜索按照“if, and, or but”的语法进行提交，然后去寻找匹配的词。现在的搜索引擎采用了复杂的运算法则来搜索数据库，并找出可能的匹配。

如同图钉的那个例子显示的那样，复杂性和对于更多数据的需要可能很快增长。由于功能强大的计算机的出现，对于把好的猜测转变成近似的输出所必须的结果进行控制成为可能。

更重要的是，UCLA的Judea Pearl这样的研究人员研究出如何让Bayes模型能够更好地追踪不同的现象之间条件关系的方法，这样能够极大地减少计算量。

例如，对于人口进行大规模的关于肺癌成因的调查可能会发现它是一种不太广泛的疾病，但是如果局限在吸烟者范围内进行调查就可能会发现一些关联性。对于肺癌患者进行检查能够帮助调查清楚习惯和这种疾病之间的关系。

“每一个单独的属性或者征兆都可能取决于很多不同的事情，但是直接决定它的却是为数不多的事情，”斯坦佛计算机科学系（computer science department at Stanford）的助理教授Daphne Koller表示。“在过去的15年左右的时间里，人们在工具方面进行了改革，这让你能够描绘出大量人群的情况。”

和其他一些项目一样，Koller是使用概率论技术来更好地把病症和疾病联系起来，并把遗传基因和特定的细胞现象联系起来。

记录演讲
一项相关的技术，名为Hidden Markov模型，让概率能够预测次序。例如，一个演讲识别应用知道经常在“q”之后的字母是“u”。除了这些，该软件还能够计算“Qagga”（一种灭绝了的斑马的名称）一词出现的概率。

概率技术已经内置在微软的产品中了。Outlook Mobile Manage是一个能够决定什么时候往移动设备上发出一封内勤的电子邮的软件。它是从Priorities发展而来的，Priorities是微软在 1998年公布的一个实验系统。Windows XP的故障检修引擎也依赖于概率计算。

随着该公司的Notification Platform开始内置在产品中，在未来的一年中会有更多的应用软件发布，微软的Horvitz这样表示。

Notification Platform的一个重要组成部分名为Coordinate，它从个人日历，键盘，传感器照相机以及其他来源收集数据，来了解某个人生活和习惯。收集的 数据可能包括到达的时间，工作时间和午餐的时间长度，哪种类型的电话或电子邮件被保存，而哪些信息被删除，在某天的特定时间里键盘被使用的频率，等等。

这些数据可以被用来管理信息流和使用者收到的其他信息。例如，如果一位经理在下午2：40发送了一封电子邮件给一名员工， Coordinate可以检查该员工的日历程序，然后发现他在下午2：00有一个会议。该程序还可以扫描关于该员工习惯的数据，然后发现该员工通常会在有 会议之后大约一个小时才重新使用键盘。该程序可能还能够发现该名员工通常会在5分钟之内回复该经理的电子邮件。根据上面这些数据，该软件能够估计出该员工 可能至少在20分钟之内不可能回复该电子邮件，该软件可能会把这条信息发送到该员工的手提电话上。同时，该软件可能会决定不把别人的电子邮件也转发出去。

“我们正在平衡以打搅你为代价所获得信息的价值，” Horvitz表示。使用这个软件，他坚持道，“能够让更多的人跟上事情的发展，而不被大量的信息所淹没。”

Horvitz补充道，隐私和对于这些功能的用户控制是确定的。呼叫者并不知道为什么一条信息可能会被优先或推迟处理。

微软还把Bayes模型使用在其他的一些产品上，包括DeepListener 以及Quartet （语音激活），SmartOOF 以及TimeWave （联系控制）。消费者多媒体软件也获益非浅，Horvitz表示。

Bayes技术不仅仅被应用在PC领域。在University of Rochester，研究人员发现一个人的步伐可以在一步前发生改变。虽然这种改变对于人类来说太过于细微，一台和电脑连接在一起的照相机可以捕捉并跟踪 这种动作。如果行走异常出现，计算机就能够发出警报。

一个实验用的安全照相机采用了同样的原理：大部分到达机场的人都会在停车以后直接走向目的地，所以如果有人停了车，然后走向另一辆车就不太正常，因此就可能引发警报。今年秋天一个创建Bayes模型和技术信息的基本引擎将会公布在Intel的开发者网站上。

理论冲突
虽然该技术听起来简单易懂，关于它的计算可能却比较慢。Horvitz回忆说他是斯坦佛20世纪80年代仅有的两个概率和人工智能的毕业生之一。其他所有的人学习的是逻辑系统，采用的是“if and then”的模式和世界互动。

“概率论那时候不流行，” Horvitz表示。但是当逻辑系统不能够预测所有的意外情况时，潮流发生了转变。

很多研究人员开始承认人类的决策过程比原来想象的要神秘的多。“在人工智能领域存在着文化偏见，” Koller表示。“人们现在承认他们并不知道他们的脑子是如何工作的。”

即便在他的时代，Bayes发现他自己置身于主流之外。他于1702年出生于伦敦，后来他成为了一名Presbyterian minister。虽然他看到了自己的两篇论文被发表了，他的理论很有效，但是《Essay Toward Solving a Problem in the Doctrine of Chances》却一直到他死后的第三年，也就是1764年才被发表。

他的王室成员身份一直是个谜，直到最近几年，新发现的一些信件表明他私下和英格兰其他一些思想家看法一致。

“就我所知，他从来没有写下贝叶斯定理，” Howard表示。

神学家Richard Price和法国的数学家Pierre Simon LaPlace成为了早期的支持者。该理论和后来George Boole，布尔数学之父，的理论背道而驰。George Boole的理论是基于代数逻辑的，并最终导致了二进制系统的诞生。也是皇室成员之一的Boole死于1864年。

虽然概率的重要性不容置疑，可是关于它的应用的争论却没有停止过。批评者周期性地声称Bayes模型依赖于主观的数据，而让人类去判断答案是否正确。而概率论模型没有完全解决在人类思维过程中存在的细微差别的问题。

“儿童如何学习现在还不是很清楚，”IBM研究部门的科学和软件副总裁 Alfred Spector这样表示。他计划把统计学方法和逻辑系统在他的Combination Hypothesis之中结合起来。“我最初相信是统计学的范畴，但是从某方面说，你将会发现不仅仅是统计学的问题。”

但是，很有可能概率论是基础。

“这是个基础，” Horvitz表示。“它被忽略了一段时间，但是它是推理的基础。”

posted @ 2006-05-30 12:51 混沌中立 阅读(417) | 评论 (0) | 编辑 收藏
面向对象设计的基本原则(转)
最近在看< 敏捷软件开发：原则、模式与实践 >在网上找了一些资料,就把他们集合到了一起,便于自己学习

此篇内容来自一下两处

http://blog.joycode.com/microhelper/archive/2004/11/30/40013.aspx

http://www.blogjava.net/ghawk/

另:关于面向对象设计的原则比较权威的是Uncle Bob-- Robert C. Martin的

Principles Of Object Oriented Design

http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign


单一职责原则——SRP
就一个类而言，应该仅有一个引起它的变化的原因
 
原则

最简单，最单纯的事情最容易控制，最有效
类的职责简单而且集中，避免相同的职责分散到不同的类之中，避免一个类承担过多的职责
减少类之间的耦合
当需求变化时，只修改一个地方

组件

每个组件集中做好一件事情
组件的颗粒度
发布的成本
可重用的成本
 
方法

避免写臃肿的方法
Extract Method
 
重构

Move Field/Move Class
Extract Method/Extract Class
 
最简单的，也是最难以掌握的原则
 
实例分析


单一职责很容易理解，也很容易实现。所谓单一职责，就是一个设计元素只做一件事。什么是“只做一件事”？简单说就是少管闲事。现实中就是如此，如果要你专心做一件事情，任何人都有信心可以做得很出色。但如果，你整天被乱七八糟的事所累，还有心思和精力把每件事都作好么？
fig-1.JPG
      “单一职责”就是要在设计中为每种职责设计一个类，彼此保持正交，互不干涉。这个雕塑（二重奏）就是正交的一个例子，钢琴家和小提琴家各自演奏自己的乐 谱，而结果就是一个和谐的交响乐。当然，真实世界中，演奏小提琴和弹钢琴的必须是两个人，但是在软件中，我们往往会把两者甚至更多搅和到一起，很多时候只 是为了方便或是最初设计的时候没有想到。 

      这样的例子在设计中很常见，书中就给了一个很好的例子：调制解调器。这是一个调制 解调器最基本的功能。但是这个类事实上完成了两个职责：连接的建立和中断、数据的发送和接收。显然，这违反了SRP。这样做会有潜在的问题：当仅需要改变 数据连接方式时，必须修改Modem类，而修改Modem类的结果就是使得任何依赖Modem类的元素都需要重新编译，不管它是不是用到了数据连接功能。 解决的办法，书中也已经给出：重构Modem类，从中抽出两个接口，一个专门负责连接、另一个专门负责数据发送。依赖Modem类的元素也要做相应的细 化，根据职责的不同分别依赖不同的接口。最后由ModemImplementation类实现这两个接口。
fig-2.JPG       从这个例子中，我们不难发现，违反SRP通常是由于过于“真实”地设计了一个类所造成的。因此，解决办法是往更高一层进行抽象 化提取，将对某个具体类的依赖改变为对一组接口或抽象类的依赖。当然，这个抽象化的提取应该根据需要设计，而不是盲目提取。比如刚才这个Modem的例子 中，如果有必要，还可以把DataChannel抽象为DataSender和DataReceiver两个接口。


开放封闭原则——OCP
软件实体（类，模块，函数）应该是可以扩展的，但是不可修改的
 
原则
 
对扩展是开放的，当需求改变时我们可以对模块进行扩展，使其具有新的功能
对更改是封闭的，对模块扩展时，不需要改动原来的代码
面对抽象而不是面对细节，抽象比细节活的更长
僵化的设计——如果程序中一处改动产生连锁反应。

方法

条件case   if/else 语句
 
重构

Replace Type Code With Class
Replace Type Code With State/Strategy
Replace Conditional with polymorphism
 
实例

开闭原则很简单，一句话：“Closed for Modification; Open for Extension”——“对变更关闭；对扩展开放”。开闭原则其实没什么好讲的，我将其归结为一个高层次的设计总则。就这一点来讲，OCP的地位应该比SRP优先。

OCP的动机很简单：软件是变化的。不论是优质的设计还是低劣的设计都无法回避这一问题。OCP说明了软件设计应该尽可能地使架构稳定而又容易满足不同的需求。

为什么要OCP？答案也很简单——重用。

“重用”，并不是什么软件工程的专业词汇，它是工程界所共用的词汇。早在软件出现前，工程师们就在实践“重用”了。比如机械产品，通过零部 件的组装得到最终的能够使用的工具。由于机械部件的设计和制造过程是极其复杂的，所以互换性是一个重要的特性。一辆车可以用不同的发动机、不同的变速箱、 不同的轮胎……很多东西我们直接买来装上就可以了。这也是一个OCP的例子。（可能是由于我是搞机械出身的吧，所以就举些机械方面的例子^_^）。

如何在OO中引入OCP原则？把对实体的依赖改为对抽象的依赖就行了。下面的例子说明了这个过程：

05赛季的时候，一辆F1赛车有一台V10引擎。但是到了06赛季，国际汽联修改了规则，一辆F1赛车只能安装一台V8引擎。车队很快投入了新赛车 的研发，不幸的是，从工程师那里得到消息，旧车身的设计不能够装进新研发的引擎。我们不得不为新的引擎重新打造车身，于是一辆新的赛车诞生了。但是，麻烦 的事接踵而来，国际汽联频频修改规则，搞得设计师在“赛车”上改了又改，最终变得不成样子，只能把它废弃。

OCP-fig1.JPG

为了能够重用这辆昂贵的赛车，工程师们提出了解决方案：首先，在车身的设计上预留出安装引擎的位置和管线。然后，根据这些设计好的规范设计引擎（或是引擎的适配器）。于是，新的赛车设计方案就这样诞生了。

 OCP-fig2.JPG

显然，通过重构，这里应用的是一个典型的Bridge模式。这个实现的关键之处在于我们预先给引擎留出了位置！我们不必因为对引擎的规则的频频变更而制造相当多的车身，而是尽可能地沿用和改良现有的车身。
说到这里，想说一说OO设计的一个误区。
学 习OO语言的时候，为了能够说明“继承”（或者说“is-a”）这个概念，教科书上经常用实际生活中的例子来解释。比如汽车是车，电车是车，F1赛车是汽 车，所以车是汽车、电车、F1赛车的上层抽象。这个例子并没有错。问题是，这样的例子过于“形象”了！如果OO设计直接就可以将现实生活中的概念引用过 来，那也就不需要什么软件工程师了！OO设计的关键概念是抽象。如果没有抽象，那所有的软件工程师的努力都是徒劳的。因为如果没有抽象，我们只能去构造世 界中每一个对象。上面这个例子中，我们应该看到“引擎”这个抽象的存在，因为车队的工程师们为它预留了位置，为它制定了设计规范。
上面这个设计也 实现了后面要说的DIP（依赖倒置原则）。但是请记住，OCP是OO设计原则中高层次的原则，其余的原则对OCP提供了不同程度的支持。为了实现OCP， 我们会自觉或者不自觉地用到其它原则或是诸如Bridge、Decorator等设计模式。然而，对于一个应用系统而言，实现OCP并不是设计目的，我们 所希望的只是一个稳定的架构。所以对OCP的追求也应该适可而止，不要陷入过渡设计。正如Martin本人所说：“No significant program can be 100% closed.”“Closure not complete but strategic”

Liskov替换原则—— LSP 

子类型必须能够替换它的基类型

原则

主要针对继承的设计原则
所有派生类的行为功能必须和客户程序对其基类所期望的保持一致。
派生类必须满足基类和客户程序的约定
IS-A是关于行为方式的，依赖客户程序的调用方式
 
重构

Extract Supper Class
 
实例

长方形和正方形

OCP作为OO的高层原则，主张使用“抽象(Abstraction)”和“多态(Polymorphism)”将设计中的静态结构改为动态结构，维持设计的封闭性。

“抽象”是语言提供的功能。“多态”由继承语义实现。

如此，问题产生了：“我们如何去度量继承关系的质量？”

Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”也就是说，当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有 is-A关系。

该原则称为Liskov Substitution Principle——里氏替换原则。林先生在上课时风趣地称之为“老鼠的儿子会打洞”。^_^

我们来研究一下LSP的实质。学习OO的时候，我们知道，一个对象是一组状态和一系列行为的组合体。状态是对象的内在特性，行为是对象的外在特性。LSP所表述的就是在同一个继承体系中的对象应该有共同的行为特征。

这一点上，表明了OO的继承与日常生活中的继承的本质区别。举一个例子：生物学的分类体系中把企鹅归属为鸟类。我们模仿这个体系，设计出这样的类和关系。

 lsp-fig1.jpg

类“鸟”中有个方法fly，企鹅自然也继承了这个方法，可是企鹅不能飞阿，于是，我们在企鹅的类中覆盖了fly方法，告诉方法的调用者：企 鹅是不会飞的。这完全符合常理。但是，这违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！需要注意的是，此处的“鸟”已经不再是生物学中的鸟了，它是软 件中的一个类、一个抽象。

有人会说，企鹅不能飞很正常啊，而且这样编写代码也能正常编译，只要在使用这个类的客户代码中加一句判断就行了。但是，这就是问题所 在！首先，客户代码和“企鹅”的代码很有可能不是同时设计的，在当今软件外包一层又一层的开发模式下，你甚至根本不知道两个模块的原产地是哪里，也就谈不 上去修改客户代码了。客户程序很可能是遗留系统的一部分，很可能已经不再维护，如果因为设计出这么一个“企鹅”而导致必须修改客户代码，谁应该承担这部分 责任呢？（大概是上帝吧，谁叫他让“企鹅”不能飞的。^_^）“修改客户代码”直接违反了OCP，这就是OCP的重要性。违反LSP将使既有的设计不能封 闭！

修正后的设计如下：

 lsp-fig2.jpg

但是，这就是LSP的全部了么？书中给了一个经典的例子，这又是一个不符合常理的例子：正方形不是一个长方形。这个悖论的详细内容能在网上找到，我就不多废话了。

LSP并没有提供解决这个问题的方案，而只是提出了这么一个问题。

于是，工程师们开始关注如何确保对象的行为。1988年，B. Meyer提出了Design by Contract（契约式设计）理论。DbC从形式化方法中借鉴了一套确保对象行为和自身状态的方法，其基本概念很简单：

  1. 每个方法调用之前，该方法应该校验传入参数的正确性，只有正确才能执行该方法，否则认为调用方违反契约，不予执行。这称为前置条件(Pre-condition)。
  2. 一旦通过前置条件的校验，方法必须执行，并且必须确保执行结果符合契约，这称之为后置条件(Post-condition)。
  3. 对象本身有一套对自身状态进行校验的检查条件，以确保该对象的本质不发生改变，这称之为不变式(Invariant)。

以上是单个对象的约束条件。为了满足LSP，当存在继承关系时，子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或者更宽松；而子类中方法的后置条件必须与超类中被覆盖的方法的后置条件相同或者更为严格。

一些OO语言中的特性能够说明这一问题：

  • 继承并且覆盖超类方法的时候，子类中的方法的可见性必须等于或者大于超类中的方法的可见性，子类中的方法所抛出的受检异常只能是超类中对应方法所抛出的受检异常的子类。
    public class SuperClass{
            public void methodA() throws IOException{}
    }

    public class SubClassA extends SuperClass{
            //this overriding is illegal.
        private void methodA() throws Exception{}
    }

    public class SubClassB extends SuperClass{
            //this overriding is OK.
        public void methodA() throws FileNotFoundException{}
    }

  • 从Java5开始，子类中的方法的返回值也可以是对应的超类方法的返回值的子类。这叫做“协变”(Covariant)
    public class SuperClass {
            public Number caculate(){
                return null;
        }
    }

    public class SubClass extends SuperClass{
            //only compiles in Java 5 or later.
        public Integer caculate(){
                return null;
        }
    }

可以看出，以上这些特性都非常好地遵循了LSP。但是DbC呢？很遗憾，主流的面向对象语言（不论是动态语言还是静态语言）还没有加入对DbC的支持。但是随着AOP概念的产生，相信不久DbC也将成为OO语言的一个重要特性之一。


依赖倒置原则—— DIP 

a：高层模块不应依赖于底层模块，两者都应该依赖于抽象
b：抽象不应该依赖于细节，细节应该依赖于抽象

 
原则

如何解释倒置
高层依赖底层，重用变得困难，而最经常重用的就是framework和各个独立的功能组件
高层依赖底层，底层的改动直接反馈到高层，形成依赖的传递
面向接口的编程
 

实例

Ioc模式
DomainObject / DomianObjectDataService
 

接口隔离原则—— ISP 

使用多个专门的接口比使用单一的总接口总要好。换而言之，从一个客户类的角度来讲：一个类对另外一个类的依赖性应当是建立在最小接口上的。

原则

过于臃肿的接口是对接口的污染。不应该强迫客户依赖于它们不用的方法。

My object-oriented umbrella（摘自Design Patterns Explained）

Let me tell you about my great umbrella. It is large enough to get into! In fact, three or four other people can get in it with me. While we are in it, staying out of the rain, I can move it from one place to another. It has a stereo system to keep me entertained while I stay dry. Amazingly enough, it can also condition the air to make it warmer or colder. It is one cool umbrella.

My umbrella is convenient. It sits there waiting for me. It has wheels on it so that I do not have to carry it around. I don't even have to push it because it can propel itself. Sometimes, I will open the top of my umbrella to let in the sun. (Why I am using my umbrella when it is sunny outside is beyond me!)

In Seattle, there are hundreds of thousands of these umbrellas in all kinds of colors. Most people call them cars.

实现方法：
1、 使用委托分离接口
2、 使用多重继承分离接口

想到一个朋友说的话：所有的接口都只有一个方法，具体的类根据自己需要什么方法去实现接口

posted @ 2006-04-09 14:06 混沌中立 阅读(560) | 评论 (0) | 编辑 收藏
关于团队的一些想法
工作了几年,在不同的公司进入了几个不同的团队.感觉团队之间的差异很大.

1.一个好的团队,是需要时间来培养的.团队中的成员需要时间来互相熟悉,这个熟悉不单是平常说的认识,还要包括熟悉其他的编程方式设计倾向,工作习惯.只有这样以后,在讨论问题讨论方案的时候,可以形成默契,基本简单几句就会明白在说什么问题.团队也需要时间来形成团队的风格,一个有团队所有成员的风格组合在一起形成的风格.包括文档,编码,设计,沟通等方面上的一致风格.中间需要不断进行review,按照review的结果,对所有成果物进行修改.

2.一个好的团队的人员流动应该是良性的.这个良性流动指的是有人员的变化,但是变化的数量和范围不会使得团队的风格发生大的变化,如果一个10人的团队,突然发生的5人的变化,就是说调整到其他团队5个人,又调整进来5个人,那对于这个团队基本可以算是重新形成一个新的团队了.

3.一个好的团队,不单需要团队内部成员的努力,同时也需要SPEG和QA在团队之外对团队的开发流程的监督和规范.如果没有了解开发流程和开发规范的SPEG对流程进行监督,即使团队形成了风格,那这个风格很有可能不是健康的风格,可能会导致团队在以后的开发的过程中产生问题.

4.一个好的团队,需要比较有控制力的PM,能力强的PSM,设计能力优秀的SA.正因为有这样的人,才能快速的将加入团队的新成员,融入团队.

好像具备了上面这些条件想不形成一个好的团队也是很不容易的事情了:)
posted @ 2006-04-08 20:01 混沌中立 阅读(1020) | 评论 (2) | 编辑 收藏
rich client的回归
最近一直在想这个事情，从近几年的web application的发展情况和工作项目的用户需求来看，rich client应该又要成为一个潮流了。

主要原因有两点：
一是网速的提高，过去使用browser是因为过去的网络速度比较慢，所以只能给客户端传送很少的信息量，让客户通过网络传输的信息尽可能少的完成操作。而现在网络速度的提高，让这样的要求变少了，网速慢的这个瓶颈也不再存在了。
二是用户的要求，用户实际上不在意什么client还是brower，用户在意的是使用是否方便，响应是否迅速,能否满足业务需要。如果网速慢,机器配置差的瓶颈在今天的技术条件下不存在了，用户对于易用性和快速响应的要求就要提高了。这个快速响应不是指那种客户端<----->服务器的响应，而已一个操作之后快速的出现结果，这个就要求有一部分在C/S模式下在客户端实现的功能但是在B/S情况下被转移到服务器上的一些功能需要在客户端实现。

但是这个rich client不是几年前的那种臃肿的不行的方式了，应该是比现在的应用的client包含的内容多，但是比以前的client的内容要少。主要解决的问题是，快速响应用户的操作，让用户的操作更简单。


（思路不是很清晰，暂时是这样，之后再修改）
posted @ 2006-03-17 10:12 混沌中立 阅读(249) | 评论 (0) | 编辑 收藏
仅列出标题
共2页: 上一页 1 2 
Powered by: 博客园 模板提供：沪江博客 Copyright ©2024 混沌中立