@黑星
如果可以请将简历发到我的邮箱好吗？

@空军上将
考虑到代码优化以及二次缓存，在某些情况下，C#的速度不一定比C++慢。

@Leepy
谢谢

@lovesea
我想我们应该坐下来好好聊一聊。和我联系吧，13911812676(最近项目太紧了，有时候可能会关机)。MSN:Iverson_Anders@hotmail.com

@镜涛 and @心有灵犀
其实应该是网络或者是图形处理。

@空军上将
实现和它一样的功能型软件

@Reeezak
谢谢。就为这人品。

@jisen
我们要的不是大拿，是兄弟！

@曼陀罗
其实我们现在的软件开发没有大牛和菜鸟之分。毕竟当你选择.net之后，也就意味着我们是搭积木的人，而非底层艺术的舞者。所以，对于团队来说，大家需要的是“人品”(我们的Dota常用语)、团结还有就是学习速度。这次扩招是因为正好有一个保密性比较强的项目需要在3~5个月内完成，所以目前需要的是能够马上为“无产阶级革命”作出贡献的人。不过这个项目完成之后，我们大概在明年年初还要再扩招一次，希望在那个时候可以看到我们的罗陀罗之花。

@williamnet
事实上，我已经说了啊。开发类似google talk、outlook、ArcGIS、ACDSee的软件。开发工作地：北京。哈哈，刚看完《太阳照常升起》，学会在电影里藏剧情了。

@jillzhang
不过，我已经把我最需要的说出来了,:)
我们团队不是以工资的形式发放的。基本生活费少的可怜，5000~10000吧。主要是技术贡献奖，这个非常高，每个项目结束后，技术贡献奖会比基本生活费高的多的多。不过，每个成员是不一样的，需要跟据成员对项目的贡献程度来定。

@TerryLee
哈哈，刚刚路过Try的BLOG，罗嗦了半天，转过来看，真是非常不错。

看了Jeffrey Zhao的留言，想起微软在04年的时候，大概是04年，记不清了，出了几期杂志，有一个系列《使用 Microsoft .NET 的企业解决方案模式》的Web 表示模式，其中更是将观察者模式融入到WEB架构上讲解。值得一看。由此推荐Terrylee的.NET设计模式（19）：观察者模式（Observer Pattern），然后Try的《IOC，观察者模式，项目的实际应用 》，再然后Microsoft的《Web 表示模式》,再然后CompositeUI Application Block的Events命名空间源码。哈哈，这个主意不错吧！

@try
谦虚了，例子的结构正好能够说明观察者模式的应用，是个非常好的补充。我也有两个例子要推荐：一个是R.C.Martin的CrouseControl.net与CCTray，持续构建应用一个非常不错的工具，可谓观察者的框架级应用了;另一个是CAB的事件处理机制,更是将容器和观察者模式有效的结合在了一起，哈哈，非常符合楼主的这个主题。刚刚路过，不免多补两句，向TerryLee和TerryLee学习。

哈哈，一篇一篇的贴，结果贴了一大堆。刚刚拿掉了。

有点意思，我喜欢。怎么听怎么像单口相声，以前是老师吧，听着像。和我一样，愿意用鼻音，不过我拉得不好，讲座太少的缘故大概。多学习，哈哈。

@sunlife
HI，我认为你可以从重构和设计模式开始。在做项目时，自己多试着分析一下是个不错的方法。不过我的观点可能有点特别，事实上，我一直认为重构的时候反倒更能帮助你学习OO的思想。我们很多人认为在一开始设计的时候就应该采用设计模式了，我却恰恰相反，我认为大多数的设计模式是在重构的时候才不断提练出来的。所以多数情况下是这样的：需求分析、简单设计、测试用例编写、编码、测试、重构、再设计、重构、设计...。就像KENT一样，最近好像有一本书要出了，叫做《重构与设计模式》，不知道谁写的，不过听名字就知道这是一个非常有实战经验的人，推荐你读一读。

@虾米
企业库应用[OOAD]的意思是以企业库为案例讲解OOAD.

哈哈，我猜想只有你知道讲智慧是谁。

