博客园_编写人生

我喜欢吃白米饭

2011-12-26T10:36:00Z

晚上一个人，就跑到街边的那种沙县小吃吃个快餐。

小店很小，只有六张桌子，我正闷头吃饭呢，突然听见一个人怒斥着什么，我抬头，只见一个长的蛮高的小伙子，大约1米8了，冬天的衣服过的厚厚的，更显得魁梧了。旁边站着一个妇女，估计是他的妈妈，我听不清他们说什么，隐约听见什么大排还是大肉，辣椒，还有加一份青菜什么的。

我又低头吃饭，一会儿他们的快餐上来了，因为他们坐下了，又坐在我的斜对角，所以听得清楚了一些。快餐只上了一份，小伙子在吃，他吃的狼吞虎咽，显然饿极了。妈妈坐在旁边，指指那个青菜，显然对额外添加的青菜不满意，在那里咕咕叨叨，小伙子没理睬他，只顾吃饭。

那点饭显然不够小伙子吃，我估计也就20秒吧，饭快没有了，小伙子到：老板加饭。老板立即盛饭去了，他的妈妈四周望了望，小心翼翼的问道：老板，你们这里米饭多少钱一碗。老板大声道：不要钱。她似乎不相信自己的耳朵，坐在旁边的民工又提醒道：加米饭不要钱。米饭上来了，老板很爽快，盛了满满一盘子，正准备倒在小伙子的盘子里呢，小伙子立马叫道：不用那么多，不用那么多。于是就只放了大半。

老板走后，妈妈又唠叨起来，但压低了声音，不要钱你干嘛不多加点。儿子还是没有理睬她，只顾着吃饭。她坐在儿子旁边，开始东张西望，过了一会儿，她又问老板：单独买米饭多少钱啊，老板说：两块。又过了好半会儿，她对老板说，那给我来分白米饭。当然，她没有忘记对坐在旁边的民工师傅说：我喜欢吃白米饭。

本文链接

IT沙龙共同成长计划

2011-12-25T08:50:00Z

继续上次说的IT沙龙，首先，我打算把名字由：助您成长改为共同成长。助您成长有那么一点点恩惠别人的意思，虽然的确是，但我相信讲师自己也会成长，听众成长之后，也反过来帮助大家，那就是共同成长了。

首先，是网站的建设，我挑选了一下，觉得Codeplex上的Orchard项目不错，他是一个C#编写的CMS开源项目。总体设计思想不错，项目也比较活跃。

网站的主菜单包括：

主页：显示最新的活动安排、博文列表、宣传性链接；

活动：罗列所有的活动列表；

博客：罗列所有的博文，这些博文是所有会员写的博文。

会员：罗列了所有会员，以及他们的信息，包括所有参加的活动，积分等。

财务：接受会员的捐款、捐物，在这里罗列，以及费用的情况。

关于：介绍主要的核心成员和讲师。

本文链接

快餐店的流程优化思考

2011-12-24T06:46:00Z

今天中午去一家饺子馆吃饺子,生意很好,是几个小年轻开的,可惜流程没有搞好,好几个人忙不过来,乱糟糟的,所以我就在想这种快餐店如何流程优化。

如果进入店后，进入自助点餐台，点餐台其实就是一个放了平板电脑的台子。

好处：减少了前台的空间，也没有了前台的服务人员。

平板的画面中使用视频告诉客户：请拿一个旁边的餐桌号牌。然后在平板旁边的扫描枪扫一下。

（如果用RFID或IC卡之类的，体验最好了）。

当然，因为我找不到合适的照片，实际的餐桌号牌应该包含大大的条码或者RFID之类的。

客户拿到后，在平板旁边扫描一下，这样我们就能够确定这个客户，后面的流程要靠这个确定客户。

现在，开始点餐了，当客户扫描了餐桌号牌后，屏幕切换到点餐界面，如果是已经点餐的，将显示已经点餐的数据。

