tianyu的专栏 - Linux site:blog.csdn.net/wishfly

今天在微博上看到几位敏捷爱好者（本着讨论问题的态度故隐其名）探讨敏捷测试和质量保证问题，我忍不住也加入了讨论：Z先生原帖：我刚才看到一个大会演讲稿，谈到敏捷测试六大指导原则：1.仅靠测试人员不可能获得高质量的软件，质量是整个研发团队的责任；2. 场景是不可

PocketSetupCreator Create a stylish installer for your Windows CE apps  Summary PocketSetupCreator is an easy to use utility that wil

摘要：代码也分种类？哪种代码能够自动生成？自动生成代码会不会让程序员没有饭吃？或者会颠覆现有的编程模式？写在前面　　学习编程，再加上实际开发，写代码也有7个年头了。虽然不敢说有多少多少经验，但思考总是有一些的。这两年慢慢发现，原来代码和代码也是不同的。　　编程越来越趋于自动化，尤其在微软的产品里，程序员总是可以很懒惰。但懒惰之余也有顾虑，35岁的年限让很多人从25岁就开始焦虑，就开始“

软件企业中有一个角色叫做软件架构师，不同公司或者不同的环境下，对该职位的定位可能不尽相同。微软首席架构师Ray Ozzie 对自己职位的一些看法，倒是给人很多启发：1. 不管是设计一座桥梁还是一幢大厦，你是在特定的情况下应用各种设计模式2. 在做程序员的时候你要花时间让自己理解各种不同的模式，并能够认知那些设计良好的系统的特性，来提高自己对更高层次抽象的能力。3. 从不同系统中学到的越多，你就越能

这个项目由于我们公司设计经验不足，导致现在到后期需要花大量的时间来弥补。这几天在做项目中的消息整理和统一，觉得非常有必要在业务框架中加入相应的功能。一、消息分类    1、成功消息：{0}处理已经成功。       {0}中填入处理的名称，应该是各种按钮的名称。    2、输入check错误消息：{0}       输入check的错误消息没有统一的格式，由各个check贵    2、处理失败消息

这个项目由于我们公司设计经验不足，导致现在到后期需要花大量的时间来弥补。这几天在做项目中的Log整理和统一，觉得非常有必要在业务框架中调整相应的功能。 一、log分类    1、框架信息log       如：Action[{0}]处理开始，Action[{0}]处理成功，Action[{0}]处理异常等，与业务数据无关的log。    2、业务信息log       上篇《业务框架中Ｍｅｓｓａｇ

一，Exception的设计１、uncheck Exception的使用    服务器的framework中，所有的Exception都有框架来处理，业务不需要处理Exception。所以服务器端全部使用uncheck Exceptino。服务器端的uncheck Exception分为三种： SystemException DBException Busin

一、消息体系的实现重点    1、消息必须支持嵌套，应该实现自己的消息对象    2、异常和log必须只支持系统实现的消息对象    3、应该有自己的消息访问对象，可以在其中设定Locale和做一些必要的判断（如MessageID的判断）二、异常体系的实现重点    1、必须有一个共同的父类，用来支持自己的消息对象    2、异常的父类中必须有个属性标志，是否能够继续处理。当发生DB中断异常的时候

引子：　　伴随福特流水线模式的百周年，回顾软件业也已经走了近四十年的光景。而全球软件行业似乎已进入到了中年期，成熟的商业模式，缺乏雨后春笋般的创新型小公司，大公司增长乏力进而带来诸多的并购等。这些都让我们感受到软件行业早已今非昔比，大部分的软件公司都变成了鸡肋。软件从业人员也都从梦想的憧憬回到了实际的运营成本控制中。即使近几年炒得火热的SOA也无法为软件公司带来多少的利润和股价提升。难道软件业

架构 ＝装配线架构 ＝接口的集合 重用的粒度 ＝ 发布的粒度

Little Tutorials的一篇文章断言：UML(统一建模语言)正在死亡：1.由一个委员会设计； 2.他们老想着把UML转化成金钱； 3.试图统一所有的东西包括厨房水池（规格文本大于800页）； 4.想要一步登天，违反了程序员的认知； 5.观念膨胀； 6.总是在追赶新的语言和新的概念； 7.UML试图成为一个程序语言； 8.需要昂贵的工具； 9.模式不清晰；

敏捷软件开发模型--SCRUM一 什么是Scrum?Scrum (英式橄榄球争球队), 软件开发模型是敏捷开发的一种，在最近的一两年内逐渐流行起来。Scrum的基本假设是：开发软件就像开发新产品，无法一开始就能定义软件产品最终的规程，过程中

http://sd.csdn.net/a/20110512/297671.html

http://blog.sina.com.cn/s/blog_591a83bf0100oc6v.html

http://cloud.csdn.net/a/20110216/291968.html

http://topic.csdn.net/u/20110206/19/a3ce3fd9-d768-4f27-820c-70dd034f377f.html

http://sd.csdn.net/a/20110224/292464.html