@GouGou @GoGoSonny
别着急，可以从OO的思想开始。我们正在着手准备这方面的内容，多提意见啊。
@ etng
HI,又见到你很高兴。

@源码工作室
大家互相学习吧
@joycode
谢谢鼓励
@天轰穿
哈哈，加油，哥们

这个部分可以参看《Java编程思想》，论述的非常清楚。我觉得对于c#语言入门，最好看一下这本书，会非常棒。

内容还没看呢，先坐一下

老赵说的有道理。
如果你当初的XML不是试验用的，也就是你的XML，不是你从数据库读到DATASET中，再用DATASET的写的XML。(别怀疑，我以前试XML的时候比较懒，不自己写XML，就常这么干)，那么老赵提到的可能性最大。
转换一下就OK了。

如果你这段代码：
for(int i=0;i<row.Length;i++)
{

Dt.ImportRow(row[i]);
}

打印出来的数据是正确的，可能的情况有两个：
1、你绑定的是DATATABLE,而不是排序后的DATATABLE对象，见
DataRow[] row = dt.Select("", "SortID ASC");
DataTable Dt = dt.Clone();
...
DataGrid1.DataSource=Dt;//此处的DT有没有排序呢？
2、DATAGRID按照默认的数据列排序了。如果是这样的话，可以指定DATAGRID的排序列，或者是执行DATAGRID的排序事件就应该可以了。
我很少写控件程序，但逻辑上应该是这样。我手头只有2.0，没有1.1的，没法查帮助。不过应该是这方面的问题，不会偏差太大。

@牧野
我个人在实作的过程中，比较重视用例文本，但是除了比较重要的需求之外，我几乎只写概要性的用例文本，就像视频中那个简要的文本一样。对图来说，我一直采用草纸绘图，只是为了视频的需要，我用ROSE进行了绘制。通常在项目组中，我只对重要的用例总结性的绘制。对于UML的使用，我推荐你看一下Martin的《UML与JAVA》，说的非常好。我也有一个总结性的文档，如果需要，我可以发到网络上。
@奔放
HI,好久不见了。最近项目比较忙，同时有多个团队并行运作，白天根本没时间上网。不过你的留言我看到了。
@天轰穿
你不用抗议，我的名字你也写错了。虽然我很有智慧吧，哈哈。
@dudu
谢谢你的服务器，一下吃了你30M,不过还好，我刚刚重作了一个，现在是20M了。
@CrazyCoder
把你的经验也拿出来和大家分享一下吧
@文野
不是不动了，是我当时没作好，你得一直点PLAY才行，能见main的留言。
@虾米
正如我以前所述，UML是器，OOAD是术。见意参看我的乱谈UML与OOAD系列
@main
谢谢哥们。我能理解你的痛苦。所以我把这个视频重作了。事实上，我也好不到哪儿去，作这个视频，整整用了一周的时间。哈哈。不过真的谢谢你，让我一边点一边看，我就没这耐心。

谢谢各位，我会尽自己的最大努力的。因为这段时间项目组的事情比较忙，所以回复比较慢。不过我会在本周推出一个DEMO测试一下，看看大家的反馈。

@Justin
是啊，所以汗如雨注。真的。希望得到你的帮助。
@ocean2000
：）

@ocean2000
我手边没有准确的定义可供参考，因为我还在“咖啡店”泡妞呢，哈哈。有两个简单的定义，不准确但是或许可以帮你。
OOP，面向对象编程，你知道的
OOA，面向对象分析，如何分析需求，如何获取分析类，如何获得初始架构
OOD，面向对象设计，如何根据需求定义设计元素，如何解决非功能性需求问题，比如性能，比如容量，比如日志的问题，这些内容如何在框架里实现等等。
OOSD，面向方面的用例驱动开发。

@ocean2000
谢谢你的见意和支持。我个人真的希望像你这样的朋友多一些，可以换位思考。你提到的这几点对我非常宝贵，也是我一直希望做到的。事实上，我一直在我的课程里加入自己的想法和看法。因为我认为这会对大家有帮助，效果还是不错的，但也因此经常会遭到网友的批评和漫骂。不过放心，我们一定不会让你失望。
另，关于测试驱动和用例驱动的内容，我曾经有过一小部分文字，可以供你参考：http://www.cnblogs.com/Iverson-Anders/archive/2006/07/25/458867.aspx