点餐界面就自由发挥了，一般来说大大的图标或图片是最好的形式。

在明显的位置包含“下单”按钮，当点击下单后，画面出现提示：总计多少钱，如果又优惠券也可以扫描一下。

最关键：还需要有一个，您有多少零钱的提示。由于后续的服务员才能一次完成找零工作。

点击：完成，拿着餐桌号牌，找个餐桌等等吧。

好处：完全不需要前台服务员，减少付款时的时间。

厨房在接收到指定的订单后，就可以制作了。

厨师的现成的食物或做好食物后，服务员在后台的触摸屏上点击将要送出的食物（他的屏幕上是未出的食物），大概是这个样子的：

画面中，底背景色表示客户已经等待的时间。

那个抹去的标志表示已经完成。辣椒图标表示客户需要的特殊口味，服务员将点击可以送出的食物，最后点击”送出按钮“。

这时，如果有送出的食物是此餐台第一次送出，屏幕将提示准备的零钱。（就是通过客户之前输入的信息）。并且打印对应的小票。

服务员按顺序将食物送出到对应的餐桌，如果某餐桌首次送餐，将会要求客户付款并支付零钱给客户。递交小票并在已经送到的食物划勾。

如果此餐桌已经全部上菜完毕，还要做一个动作，将餐牌收回，并提示客户用完餐后将托盘和碗筷放到哪个位置。

餐桌号牌收回扫描给电脑，并存入客户的付款。

基本上，餐厅就只剩下打扫地面和餐桌的服务员了。

本文链接

宅男网上购买大家电对各大网站的总结

2011-12-24T02:44:00Z

家里要买一些家电，我又正好在家闲着，那这个光荣的任务当然是我来做，但我可不愿意到国美苏宁这样的商场去逛，我是技术指标狂，到那种地方服务员还没我懂，关键是还价了半天还没有网上的便宜，费那个力气干啥。

我需要购买的商品如下：

基于价格与指标的平衡，我目标是这些商品，他们都是非常节能，质量又不错的产品。（注：LG的洗衣机也可以选择WD-T12235D，是7公斤的，仅仅贵300多）。

下面是我购买这些商品时的体验。其他的淘宝商城、亚马逊、新蛋等，毕竟不是做大家电的，完全不在一个层次就不评价了。

www.360buy.com
体验	★★★★★	分类准确细致，参数详细可查询。易用性好，注重细节
价格	★★★★	价格相对线下还是很有优势，但是在库巴和苏宁面前，还是要贵个几百，但是优惠活动多。
货源	★★★	总体来说，货物种类非常多，也基本都有货，但真正畅销的往往脱销没货。
综合评价	★★★★	作为最老牌的网上电器购物，仍然是群龙之首，但价格没有苏宁给力了。

http://www.coo8.com/
体验	★★★★	这呀的太卑鄙，完全照抄京东的设计，但毕竟是仿制品，细节欠火候。
价格	★★★★★	价格简直太给力了，我上面的图就是在库巴的订单。如果说网上购物比线下可能便宜一千，那么库巴你仔细找，很可能比其他网站还要再便宜几百。他给力的价格促销好像非常短，在我欣喜的下订单后支付出了问题，第二天再次购买时已经两个商品涨价了。
货源	★★★★★	从网站的提示看，货源种类比较多的，货源也充足。很多抢手货他都提示有，但具体有没有没试过。
综合评价	★★★★★	价格太给力了，很多大城市市区还支持货到付款。国美2010年收购了他，应该不错。

http://www.suning.com/
体验	★★★	界面中等，但还是新手，比如将洗衣机先按照波轮和滚筒，这是一个低级错误。如果客户没钱只想买波轮，他就会直接进入波轮，然后看见有特价就买了，这很可能让他错失滚筒的另外一个特价。这样的问题还很多，包括没有专门的参数对比。
价格	★★★★	可能是不想做千年老二吧，这个网上的价格很给力，比库巴贵一点，但比其他的都便宜很多。
货源	★★★★	货源种类比较多的，货源还行吧，至少比京东的货源充足。
综合评价	★★★★	价格给力，又是苏宁的正太子，支持还行。