http://topic.csdn.net/u/20110101/19/6ab1e45f-2387-4f34-bd13-132bbbeea660_2.html

http://cloud.csdn.net/a/20100607/267313.html

SERVICE_FAILURE_ACTIONS sdBuf={0};    BOOL bSuccess=TRUE;  if (argc!=2) {  return 1; }    // Open a handle to the service.  SC_HANDLE sch=OpenSCManager(NULL,NULL,SC_MANAGER_ALL_ACCESS); if (sch==NULL)

 前一阵子到苏州参加IC China 2006，在回来的路上我突然想起了这个题目。      事情是这样的，在一个路口我们车在等红绿灯的时候过了线，旁边还站了个警察。我们的司机由于忘带驾照，怕引起警察注意而导致不必要的麻烦，就把车往后倒了倒。倒车过程中，车上的倒车雷达叫了起来，司机师傅没管这个。完全依靠自己的判断将车倒了足够的距离。      那么这件事情和层与层之间的控制关系之间有什么联系呢？下

今天有一位同事问到一些开发的问题，我认为比较典型，故写上一段短文，希望能给大家一点启发。    我们遇到软件增加功能的时候，传统的方法是拿过源代码直接动手修改。这本身亦无可厚非，一般都是这样。但如果我们换个角度，从敏捷开发方法的角度考虑，却大有问题。因为直接修改代码本身有一个可怕的后果，就是引入bug，原先正常运转的功能面临被破坏的危险。    敏捷开发方法以快速响应用户需求和提供高质量的产品而博

  在 我的架构经验小结（二）－－ 关于三层架构 一文中，已经比较深入的介绍过三层架构方面的一些经验了，现在，我们来使用一个更小的比例尺来近距离观察我所理解的三层架构。一．三层架构图 二．系统各层次职责1.UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服

在 我的架构经验小结（一）－－ 常用的架构模型 一文中简单介绍了我常采用的几种架构模型，本文将稍微深入地介绍其中的一种 －－ 三层架构模型。一．三层架构图 二．系统各层次职责1．UI（User Interface）层的职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。与UI平行的Service Interface层用于将业务发布为服务（如WebServices

 经过这几年的积累，在系统架构方面逐渐积累了一些自己的经验，到今天有必要对这些经验作个小结。在我的架构思维中，主要可以归类为三种架构模型：3/N层架构、“框架＋插件”架构、地域分布式架构。一．三种架构模型1．3/N层架构       这是经典的多层架构模型，对于稍微复杂一点或特别复杂的系统，不使用分层架构是很难想象的。下图是经典的3层架构：     如今，凡是个程序员都能侃侃而谈3

 AOP：通过面向方面编程提高代码的封装和复用性发布日期： 4/8/2004 | 更新日期： 5/28/2004http://www.microsoft.com/china/MSDN/library/windev/COMponentdev/AspectOrientedProgrammingEnablesBetterCodeEncapsulationandReuse.mspx?mfr=t

以数据库为核心的软件时代已经过去，数据库时代早已结束，当我看到J2EE征途中那么多人在对象和数据库之间彷徨痛苦ing的时候，我想我该出来喊一声了。　　其实这句话在几年前肯定有人喊过，因为中间件时代的来临，实际意味着数据库时代终结，正所谓一山无二虎：如果你重视数据库，你的J2EE系统就无法完全OO，只有你忽视数据库，你的系统才有可能完全迈向OO，至于数据库性能调优等特定功能都可交由EJB容器或O

多变且复杂的需求　　如果没有多变的需求，也许就没有今天的面向对象软件，我们曾经试图通过需求管理、需求跟踪等等管理方式约束和减少需求频繁更新带给软件的冲击，可是这样下去的结果只有一个：使得软件更加僵化；或者程序员更加 劳累。　　需求不但多变，而且经常是不可能第一次就能掌握，需求反映了某个领域的专业知识，例如数学、管理、财务或 电子商务等等，每个特定案例需求又有其特别复杂之处，几乎没有人能够第

 有人说：今年是AJAX年，AJAX作为软件系统表现层实现技术，怎么能和改变软件开发方式的模型驱动开发模式相比呢？DSM、Together 2006等都在2006不断亮相，因此，说2006年是领域模型年一点也不过分，因为这是一个软件新旧时代的开始之年，数据库时代已经过去。领域模型时代已经来临！　　过去，当我们面对一个新的业务需求时，我们总是从先建立数据表结构开始，这种面向数据表的分析设计方法已

前言  上一周由于工作的需要，我尝试运用面向对象的设计思想来解决实际工作中遇到的一个设计问题。整个设计过程主要涉及到C++语言,OO编程思想，设计模式这三个方面的知识，是对我软件设计能力的一次综合考验。虽然最后由于种种原因，我的设计方案并没有获得采纳，但是这个并不重要，重要的是在整个设计过程中我自己思考过，并提出了我的方案，也就是说，我在这次设计过程中学到了很多。我决定把这次设计记录下来，一方面是