@ocean2000
用例驱动的思想是以业务作为根本的。即根据用例(需求)获取分析元素(分析类与初始架构)，然后再将分析元素落实到设计元素(设计类、包以及子系统)，设计元素通过开发完成组件的设计和布署。即用例到用例实现的过程。
测试驱动的思想是以测试为根本的，什么叫测试驱动。打个比方，你要做个Add函数，这个函数接受两个int类型的值，将它们相加返回。那么如果这两个参数分别是4和5，那么返回的结果就应该是9。也就是说Assert.AreEqual(9,obj.Add(4,5))是对的。这么看来实际上单元测试本身不应被看作测试，而是开发的一部分。所谓的重构是建立在单元测试的基础上的。
这两个驱动的方法是当前最为流行的两个面向对象的设计方法。而它们的开发先驱都是我们软件业的巨头。事实上，目前流行的OO思想几乎半数都来自于他们。你所说的开发我猜测可能是指OOP，而开发的过程还要包括诸如OOA、OOD以及OOSD等等内容。我以上的解释存在一定的漏洞。但我想可以帮助到你。

对，我也认为课程是要用案例串的。就怕时间来不及，所以总想扯上开源项目或者企业库。正好TerryLee 做企业库的课程，因此，我俩之前的想法就是合作一下。具体情况得作出一期两期后，大家反馈回来看看。

我原来写了一个大纲，后来给删了。觉得还是把思路发出来吧。看看大家的意见。

@局外人
在国内，对着自己人，我就要称我们国人。我们国人在什么地方是好的，什么地方做的不好。我从来不怕自己的国人骂我，大家越骂我，我越觉得自己写的东西有意义。哪怕我自己的知识不够，我的历史太薄，但我仍然要写。但是我不想让外国人骂我，不想让外国人这么看我们国人。因为这是一种耻辱。这就是我的位置。

@双鱼座
SORRY，我想我真的要解释一下。那么说，是我自己的文笔不够。我并非不是不承认自己的问题。是对自己的失望，因为要改这些毛病改了很久了，一直改不掉。就在前几日还写了一篇东西责怪自己。所以我为什么叫自己固步自封。就是总认识到自己的缺点，但总也改不了。局外人怎么看不重要，但我不希望你误解。这个部分可以参看我18日的BLOG：
http://killeriverson.spaces.live.com/blog/cns!96C8C045164B5DC9!766.entry?_c11_blogpart_blogpart=blogview&_c=blogpart#permalink

我个人以前是讲师。5年讲课经验。前两年主讲.NET平台，后几年主讲UML、OOAD和软件架构方面的内容。(可以在网络上搜到我的讲课案例)目前带项目，如果讲课是免费的，我愿意参加教师团队，大家互相沟通交流。我的MSN：Iverson_Anders@hotmail.com。

@ballake
Sorry，我给漏看了。不过小陆的话，好像有了回答。

@小陆
很有道理，从留言上就知道小陆是个高手。大家多交流，互相促进。
@zxy
没有失望。事实上昨天在和国外的朋友通电话，我还一直在说，回来吧,现在中国的机会是最大的。