http://www.gome.com.cn/
体验	★★★	界面中等，但还是新手，没有专门的参数对比。出现几次JSP错误，直接把调用堆栈显示出来，圣诞节白天竟然“系统升级中”。
价格	★★	国美即想搞网上商城，又怕价格阻碍了线下，两边不讨好，所以价格高企。
货源	★★★★★	货源有比国美的多的吗。
综合评价	★★★	一般一般，实在不推荐，只能期望哪次突然搞大活动。

本文链接

助您成长计划

2011-12-20T13:24:00Z

想法

随着自己年龄的增大，生活也逐渐安定下来，越来越觉得很多的事情可以去做，回想过去，自己不是科班出生，所以需要自己慢慢的学习，幸运的是，我身边有很多热情的同事，他们给了我很多的帮助。
现在，我看见一些和我一样从农村走出来的程序员朋友，他们都很年轻，由于缺乏实战经验，拿着微薄的工资却仍然需要加班加点，看不到美好的希望。我虽然没有什么钱，但我算是肚子有点墨水，所以想出一个主意，就是通过一些形式帮助他们快速的成长，当然，我希望这些成长不仅仅是技术上，还包括思想、人格等各个方面。

比较现实点的形式，是使用沙龙这样的方式，原因如下：
1、几乎不占用什么资金，如果需要很多资金，我估计不能一直坚持，沙龙比较简单，买点零食有个场地即可。
2、参加的人可能参差不齐，搞讲座啥的会众口难调。沙龙形式主题随意，技术好的可以自己来讲，不好的来听。
3、沙龙能够比较好的促进共同成长，有经验的引导新生，等他们成熟后成为新的力量。

实施

具体安排上，我觉得每个月举行两次，一次小型活动，一次正式活动。安排在周二或周六比较合适。
小型活动限制为一个主题，人数少，比较随意，正式活动一般安排2-3个讲演主题。
另外，建立一个简单的网站，以便展示活动安排、成果以及记录会员的积分等信息。参加沙龙的所有人需要注册为会员，这样一方面可以互相交流，另外一方面也可以记录积分。
会员在参加一次活动后会获得参与积分，但也同时扣除分享积分，如果组织活动（文职）或主持活动，就可以获得分享积分，用于归还扣除的积分。这样做主要是期望大家能一起建设。

网站上包含了会员的姓名、联系方式、专长、参加过的活动和积分，联系方式只能是会员才能看见。
活动会设置文职的工作，活动前负责了解讲师的主题，发布到网站，购买零食和准备场地和设备，在活动期间登记参加的人员，录制讲师的视频，并在最后发布到网站。

这是我目前大致的想法，更重要的是我希望有志同道合的一些朋友能够和我一起共同建设。

本文链接

WinRT比.NET快了，还是Win8比Win7快

2011-12-04T10:44:00Z

我对WinRT的理解是，WinRT是吸收了.net设计经验，一套非托管的Win32 API替代品。对于.net程序员来说，当我们调用WINRT库时，理论上，要比调用.NET自带的库要快，是吗？我今天就自己验证一下。

我的想法是使用WinRT自带的List<T>和.net Framework自带的List<T>进行比较，创建一个List<int>实例，然后添加两个实例，循环1亿次。

在Windows 8 64位开发者预览版下，我创建了一个页面，然后执行下面的代码：

private void ListAddTest()
{
    System.Diagnostics.Stopwatch watch = new System.Diagnostics.Stopwatch();
    watch.Start();

    for (int i = 0; i < 100000000; i++)
    {
        List<int> list = new List<int>();
        list.Add(i);
        list.Add(i++);
     }

     watch.Stop();
     lstOutput.Items.Add("Time=" + watch.Elapsed.ToString());
}

