<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>臭皮匠 &#187; 设计模式</title>
	<atom:link href="http://guogoul.com/category/design_patterns/feed/" rel="self" type="application/rss+xml" />
	<link>http://guogoul.com</link>
	<description></description>
	<lastBuildDate>Fri, 29 Oct 2010 00:24:37 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>从精益生产到精益软件开发</title>
		<link>http://guogoul.com/2008/06/22/lean/</link>
		<comments>http://guogoul.com/2008/06/22/lean/#comments</comments>
		<pubDate>Sun, 22 Jun 2008 13:11:18 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[感悟]]></category>
		<category><![CDATA[设计模式]]></category>
		<category><![CDATA[Martin Fowler]]></category>
		<category><![CDATA[敏捷]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/06/22/lean/</guid>
		<description><![CDATA[第三界&#8221;敏捷中国&#8221;的会议主题是精益软件思维，听了Martin Fowler（重构的作者）和ThoughtWorks同事的精彩演讲，收获不少。在此分享一下学习心得。敏捷的最大好处是减少浪费，通过对质量的严格控制减少返工的浪费，通过频繁的反馈减少误解的浪费。这种与浪费做战的态度，与精益(Lean)思想同出一处。
1）何为&#8217;精益&#8217;:以上摘自: http://blog.vsharing.com/tiger_wing/A387321.html精益生产（Lean Production，简称LP）是美国麻省理工学院数位国际汽车计划组织（IMVP）的专家对日本“丰田JIT（Just InTime）生产方式”的赞誉之称，精，即少而精，不投入多余的生产要素，只是在适当的时间生产必要数量的市场急需产品（或下道工序急需的产品）；益，即所有经营活动都要有益有效，具有经济性。精益生产是当前工业界最佳的一种生产组织体系和方式。
2)怎么从传统工业中的精益生产到软件互联网行业的精益开发呢？软件行业是一个新兴的快速发展的行业，他与传统行业存在很多不同的思维方式，但是存在更多的共同点，很多在软件行业中的做法借鉴了传统行业，并且在软件行业中收效很大。比如软件设计的精典著作《设计模式》则借鉴了建筑领域的著作《建筑模式》.软件行业学习制造业的精益思想也是理所当然.(以下笔记摘自路宁的精采演讲)2.1 精益工厂的环境是干净，井井有条的工厂搞得像医院一个干净有条理,而不像一般的工厂一样到到处是油污，到处散落零件。目的是更加方便的找出质量的死角，无限放大工作流程中的失误。我们程序员的工作环境也是如此，工作环境不仅指一个公司的工作环境，还指一个程序员个体的编码环境。如果工作环境是无序的，零乱的，那么在这个环境里面的工作人员怎么不会被外界的环境所影响呢？程序员的编码环境也如此，如果每天发费大量的时间在你混乱的文件路径中查找你在中的工作材料,怎么会有时间集中精神把一件事件做到位呢？（哈哈！从现在开始把当天要进行开发的工作目录设置为根目录）2.2 最大程度的了解团队的信息。在精益工厂工人之间是易于沟通的，工人与上级之间也是无障碍的.所有工人的劲往一个地方使。我们的开发团队去掉你们工位挡板，与合作伙伴坐到一起，项目负责人可以试着走出你的办公室,坐到你的团队成员之间来.只有面对面交流，才能互相子解团队中的所有的成员技能特长，最终达到人尽其才,提高团队战斗力。2.3 准时化，零库存。在精益工厂中，库存就是浪费。库存不能为你的产品产生任何价值，而且还要浪费你的很多资源,是不可取的。怎样来估算一个软件项目的库存呢？如果你当前的项目提交时间点到了，你手头上还有多少还没有实现价值的代码。那么这些没有实现价值的代码就是库存，尽管这些库存的代码可能会对本项目的深度开发有用.由于这些库存不是程序实现的目标，那么你的这些库存就会是浪费。敏捷开发讲究早开发完成，早测试，早发现问题，早解决问题.对一个问题实现多次上面的迭代,以实现提到软件质量的目的。根据这个思想我们可以把用来做这些库存代码的时间拿来提高产品的质量上去,多做几次迭代。当然零库在项目开发中是不可能,但它是敏捷的一个重要目标。在软件产品设计的过程中的库存很多时候体现在过度设计或者分析瘫痪上面.不要为不存在的需求做过多的设计。有什么样的需求，就做相关开发。2.4.单件流通，任务细化，及时提交。每件产品必须按顺序的走完整个生产流程，这样才能保证每个产品的质量。也就是说一个产品出现问题必需先阻塞住当前的生产流水线，把问题解决再启动生产流水线继续正常工作。软件开发过程中，一个团队尽量避免同时做几个项目,多个项目并行开发，最终可能导致每个项目的质量都得不到保证。项目实施的过程中出现问题一定要立即解决,如果不趁早解决,问题出现的点可能就成为影响你整个产品质量的关键。2.5 工作流程一定是可视化。可视化的工作流程不仅容易发现工作中的问题，而且还可以容易控制工作的进度。相比传统行业，软件行业以智力为主.对于智力工作如何把工作流程可视化呢?可以用一些工具简单的记录团队成员每天的工作内容(写出关键工作点不可，不要成为负担)，或者与团队多开一些简短的standing metting.也可以进行结对开发。结对应该是频道的结合，一对搭档最好不要连续合作超过3天。这些方法只有一个目的，就是让团队的成员知道你在做什么。2.6 一个质量例子：（路宁讲的）大家都知道德国的汽车以质量好出名，在德国的汽车流水线后面会在大量的刚从下线的汽车，大量的质量检测工人拿着工具检查车的质量，这些工人的占人总人数的1/4。同样以质量出名的日本精益流水线，生产线的末端都是只有为数不多的车,一个质检人员也没有，他们相信质量问题已在线上的各个环节中给解决了,车生产出来之后就可以直接拿上路了。可见保证软件质量的并不在于我们有多大的测试团队，而是在于问题在什么时候解决。如果像精益生产线一样在第一时间解决的话，那么产品的质量将会保证的更好。如果到了最后才去发现问题，解决问题，很有可能只解决了问题的表面现象，没有改变问题的本质。反问一句有多人能说的清楚起1个月前的自己的错误是怎么产生呢？(强调:第一时间解决问题).
在这次大会中，还有很多关于精益，敏捷的精彩课程.他们的演讲让我受益匪浅.腾讯公司研发管理部总经理林松的演讲也十分的精彩。
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/06/22/lean/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>摘自_设计模式解析(2)</title>
		<link>http://guogoul.com/2008/05/13/pick-design-patterns-2/</link>
		<comments>http://guogoul.com/2008/05/13/pick-design-patterns-2/#comments</comments>
		<pubDate>Tue, 13 May 2008 15:25:08 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[技巧]]></category>
		<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/13/pick-design-patterns-2/</guid>
		<description><![CDATA[8.switch语句本身常常说明:
   (1).需要多态行为;
   (2)存在职责错放.应该考虑用一种更为通用的解决方案,比如抽象代替switch语句,或者将职责赋于其它对象.
9.使用设计模式常见的错误:
 (1)浮于表面:仅仅对低层情况有一些肤浅的理解，就草草选择一个模式。
 (2)偏见:对于模式过于偏信。根据已经选定的模式/模型来解释所有的数据，不愿意对自己的偏见有任何的怀疑。
 (3)错选: 不理解模式适用的背景和条件（对各模式的分类关系理解不全）,选择了错误的模式。
 (4)误判：不熟悉各种模式，因为无知导致误判。
 (5)削足适履：忽略了实际的，具体实例行为中的例外情况，因为它们似乎不符合模式中所表达的理论。很可能会使所建模出来的对象过于僵硬，不符合实际情况。
10.与客户打交道的经验:
 (1).他们通常非常了解他们的问题域（大多数我们永远都赶不上）
 (2).一般情况下，他们不会像开发人员经常的那样在概念层次上表达事情，相反，他们会谈得十分的具体。
 (3).他们经常用&#8221;总是&#8221;表示“通常”
 (4).他们经常用&#8221;从不&#8221;表示“很少”
 总之对于非常具体的问题，客户详细的回答一般是可信的，但是他们一般性的回答却不可信。
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/13/pick-design-patterns-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>摘自_设计模式解析(1)</title>
		<link>http://guogoul.com/2008/05/11/pick-design-patterns/</link>
		<comments>http://guogoul.com/2008/05/11/pick-design-patterns/#comments</comments>
		<pubDate>Sun, 11 May 2008 08:03:59 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/11/pick-design-patterns/</guid>
		<description><![CDATA[1. 正确分析和设计要求我们在互相矛盾的关注点中找到平衡,必须决定问题的哪些方面是设计的重点,或者应该让系统防范哪些变化.寻找平衡必须成为做出决策的第一要务.不要让细节转移了你的注意力.分析人员都可以犯的常见错误是:在开发过程中过早的深入细节,因为处理细节是比较容易.细节的解决方案总是显而易见的,但并非肯定是最好的入手点.细节问题的处理应尽可能推后.
2. Facade模式简化了接口,而adapter模式则将一个已有的接口转化成另一个接口.
3. 优先使用对象组合,而不是类继承.
4. 过度使用继承:(以下作者的感悟,我觉得很有道理)
   &#8220;在我还是一个初级的面向对象分析时,曾经很喜欢利用继承,使用特殊情况解决这里碰到的问题.我喜欢继承的思想,因为他们看起来新颖而且功能十分的强大.只要可以继承的地方都使用了继承.似乎对许多设计师来说这很正常,但是其实这是很幼稚的:有了新的&#8221;锤子&#8221;,所有的东西看上去都成了钉子.糟糕的是许多面向对象的设计方式关注点都放在了通过特化处理,从已有的类派生新类上.正是对这种对对象的&#8217;is-ness&#8217;性质的过度关注,程序员往往会在巨大臃肿的类层次关系中创建对象,这种层次开始时可能还能正常工作,但是随着时间的推移将变得越来越难以维护.而当我成为一个有经验的面向对象设计人员之后,仍然深陷于继承的设计方式之中,还是根据&#8217;is-ness&#8217;性质观察类的特点,无论结构变得多么的复杂.用设计模式进行思考最终救我于泥潭之中,自此学会了用对象的职责而不是其结构来思考问题.有经验的设计分析师都已经了解到应该有选择的使用继承.才能发挥其优势.使用设计模式,将有助于加快这一学习进程.其中就包括从&#8217;为每种变化使用不同的特化&#8217;(继承)到&#8217;将变化转移到使用或拥有这种变化的对象中&#8217;(组合)的转变&#8221;
5. 一条规则,实现一次:
  &#8216;有一条重要的实现策略应该遵循:规则只在一个地方实现.换言之,如果做什么事只有一条规则,只实现一次.这通常会使代码中出现许多小的方法,所增加的代价很小,却消除了重复,而且经常可以预防将来可以出现的许多问题。重复的害处不仅在于输入工作成倍增加，还因为将来有东西发生变化时，可能会忘记在所有需要地方进行修改.&#8217;
6.衡量设计质量的一种方法是:看它是否能很多好应对变化。
7。模式并不总能提供十全十美的解决方案,但是因为模式是众多设计人员多年的集体智慧结晶，所以它们通常优于你我自己有限时间所能提供的解决方案。
欢迎大家谈谈关于设计模式的一些想法
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/11/pick-design-patterns/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>为什么要学习设计模式</title>
		<link>http://guogoul.com/2008/05/08/why-design-patterns/</link>
		<comments>http://guogoul.com/2008/05/08/why-design-patterns/#comments</comments>
		<pubDate>Thu, 08 May 2008 15:19:44 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/08/why-design-patterns/</guid>
		<description><![CDATA[设计模式是程序员自身修炼的宝典,一直没有时间系统的学习.主要原因是没有认知其重要性.最近花了点时间看了设计模式解析,通俗易懂.个人觉得是一本好书,过一段时间再认真学习一篇.学习设计模式最好的时机是在有一年左右的编码经验以后.因为只有在有一定的编码经验才能感同身受,更易理解模式其更深层的道理.
    下面就来解答一下学习设计模式的理由:
     1.复用解决方案: 通过复用已经公认的设计,能够在解决问题时取得先发优势.避免重蹈覆辙.您是是否也有类似疑虑:几个项目下好像解决方案大体可以公用.但是就是没有总结.工作好像一直在重复
     2. 确定通用术语: 开发中的交流和协作都需要共同的词汇其础和对问题的共识.如果交流双方都学习过设计模式交流起来就会十分的舒服.不知道你有没有想表达又表达不清楚的设计思路,或者自己表达得明白但对方又误解了你的意思了呢?看了设计模式你也许可以找到你想要的答案
     3. 改善团队的沟通和个人学习.一个团队一起学习设计模式,有助于团队战斗力的提高.
     4. 代码更易于修改与维护. 因为设计模式都是久经考验的解决方案,它们的结构都是经过长期的发展形成的.善于应对变化.
     5.学习模式后,就算不用模式中的方法.也会更好的采取更好的策略去解决问题.
     难道你还不心动吗?
]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/08/why-design-patterns/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>singleton模式与double-checked Locking模式</title>
		<link>http://guogoul.com/2008/05/04/singleton/</link>
		<comments>http://guogoul.com/2008/05/04/singleton/#comments</comments>
		<pubDate>Sun, 04 May 2008 15:10:47 +0000</pubDate>
		<dc:creator>john</dc:creator>
				<category><![CDATA[设计模式]]></category>
		<category><![CDATA[singleton]]></category>

		<guid isPermaLink="false">http://www.guogoul.com/2008/05/04/singleton/</guid>
		<description><![CDATA[singleton是一个十分常用的模式,也十分简单.不过到现在才知道这种模式叫singleton模式.
现在把singleton模式做一下记录.
模式意图:
     保证一个类仅有一个实例,并提供一个访问它的全局访问点.
问题:
    几个不同的客户对象需要引用一个对象.而且希望确保这种类型的对象数目不超过1个
实现原理:
    1.添加一个类的私有的静态成员变量,引用所需的对象.
    2.添加一个公共的静态方法,它在成员变量的值为null时实例化这个类,然后返回成员变量的值.
    3.将构造函数的状态设置为保护或私有,从而防止任何人实例化这个类,绕过静态构造函数的机制
Singleton模式的C++片段
        class SingletonTest{
            private static Singleton s_instance;
          [...]]]></description>
		<wfw:commentRss>http://guogoul.com/2008/05/04/singleton/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
	</channel>
</rss>