@uxabc
你说的有道理，要不然我不会有时间写这随笔。就像你有时间给我回复一样。
@kklc
对儒家了解称不上，但多少知道一点。我一定会加强自己的学习，事实上我一直是这么做的。
@双鱼座
谢谢。我就说过我自己做东西从来不严谨。一直想改，改不掉。这是一直养成的习惯，很难改正的。
@etng
事实上，我也需要吃饭的。我在写关于UML的网络免费版的文档，相信大家可以看到，写的不好，都是自己的理解。有时候会顺手加评论，就和现在这样，哈哈。另外很高兴认识你。
@Liusa
我同意你的观点
@flyingleaf.
非常喜欢你的留言。我在写这随笔的时候，是因为看到的一些事情，想到国内大多数的项目。所以写下来。并没有以偏盖全的意思。我想我们需要在一起讨论。发现我们自身的问题，有的就加以改正。没有的做为警戒，是好的。有一点需要说明的是电视里的秦皇汉武是光辉的，但是真正的历史也有一些问题。比如李陵、杀朝鲜国君都发生在汉武时期，在汉武的后期，面子工程是比较严重的。关于毛主席，我本人非常遵重。需要说明的是，我没有以偏盖全的意思。我只是想我们自己家里的人坐下来，看看。反思，总结而已。我喜欢你的留言。
@Wisdom-zh
我支持你的观点。这是我一直想说的。但是作为我自己目前的立场是不能说的。我听说《丑陋的美国人》出版之后，很多的美国人都响应，大家一起总结。好像还做了很多期节目。我还听说《丑陋的中国人》一直没有办法出版，出版之后几乎被口水淹没。而这本书的灵感就来自柏杨先生在狱中的生活。有时候我们真的要反思一下。我们到底要不要指出自己身上的问题，我们要不要认真的分析一下自己的问题。王安石是个伟大的哲学家和政治家，可惜指出的太多，死掉了。柏杨先生也“死”掉了。我不想“死”，我只是一个帮着敲边鼓的。因为我觉得自己首先是个中国人，如果中国人要想站起来，就是把自己的问题藏起来，而是提出来，改正的。问题不会因为你没有发现，没有指出他就不存在。我非常同意Wisdom-zh 的观点，少一点吵闹，多一点心平气和。

谢谢各位的留言。有时候自己静静的想，会想到一些东西，就顺手写出来了。这是目前的现状吧。有一些诱因。我本人在读一些中国历史和中国哲学史的东西，结合软件行业总会有一些感触。所以记录下来。
说到这里，想起前一段时间的一个网络案件，起缘是某人使用了MSN，被使用QQ的人称之为汉奸。很是心痛。我不知道应该怎么帮助他们。最近有读一本书，柏杨先生的《丑陋的中国人》，很喜欢。也看到了网络上很多骂的人，更为心痛。我曾经看过《丑陋的美国人》，也曾经看过《丑陋的日本人》，为什么不能有《丑陋的中国人》，如果没有，为什么要怕别人写。如果有，为什么不正视它。我们国人最大的毛病就是一旦要认认真真的找找自己的问题，马上就会被人扣上汉奸之类的帽子。真的心痛。
我原来不想写国人的劣根的，见到这种情况，更想写下去。而且一定要写下去。如果大家有兴趣，见意看一下柏杨先生的《中国人史纲》，尤其是宋朝那段。一定可以感知我现在的心情。

TO：Binger
UML是一种可视化的帮助我们面向对象的看待问题的一种语言。由Iver、james和Grady共同将自己的思想和方法组合发展而来的。很好的工具。有兴趣的话，见意看一下。我推荐Craig Larman的《UML和模式应用》和Matrin的《JAVA与UML》。另外Matrin Flower的《UML精粹》非常不错，不过翻译的可能不太好，和大家平时熟悉的概念有一些出入，如果英文不错，推荐看英文。另外网上有IBM发布的UML讲义，你可以搜索一下。

TO:wu
我并没有说老外好，我在文章里提到过老外好吗？我用我的想像看国人怎么使用UML？我自己就是培训UML的老师，五年了。我是由我在平时培训的所见所闻而得的。那么反过来，是谁在用自己的想像力呢？我说国人的劣根性，并不代表我崇洋媚外。事实上，我曾经专门写过一篇文章，论中国的文化起源，说到自己国家的强大和文化历史。就像我关起门来和家里人说，我说大家看，我们家有什么问题？这个家里就包括我。于是你说，别人家好你去别人家啊。这个我可以理解，就像我说的，这是我们国人的劣根性。
不是说自己不好，就是崇洋媚外。不是用MSN，就是汉奸。
反过来谁是一面之词呢？

谢谢
当时写完了，贴在MSN上了，后来转过来的。

@浪子
我自己还没解决呢，谁帮个忙？

蛙蛙多大了？

哈，谢谢。