测试结果基本在3.1-3.2之间，比较稳定。

然后，我重新启动，切换到本机另外一个操作系统,Windows 7 32位中文版，编写了一个控制台程序，使用.net framework 4 client profile。代码和上面一样。

测试结果基本在5.2-5.3之间，但很不稳定，偶发性的会快到4.7。

至此，我认为WinRT比.net快了，对吗？

我将Windows 7编译的程序重新在Windows 8环境下运行，测试结果竟然稳定在2.7-2.9秒之间。大出我意料！！

好吧，我犯糊涂了，

是Windows 8下，.net 运行效率提高很多？

是Windows 8下，程序自动切换到.net 4.5？是4.5比4.0快多了？

其实,WinRT下我并没有找到List<T>实现，其Windows.Runtime的DLL下，只有接口没有实现，我是在System.Collection.dll下找到的，是不是意味着我测试的实际上是.net 4.5与.net 4.0的比较？

求解？？

备注：

测试硬件为：Intel i3 M350 2.27GHz ，2GB 内存。

软件为：一个是Windows 7 32位中文版，一个是Windows 8 64位英文版（开发者预览版）。

编译环境：控制台程序在VS 2010 .net 4编译，WinRT程序在VS 12 .net 4.5下编译。所以编译均为Release版本，直接运行无调试。

本文链接

一个并发环境下的BUG分析

2011-11-29T12:41:00Z

今天接手一个并发压力下的一个BUG，程序报：“字典中已经添加了重复的键”，出错的代码如下：

lock (connectionList)
{
    // Next we'll see if there is already a connection. If not, we'll create a new connection and add it
    // to the transaction's list of connections.
    // This collection should only be modified by the thread where the transaction scope was created
    // while the transaction scope is active.
    // However there's no documentation to confirm this, so we err on the safe side and lock.
    if (!connectionList.TryGetValue(db.ConnectionString, out connection))
    {
        // we're betting the cost of acquiring a new finer-grained lock is less than 
        // that of opening a new connection, and besides this allows threads to work in parallel
        var dbConnection = db.GetNewOpenConnection();
        connection = new DatabaseConnectionWrapper(dbConnection);
        connectionList.Add(db.ConnectionString, connection);
    }
    connection.AddRef();
}

这段代码是企业库的一段代码（参见：http://entlib.codeplex.com/SourceControl/changeset/view/90009#526470）

那个Add方法出错的，我得承认，我花了很长时间想这段代码在哪种情况下会造成锁定失败呢？怎么可能有两个线程进来。你看出来了吗？

好吧，答案是，问题并不是在lock上，而是在两次调用db.ConnectionString上。

在并行环境下，外界错误的使用了静态变量共享了IDatabase实例（这个db对象），这是主因。但是在这段代码中，判断字典是否存在某个key时使用了db.ConnectionString获取，但很不幸，在并行环境下，这个静态共享的db对象被其他线程替换成了另外一个连接字符串，于是在Add时，使用了另外一个字符串作为key,又不幸的是，字典中已经存在了此键。

修改的方法当然是先取消外部静态共享IDatabase对象。但这个地方也不妥，严密的代码应该是：

string key = db.ConnectionString;
lock (connectionList)
{
    // 使用同一个Key值，而不是两次访问属性，可能不一致。
    if (!connectionList.TryGetValue(key, out connection))
    {
        var dbConnection = db.GetNewOpenConnection();
        connection = new DatabaseConnectionWrapper(dbConnection);
        connectionList.Add(key, connection);
    }
    connection.AddRef();
}

总结：

1、慎用静态变量，他经常是内存泄露、并发冲突的元凶；

2、注意属性可能在并发下中途被修改，可以使用字段备份一份。

本文链接

简单关系型结构的依赖运算模型

2011-11-06T10:21:00Z

简介：本文阐述了在数据型应用程序中，对各种运算的关系的分析，简化这些应用程序的开发以及提高性能的方法。