STRATEGY模式———赵子龙单骑救主junguo    STRATEGY在中文中被译成了策略，我感觉这个意思并不妥切，但翻英文词典能得到的翻译也只有这个，我的词典比较简单，不知道是否还有其它意思？如果没有，那么我想可能和中国研制的CPU在研发阶段被定名为“狗剩”一样，它只是一个名字而已，并不能确切的代表真实的意义。经典著作《设计模式》中将策略模式定义为：定义一系列的算法，把它们一个个的封装起来

自从2004年7月开始，就一直从事N层C/S架构的服务端的开发，从最初的熟悉各种Windows Socket API、熟悉完成端口模型，探索高效稳定的服务端通信模型，时至今日，慢慢的积累了一些（N层）C/S系统的开发经验，ESFramework体系便是这些经验的总结。ESFramework的前生是EnterpriseServerBase类库，后来我将EnterpriseServerBase中的Ne

软件开发之所以复杂，是因为业务需求与程序语言之间存在的巨大鸿沟，有太多的变数。你无法清晰和准确的描述你所想要的东西，而即便你能，你也很难最后实现出来的东西是不是你所想要的。因为，在软件业，宏观的业务需求很多时候竟然是程序员决定的，要确定一个特性具体会怎样体现，你竟然不得不去看源代码。就好比说，制作一架航天飞机，你不得不从每一个螺丝钉开始考虑。软件太虚幻了，以至于你无法从外观上看出，一个exe程

我做软件设计有一个重要原则，即经济性。这个原则最终决定了软件的功能和定位。两年前开始开发定下来的基本架构到现在都没有大动。这至少说明这个框架还是比较成功的。但随着时间的推移，问题也暴露出来的，比如不支持回退，不支持结果的回馈（即修改了构件向导产生的钢筋，下次重新提交的话不能记住修改）。有的问题可以通过改良来修正，而有些却需要用打破旧世界的革命来完成。这很令人恐惧。再回到“经济的做软件”的原则，我们

黑板架构与两层架构相类似，有着某些局限性。最明显的缺点，就是所有的数据之间的完整性需要应用程序员来控制，这对大型应用来说，这是一个恶梦。主要原因是黑板架构中的黑板和两层架构中的数据库都不能对真实世界建模，因而维护这些非常具体的数据的工作量也的确大的惊人。    针对上述问题，在上个世纪的70年代就出现了三层式架构的说法。这里的三层式的三是虚数。实际中往往不止三层。最著名的三层式架构就是Micros

 DOS时代的程序员是电脑的主人，从main()函数执行开始，程序员就开始接管了电脑的一切。所有的一切都尽在程序员的掌控中，感觉非常好。随后，进入了Windows时代，一下子一大批程序员倒下了。原因很简单，不能适应Windows的开发环境。在Windows的框架中，消息驱动是核心。程序员从一个发号施令者变成了一个被调用者，等待Windows的调用。所以不能适应这一点的程序员被淘汰就是顺理成章的事情

计算机语言的发展，从过程式到面向对象的编程不断的发展。解决的问题也越来越复杂。我记得有一个名人所说：写出一个让计算机理解的程序并不困难，要写出一个人能理解的程序就非常困难。    我自己在这方面就有很深的体会。很多程序写了较长时间，回过头再去理解就非常困难。至少要花很长时间。显然，这很不经济，白白浪费大量时间。可能有人要问，为何不写文档？事实上，一方面写好文档就非常困难，因为程序本身应该就是最好的

  我一直认为，很多道理都隐藏在我们的周围，只不过我们没有认识到罢了。在这里我先从一个简单的故事开始。这个故事我已经在很多场合讲过。在找到更好的故事之前，我将一直用它。    我说的这个故事的名字叫“总经理与秘书”的故事。这里没有任何桃色新闻，这点恐怕会让某些人失望:)。    上海的一家公司的总经理A明天需要到北京参加一个非常重要的会议，他叫过来自己的秘书B吩咐道:“B小姐，请帮我订一张明天早上

为什么要区分J2EE容器和J2EE应用系统？　　我们知道，J2EE应用系统只有部署在J2EE容器中才能运行，那么为什么划分为J2EE容器和J2EE应用系统？ 通过对J2EE容器运行机制的分析（见我的电子教材“EJB实用原理”），我们可以发现：实际上J2EE容器分离了一般应用系统的一些通用功能，例如事务机制、安全机制以及对象池或线程池等性能优化机制。　　这些功能机制是每个应用系统几乎都需要的

以前的帖子提到依赖三原则,我当时是这样写的：1 任何一个类不要从一个具体类中继承；2 任何一个类成员不能指向一个具体类；3 任何继承类的成员函数不得覆写父类的函数；    近来研究一种新的架构设计方法。突然体会到架构和依赖三原则原来竟是完美的统一。为了保持架构的弹性。在C++中，架构代码一般有两种写法，一种是完全是由接口类外加组装类构成一个体系，现在的ECAD就是用这种方法写的。这充分体现了我以前