@LIVE and Cavingdeep
感谢二位的参与。尤其是不同意见。
有些术语我想可能会有误会。
1>调试。这里的调试并非指像VSNET里的调试。我的意思是当结果与预期值不一致时，我们可能需要在某个测试块的内部设置一个断点，以监视一些内存的变化。这里有一个前提，就是在实际的项目开发过程中，不需要对所有的功能块都进行测试。就我个人而言，我把系统的功能块也分出优先等级来，比较重要的功能块就像我们都知道的一样，分成一个一个小的步骤，小的功能来实现(这个部分可以参见我前面的blog“有病呻吟”)。但是对于一些并不重要的功能块，因为项目时间紧的缘故，我们常常采用重用某些即有代码的方式(这些代码有时候比较久远，但是在多个项目中已经被多次应用)。我们不可能也不需要对所有的功能点进行测试。我采用的是以用户故事的方式将代码组织在一起，每一个用户故事(或者每一个功能模块级用例)为测试函数。这时候，当测试不能通过时，我就采用断点调试，一步步跟踪，必要时把该函数分为多个单元测试块。如果通过，我一般并不再分。当然，我也希望把所有的单元测试都完成一小步一小步的。但是在现实的情况下，我们并不一定能够全部做到。所以我认为可能把功能块划分优先级。每个优先级有不同的测试方案。
2>单元测试与重构需要组合。我一直赞成这一点，而且项目组一直这么应用。已经有两年了。我们在这一点上没有分歧。可能我在说明某个问题时没有表达清楚。（这个部分可以参见我前面的BLOG）。
3>使好了任何一个工具，都可以发挥其威力。这句话没问题。但是如果使不好呢？NUnit是可以调试的，我之前也承认了。我只是说他的调试功能不如MSTest的强大。而NUnit的使用又有很多MSTest不及的地方。比如我，只是一个工具的使用者，我并不想对他有更深的挖掘。但是在实际的工作中又需要使用到它们的长项，所以才有了这篇文字。所以我们需要对一些内容有一些深入的了解，而有一些内容只需要了解皮毛就好了。就像我们需要了解单元测试本身，而不需要了解单元测试的各种工具一样。这篇文字也只是我在项目过程中遇到问题后，想到能不能即用NUnit，又能用MSTest呢。所以做了个小试验。在此没有比较工具的意思。但是我在文字的前面确实提到了。我这个人就是这样，有时候脑子里想到一些，说的时候又说一些。比较随意，非常的不严谨。哈哈。倒是让两位仁兄见笑了。

我真诚的感谢各位对这篇文字的回复，受益非浅。我有个提议，大家找个时间把各自的经验和学习的总结拿出来分享。然后再总结出点文字出来，我想是好的。
我的MSN：Iverson_Anders@hotmail.com

我想让我把单元测试的内容好好整理一下。然后重新做个视频出来。毕竟发布的东西最好是有效的。
关于团队开发流程的内容，我曾经有一个贴子http://www.cnblogs.com/Iverson-Anders/archive/2006/07/30/463090.html。这个贴子与其说是写NHibernate在项目中的应用，不如说在我的团队中的开发流程的一种映射。还有一些以前写的单元测试的贴子。有时候你从书本上向实际，或者说是从空中向地面转移的过程中，是要学会理性的批评的。有很多内容在书本上行的通，但是在实际的过程中你必须学会转化。所以我比较喜欢JOEL。Kent Beck也是我喜欢的大师，可以说是崇拜的偶像。但这并不是因为他的程序功底，而是因为他做学问的精神。不知道大家看过他最近出版的《拥抱变化》没？把以前的一些内容给推翻了。这种求学的精神真的是值得我们学习。不是吗？
我还喜欢Bob，他总是要把一些理论的东西实践一下，才可以。我想这也是他为什么这么受欢迎的原因。
我喜欢那些大师的东西，但我从来不迷信。有时候甚至极端。比如我把单元测试和用例就在项目组中结合在了一起，感觉不错。但是有硬伤。也许，我们还需要不断的探索不断的实验，千万不要把自己滞固在理论或者是技术细节上。就像BOb的Thoughtworks一样，把经验总结出来，一点一点的，形成实实在在的东西。
当然，没有什么东西是一定的，我们需要不断的提出、实验、测试、总结、重构。是的，它们是一个反复迭代的过程。但我们需要这种迭代的精神，不是吗？
最近项目组在写一个.NET下的技术框架。我们将架构机制都放在这个框架里。有点像Ivar的新用例思想。快完了，回头我把它发布上来。大家一起评判吧。