概述

在数据型的应用程序中，我们经常面对关系型的数据结构，即经典的表、字段和关系的结构。在这种关系型结构下，我们需要在某个字段或关系的数据发生改变后，作出相应的反应。

这些反应可能是数据处理的，例如当单价发生改变后，需要对金额进行重算，金额=单价*数量。也有可能这种反应是界面上的，例如未录入物料时，单价和数量均不能录入（Enabled=false)，但是，一旦录入后，界面作出反应，其单价和数量就可以录入了。我们称这种反应为计算单元。

我们注意到，这些计算单元，依赖某个字段或关系的数据更改，例如计算金额的计算单元，依赖单价或数量字段更改，而计算单价和数量是否有效的计算单元，依赖物料字段。我们也可以理解为，计算单元依赖的数据未发生改变时，无需重新执行这些计算单元。

我们理解这个“简单关系型结构的依赖运算模型”就是：在数据装载或发生改变后，智能的执行对应的计算单元的一套模型。

数据结构

既然我们在这个标题中已经限定了其是：关系型结构，那么一切的基础就是关系型的数据结构。在这个模型中，我们需要定义表、字段和关系。

表包含很多的字段，这些字段都是简单的数据结构，不能再拆分。在当前模型中，我们只能做到有且只有一个根表，所有的表都是此根表的子表或间接子表，以后将取消此限制。

关系描述了表与表之间的关系，一端是父表，一端是子表，在目前的模型中，我们只能支持固定的关联关系，那些动态的关联关系还未考虑。多对多的关系也还需要全面评估。

在实际的应用中，这个数据结构最佳实践应该是能够支持动态的数据结构，例如在某些界面中，基于性能的考虑，可能希望在用户点击某个页签时，才加载某个关系，关于此问题我们在其他的文章再讨论。

还需要注意的是，目前的应用程序，很多都是使用面向对象的数据结构，我们今天还使用关系型结构，是不是老套了。事实上，我一开始就是基于面向对象的数据结构设计此模型，但随着经验的增加，我发现，复杂的对象只会把事情越搞越复杂，而对象的结构最终都可以映射到关系型结构的模型上。因此，我将对象的结构映射到关系型结构上，从而使用关系型的结构处理对象的复杂情况。

计算单元

有了数据结构，我们就可以基于此定义计算单元，每个计算单元都包含一个批量执行的方法，在需要的时候，引擎负责调用此方法以便完成计算。

为简化具体的计算单元编写，要求计算单元必须提供一个TargetTable属性，他指向一个表，引擎执行计算单元时，将永远提供此表的数据。

假设在销售订单中，单据根表包含一个折扣字段，明细上包含金额和折后金额，当金额或折扣字段发生改变后，我们期望能够执行这个计算单元，以便更新折后金额。在传统的编程模型中，当折扣发生改变后，我们需要自己编码获取所有的明细，以便更新全部明细，而用户仅更改了某行明细的金额时，我们又需要仅计算此行的折后金额。

TargetTable属性就是向引擎声明：不论更改的字段在哪里，请帮我智能的转换成此Table上的数据。这样编写计算单元的程序员就很简单了，循环计算就是了。在这个例子中，当折扣发生改变时，引擎将提供所有明细给计算单元，而某行的金额发生改变后，引擎将提供仅包含发生行一条记录的集合。

在这里例子中，你也许注意到，此计算单元仅希望折扣或金额字段发生改变后才执行，其它字段改变就不要让我再执行了。我们称这种特性为依赖字段，此计算单元的DependencyFields为折扣和金额字段。

但你需要注意的是，计算单元不仅可以依赖字段，还可以依赖关系，一个典型的场景是：Items.Count 公式的计算，依赖关系Items的变更，当Items关系有新增、删除或重置时，需要重算此公式。当然，为统一概念，我们认为关系也是一个字段，称为集合字段，就像面向对象中一个集合属性一样。

与DependencyFields相对应的，当计算单元计算完毕后，可能会影响某些字段和关系，在这个例子中，此计算单元完成计算后将更新“折后金额”字段，引擎需要这样的信息，以便将依赖“折后金额”字段的计算单元放在此计算单元之后。我们称此特性为ApplyToFields。

与阐述DependencyFields一样，ApplyToFields也可以更改影响关系。

工作区及引擎

所有的数据结构定义及计算单元都被存储在一起，即一个工作区，引擎是工作区平行的部分，他负责调度这些计算单元。

在一个工作区中，会包含很多的计算单元，此模型的引擎在某些字段或关系数据发生改变后，分析哪些计算单元需要执行、执行的先后顺序，以及避免在批量处理时的重复计算。

引擎在初始化时，分析每个计算单元的DependencyFields属性，并建立数据结构以便在某个字段（或关系）发生更改后快速的找到其对应的计算单元。另外，还分析计算单元的ApplyToFields属性，建立数据结构以便快速的决定计算单元的执行顺序。

由于各种实体的更改通知机制不同，所以引擎本身并不包含对实体更改的追踪部分，而是让外界手动的通知引擎。可以建立一个适配器跟踪实体的更改，然后通知引擎。

更改通知包括字段的DataChanged和关系的CollectionChanged俩种，字段DataChanged比较容易理解。关系的CollectonChanged包括三种更改方式：插入、删除和重置。

引擎在收到更改通知后，将启动一个事物（事物处理由外界管理），以便能够在后续的计算发生错误后回滚现场。

根据此通知信息找到所有依赖更改字段的计算单元。找到的计算单元可能有重复，可以很容易的先去除重复的部分。然后，引擎再根据之前的数据结构很容易再推算出执行的先后顺序。

由于计算单元有TargetTable属性，所以引擎一种重要的工作就是分析出对应的目标数据。更改的字段所在表称为EventSouceTable，由于EventSourceTable与TargetTable存在某种联系，因此，可以通过EventSourceTable的数据推导出TargetTable的数据，这种运算很像执行一个SQL查询，例如：

Select TargetField1 From TagetTable Left Join EventSourceTable On XX=YY Where EventField = '01'

此算法有些复杂，我们将在另外的文章讨论此算法。

在CollectionChanged中，有一个叫“插入”的事件类型，这个过程很像我们的单据的新增或者新增某行明细，我们通常会在此过程中初始化一些字段的默认值。

当我们获取了需要执行的计算单元、先后顺序，以及各个计算单元对应的数据，我们就可以调用它们了。最后提交事务。

在执行计算单元时，某些计算单元不会影响其它的字段，即AppToFields为空，这种计算单元都可以最后执行，甚至异步执行。例如界面样式的计算、校验等。

另外一种特殊的通知是装载初始化通知，他发生在初始化数据或切换数据阶段，你可以理解为执行所有的计算单元，但事实上，计算单元还有一个属性指示是否在初始化时执行，大多数的计算单元此属性为false，因为当重新加载一个单据时，你并不希望重新再计算一遍折后金额，因为它们已经计算过了。但是那一定希望重新计算某个控件的Enabled值，因为数据已经切换了，锁定性也需要重新计算了。

引擎另外一个非常重要的特性是批量处理，Excel导入、剪贴板的粘贴、单据转换、邮件导入都是批量处理的典型应用。我认为，我们应该将所有的输入统一在一个模型上，看起来是一个“神键手”快速的录入数据，这样可以大大减少开发的工作量。

批量处理的重要点在于排除重复的执行，这可以通过分析最终的计算单元和对应的目标数据来完成。另外一个重点是，需要考虑数据录入的先后顺序，例如在销售订单中，必须先录入客户，再录入商品，因为商品要根据客户来决定他的销售策略。

此模型是一个复杂的项目，本文仅阐述其基本的组成及执行原理，更多的知识我们在后续的文章中介绍。

本文链接