@Cavingdeep
单元测试是需要和重构结合使用的，没错。这一点我并不反对。事实上这十二个最佳实践都是相互结合的。我一直秉奉的一个原则就是简单设计-单元测试-简单实现-重构。这个部分我在写项目开发流程的时候不只一次提过。

当我拿过一个即有的代码，需要测试他的功能时。它和单元测试毫不相关。我承认，这是对的。但是对于我来说，我仍然不习惯新建一个控件台程序来测试功能，我习惯在一个单元测试里看看他有什么。没错，那不是单元测试。但我习惯用单元测试工具看看即有的开源项目里的功能。这和我的习惯有关。PASS

“单元测试本身也不能保证它的正确性，它需要和功能本身相互映证。”这句话请查阅Kent Beck的《测试驱动开发》。

采用集合的输出是固定的。在我的项目里会经常变动数据库。总部,分部,项目组,小队。采用的数据库都是不一样的。几个位置集成开发。因此我采用的方法是在单元测试里添加一个小的函数，虽然有唯单元测试的初衷，但是用起来不错。有效的就是合理的。至少它对我有效。

团队开发和个人开发是要有机结合在一起的。自动化单元测试的好处我当然会注意，要不然我也不会在一开始就提出CVS+CruiseControl.NET+NAnt(或者MsBuild)+NUnit+NConver+FxCop的持续构建组合。事实上，我之所以要用两个工具的目的就是个人开发的时候可以使用MSTest的调试功能。而签入时则会应用自动化测试的好处。

以上是我在项目中的感受。有不同意见，我们互相进步。
我想这个论题大家要讨论下去。
在敏捷开发的过程中，我也有一些心得。但有很多看起来不成体统，使用起来还是非常有效的。我想大家把自己的心得体会都拿出来。争吵、讨论、总结。一定会有属于我们国内团队的有效经验。

没错，我也认为单元测试不应该和调试混为一谈。但是如果当你拿过一个即有的代码，需要测试他的功能的时候，要写一个新的项目吗？我可不这么认为。为什么不把调试和单元测试放在一个项目下呢？尤其在这个需要大量学习前人即有经验的时候。TestDriven我用过，很早了。后来就没怎么用，而且MSTest看起来比它更专业。我曾经在一个项目中改用MSTest，后来发现在持续构建的时候有问题。所以写了这篇文字，几个月之前的事了。你的一句话，我并不认可。就是“需要调试的单元测试并不是好的单元测试”。单元测试本身也不能保证它的正确性，它需要和功能本身相互映证。如果我们需要一个验证结果，但是又于期望不一致时，我认为有好的调试功能恰恰是一个不错的主意。事实上，我并没有准备把大量的难度的代码放在我的Code里。在我的Code里，代码常常很简单。比如当你的返回结果是一个集合的时候，比如从数据库里取数据，怎么办？用Mock？我认为你可以在可调试的环境下搞个单元测试出来，虽然那个代码最多不会超过三行，但是调试是一个不错的辅助工具。也许，你有更好的方法可供借鉴，希望能和大家一起分享。

还有一个问题，我想大家一起讨论一下。就是单元测试的粒度，我曾经想单元测试应该和用例一样有粒度的划分。虽然Kent Beck的初衷是测试单元的，但是我认为在测试单元的基础上，应该有测试功能的。是的，是的，那可能就不是单元测试了。但是想想看，如果我们需要测试先行。为什么不将小的用户故事(或者用例)分成多个任务，然后直接针对任务写我们的单元测试，虽然这个粒度大了点，但是将他们穿起来就是一个故事。当然，我们还是需要把这个粒度的大块分成几个小块。就像CockBurn的白云、风筝、海平面....我曾经在自己的项目组里试过，感觉不错。不知道大家什么感觉？