新产品开发后期的主要技术工作：质量、性能、效率和推广

2011-10-28T13:35:00Z

新产品开发的后期以及发版后的一段时间内，很多的工作要做，作为技术人员，我的观点是，重点技术工作应落实到质量、性能、效率和推广。

质量

对于一个新产品来说，质量真的是比任何事情都重要了，一个动不动就死机的手机，其它方面再好估计你也不会用。第一个版本一旦出现质量差的影响，一般很难再翻身了，即所谓的第一印象。

要控制好质量，最好的方法我认为就是大量的单元测试，在产品开发后期，平台接口相对稳定了，不像早期的时候，接口一改，大量的单元测试要重写。在后期，最怕的是修一个BUG又制造了一堆的BUG，单元测试是最好的工具。顺便提一句，所有的单元测试必须保持全部通过，注意是全部通过，否则单元测试将毫无用处，因为当你改动了一个功能后，你很难知道未通过的测试用例是你造成的还是原先就不能通过。

性能

质量是第一步，第二步就是性能，这个教训，在Windows上是最好的佐证了。你看，微软这不Win8强调很低的配置也可以跑的很快吗？在没有选择的情况下，大家也就忍了，有选择的时候你客户跑的有多快啊，哈哈。

关于性能，我认为不要走火入魔，一个买十几万的产品，要搞千万级产品的负载是不妥的，性能优化也是要成本的。再比如，已经优化某个指令在100毫秒内完成，就没有必要要花很大的成本降低到10毫秒，客户能区分10秒比1秒快，但无法区分10毫秒比100毫秒快。

我们知道，底层平台的一个优化，会让上千的上层应用加快。但你也要记得，底层平台好不容易减少的几个毫秒，业务代码可能一个循环SQL就把这个应用搞的糟糕，因此，在调优底层后，代码检查业务代码也很重要。

效率

在新产品的开发过程中，我们知道工具非常重要，可现实是，除非非常重要且相对简单的工具，往往被“更重要”的需求所排队的后面。

在交付新产品后，应该对过去的开发进行总结，访问一线的开发人员，找到影响开发效率的点。例如在我们的开发中：

— 要加载太多的工程文件，机器运行缓慢；

— 附加方式的调试造成VS不能实现“编辑即运行”，每次发现错误都要停止调试；

— 配置的修改不能即时应用，要重新启动产品；

— 不能在运行时，使用即时脚本查看运行的变量值，运行日志；

— 造数据，要花很多的时间

这些点点滴滴的地方，你会发现一天的时间中，你只有很少的时间花在代码的编写上，大部分是在调试。

推广

我这里指的推广，指规范的开发方法在开发组的推广。在产品形成初期，大家也都是在摸着石头过河，代码写的是五花八门。现在，底层也稳定了，该经历的也经历了，有了这些丰富的经验，就需要总结各种应用其开发的模式形成文档和范例，这样，在产品功能的后续开发中才能规范和快速。

我认为可以建立诸如MSDN这样的网站，包含文档库、范例、教程视频和论坛。

本文链接

简化策略模型的代码

2011-10-17T14:03:00Z

在我们编写代码时，经常遇到一次策略模式（俺不会背那个啥设计模式，暂时叫他策略模式吧），例如，在反序列化时，已知一个名称和命名空间，获取其对应的类型，使用下面的策略：

尝试从绑定期中获取，

如果不成功，尝试从基类获取；

如果还不成功，尝试播发事件获取。

看起来，一个个尝试，如果不成功，下一个。代码是这个样子的。

private IEntityType BindToType(XElement element,IEntityType baseType, out IEnumerable<DcxmlBinder.CustomAttribute> attributes)
        {
            //第一级策略
            var name = element.Name;
            attributes = from p in element.Attributes()
                         select new DcxmlBinder.CustomAttribute() { Namespace = p.Name.NamespaceName, Name = p.Name.LocalName, Value = p.Value };
            IEntityType dt = _binder.BindToType(name.NamespaceName, name.LocalName,attributes);

            if (dt == null)
            {
                //第二级策略:如果没有，看看是否有缺省类型。
                if (baseType != null)
                {
                    //检查此类型的确正好是此名称
                    string n1, n2;
                    _binder.BindToName(baseType, out n1, out n2);
                    if (string.Equals(name.NamespaceName, n1, _binder.StringComparison) &&
                        string.Equals(name.LocalName, n2, _binder.StringComparison))
                    {
                        //不用检测派生关系，直接返回。
                        return baseType;
                    }
                }
                
                //第三级策略
                //TODO:应该先播发event System.Xml.Serialization.XmlElementEventHandler UnknownElement事件。外界获取类型。
                throw new ApplicationException();
            }

            //检查派生关系是否正确，即dt必须是baseDt的派生类型。
            if ((baseType != null) && (!baseType.IsAssignableFrom(dt)))
            {
                throw new ApplicationException("设计错误，返回的数据类型没有派生自baseType");
            }

            return dt;
        }

有点乱糟糟的，老实说，我也觉得乱糟糟的。于是我也想优化这样的代码，最终，我利用了C# 的或短路的特性，代码如下：

private IEntityType BindToType(XElement element,IEntityType baseType, out IEnumerable<DcxmlBinder.CustomAttribute> attributes)
        {
            IEntityType dt;
            if (TryBindFromBinder(element,out dt,out attributes) ||
                TryBindFromBase(element,baseType,out dt) ||
                TryBindFromEvent(element,baseType,out dt))
            {
                //检查派生关系是否正确，即dt必须是baseDt的派生类型。
                if ((baseType != null) && (!baseType.IsAssignableFrom(dt)))
                {
                    throw new ApplicationException("设计错误，返回的数据类型没有派生自baseType");
                }
            }
            
            return dt;
        }

        private bool TryBindFromBinder(XElement element, out IEntityType dt, out IEnumerable<DcxmlBinder.CustomAttribute> attributes)
        {
            //第一级策略
            var name = element.Name;
            attributes = from p in element.Attributes()
                         select new DcxmlBinder.CustomAttribute() { Namespace = p.Name.NamespaceName, Name = p.Name.LocalName, Value = p.Value };
            dt = _binder.BindToType(name.NamespaceName, name.LocalName,attributes);

            return (dt != null);
        }

        private bool TryBindFromBase(XElement element, IEntityType baseType, out IEntityType dt)
        {
            //第二级策略:如果没有，看看是否有缺省类型。
            if (baseType != null)
            {
                var name = element.Name;
                //检查此类型的确正好是此名称
                string n1, n2;
                _binder.BindToName(baseType, out n1, out n2);
                if (string.Equals(name.NamespaceName, n1, _binder.StringComparison) &&
                    string.Equals(name.LocalName, n2, _binder.StringComparison))
                {
                    //不用检测派生关系，直接返回。
                    dt = baseType;
                    return true;
                }
            }

            dt = null;
            return false;
        }

        private bool TryBindFromEvent(XElement element, IEntityType baseType, out IEntityType dt)
        {
            //第三级策略
            //TODO:应该先播发event System.Xml.Serialization.XmlElementEventHandler UnknownElement事件。外界获取类型。
            throw new ApplicationException();
        }

虽然代码比以前多了，但是看起来清晰了很多。而且，通常第一个策略都能完成搜索，所以就不会调用后面的方法，也就不会初始化其变量了。

本文链接

博客园_编写人生

我喜欢吃白米饭

IT沙龙 共同成长计划

快餐店的流程优化思考

宅男网上购买大家电对各大网站的总结

助您成长计划

WinRT比.NET快了，还是Win8比Win7快

一个并发环境下的BUG分析

简单关系型结构的依赖运算模型

新产品开发后期的主要技术工作：质量、性能、效率和推广

简化策略模型的代码

IT沙龙共同成长计划