10 2015 档案
摘要：写一个函数，用递归函数完成以下运算:sum(n) = 1 – 1/2 + 1/3 – 1/4 + … -(1/n)*(-1)n （其中n>0）函数原型： float sum(int n);函数参数：n为正整数。函数返回值：相应于给定的n，右边表达式运算结果。提示：你可以使用递归表达式： sum(n)...
阅读全文
摘要：头五项原则是关于类设计的，它们是： ◆ SRP，单一职责原则，一个类应该有且只有一个改变的理由。 ◆ OCP，开放封闭原则，你应该能够不用修改原有类就能扩展一个类的行为。 ◆ LSP，Liskov替换原则，派生类要与其基类自相容。 ◆ DIP，依赖倒置原则，依赖于抽象而不是实现。 ◆ IS...
阅读全文
摘要：以前回复一个关于9连环解法的问题,看过《计算机程序设计艺术》的人都知道，这个问题的是中国的古老游戏，其解法就是“格雷二进制”的描述。九连环是一种传统的中国玩具，它有九个连在一起的环河一根长棒组成。一开始，九个环都装在榜上，由于其特殊的构造，只能按以下规则从棒上取下或装上环： 1）所有环只能从棒的一端...
阅读全文
摘要：任何在项目伊始就规划所有的可能需求之企图都会落败，并以客观的延误告终。-Pahl,Beitz 《Engineering Design》关于需求：项目伊始，有多少需求是有技术人员参与的？有多少需求是市场人员提供的？。。。 现实中，大部分此类需求只是客户那边的管理层，各自为阵提出自己的想法。而这些想法很...
阅读全文
摘要：Wiston Royce，瀑布模型的提出人，他提出瀑布模型的本意就是用来批判的，但是现实和他闹了个笑话，多少年了大量的设计师把它奉为圣典。更加可恶的是，我们的教科书上曾经也把他视为珍宝，这些教育工作者，叫兽砖家们，该醒醒了 。。。：）理性模型强调在设计的第一阶段就是把需求的内容以完整的设计树来表达，...
阅读全文
摘要：理性模型 最原始也是最符合设计师第一感觉的设计方式，因为理性，所以叫理性模型：）； 设计的理论即一般的搜索理论,对象是巨大的组合空间.目标: 某人想要建立一个海滨小屋,以享用面向大海的一块海滨场地的海浪.必要条件: 海滨小屋应该足够兼顾以抵御飓风; 具备至少14个人躺卧和就座的空间; 为宾客提供令人...
阅读全文
摘要：4.9 在实现语义约束时,最好根据类定义来实现。但是这经常会导致泛滥成灾的类，在这种情况下约束应当在类的行为中实现，通常在类的构造函数中实现，但不是必须如此。 还是以汽车为例,我们看汽车的定义,为了集中注意力,先只关心汽车的发动机[csharp] view plaincopyprint?class汽...
阅读全文
摘要：4.7 类包含的对象数目不应当超过开发者短期记忆数量,这个数目通常应该是6左右4.8 让系统在窄而深的包含体系中垂直分布 假设有如下两份菜单: 正餐 --->甜瓜 --->牛排 --->土豆 --->豌豆 --->玉米 --->馅饼或者 正餐 --->甜瓜 --->牛排套餐...
阅读全文
摘要：4.6 尽量让类中定义的每个方法尽可能多地使用包含的对象（即数据成员）这其实就是高内聚的翻版强调。如果每个类的情况并非如此，那很可能是这一个类表示了两个或更多的概念，记住一个类只应该表示一个概念。 最明显的情况就是类的一半方法使用了一半的数据成员，而另一半方法使用了另一半的数据成员，那么这个类就应该...
阅读全文
摘要：4.5 如果类包含另一个类的对象,那么包含类应当向被包含的对象发送消息（调用方法）。也就是说，所有的包含关系都应当是使用关系。如果不是这样，那么包含的类有什么用处呢？当然，面向过程的开发人员会想到可能有一个Get方法供其它类使用这个包含的对象，那么按照“数据隐藏原则”，为什么 不让使用包含类的类直接...
阅读全文
摘要：4.1 尽量减少类的协作的数量,即减少使用者和被使用者的数量。 协作意味着一定程度的耦合，但是完全没有协作的类也是没有意义的，最多只能作为一个库使用。 通过抽象，依赖接口，可以最大程度减少依赖的实现类，对使用者来说，只看到接口的依赖，而具体的实现的依赖可以通后后期绑定来配置依赖关系。 如 菜单 --...
阅读全文
摘要：使用关系对象A的方法MethodA使用了B的方法MethodB,则表示A对B存在使用关系 使用关系的最关键问题在于,A如何找到B,存在6种方案方案一: A包含了B,B作为一个成员定义在A的类中,那么在MethodA中可以直接调用B.MethodB() 如汽车可以包含车轮。 如果汽车需要加油，那么就需...
阅读全文
摘要：3.7 从设计中取出不需要的类 只有Get/Set方法的类不算是一个必要的类,Get/Set方法也不算是有意义的行为。这种类降级为属性更加合适。3.8 去除系统外部的类 如果一个类只调用系统领域的方法，而系统没有向该类调用，则可以认为这个类并不属于系统。可能只是系统的使用者，我们没必要去为此建模。 ...
阅读全文
摘要：面向过程的软件开发通过非常集中化的控制机制来分解功能,在程序设计中表现就是大量的条件判断,深层次的循环嵌套等。这种模式下，我们可以通过分析方法的参数，局部变量及其访问的全局变量来得到方法对数据的依赖性，但是我们只有分析整个项目代码才能得到数据对方法的依赖性。 面向对象的软件开发主要关注在非常分布的环...
阅读全文
摘要：一,继承只应被用来为特化层次结构建模 实际上也就是要满足LSP原则,水果类<-榴莲的继承是特化二,派生类必须知道他们的基类,基类不应当知道他们的派生类 复用的前提三,基类中的所有数据都应该是私有的,不要使用保护数据(方法不在此原则约束下) 数据封装，物体的重量看起来可以用一个保护数据来表达，而不是g...
阅读全文
摘要：一个对象一定会有如下4个属性: 1,它的身份标示,可能只是它在内存中的地址; 2,它的类的属性(通常是静态属性)和这些属性的值(通常是动态的); 3,它的类的行为(从实现者的角度看); 3,它的公开接口(从用户的角度看).2.1 所有数据都应该隐藏在它所在的类内部. 考虑最简单的点Point类(X,...
阅读全文
摘要：为了理解ActiveX事件的运作原理，特意做了如下实验 初试化过程：try{ CLSID clsid; HRESULT hr=::CLSIDFromProgID(L"MSWinsock.Winsock",&clsid); if(FAILED(hr)) throw "获得对象的CLSID失败...
阅读全文
摘要：为了弄清楚COM库的运行原理，特意做了这个实验： #include "stdafx.h"#include "objbase.h"#include "atlcomcli.h"#include "limits"//#include "commctrl.h"#import "msscript.ocx" n...
阅读全文
摘要：题目大概是这样的：有两个数组a[N],b[N],求构造 b[i]=a[0]*a[1]*a[2]*...a[N-1]/a[i], 要求：1、不能使用除法。2、空间复杂度O(1),时间复杂度O(n)。3、除循环计数器和a[N]、b[N],不能使用其他变量。 个人看法: 与N有关，又要求空间复杂度O(1)...
阅读全文
摘要：DH 请教下大家一个设计模式的问题 业务： 有多种短信指令，系统会根据接收到的指令进行相应的业务处理，处理完成后，系统会回复一条短信 这种业务处理，可以用哪个设计模式来做？ QX 状态模式 DH 小雪，短信指令可能会增加，也可能会减少 QB 命令模式 DH 用命令模式更合适？ QB 命令模式看起来挺奇怪的。 QB interface ICommand{IComm...
阅读全文
摘要：TY 用策略就是动态改变对象的方法了怎么还要有访问者的出现 有点晕 STST 策略所改变的同一性质的方法的不同实现,如记录日志,策略1记录在文本文件,策略2记录在Access文件里 ,......访问者则改变的是完全没有相似点的方法,如一个是打印,一个统计,一个是邮件通知 访问者要求对象的结构稳定,变化的是行为 结构稳定,就是指被访问者对象的类继承层次是稳定的,不会经常变化...
阅读全文
摘要：CZ 匠友们，请教一个细节问题： 在一张表里，有一个字段"图件类型"，包括 "平面图，柱状图，统计图",我现在是将该字段设计为 varchar 类型，直接存放类型名称。 现在有同事建议，应该设计为interger类型，然后定义一个枚举变量， enum MapType{AllMapType=0,Plane=1,Histogram,Cartogram};理由是， 1）这样查询的效率高。 2）避免使用...
阅读全文
摘要：HZ 动态代理学了 不知道在工作中杂用哦 HE 现在一般不会直接用吧，一般都是用aspectJ这种完整aop的实现 STST 拦截方法调用 HZ 我见过把所有accessor方法放到切面的 还有transaction肯定都是在切面的 STST 比如一个方法,记录要保存起来用来验证用户名密码,如果不拦截的话就要如下处理bool Valid(string ...
阅读全文
摘要："设计模式，需要则用之，否则为了设计模式而设计模式反而不好，我们前段时间，大量的删除由于设计模式多出来的类和方法",一哥们这么说 关于这个,我认为: 为了设计模式而模式，肯定是不行的，基本上所有的模式都是用复杂性换取代码的其他属性（可维护性，灵活性等）使用了模式的代码肯定比平铺直叙的代码要复杂，但是带来了其他方面的好处，所以设计的时候应该先按照平铺直叙的方式设计，然后遇到重复的问题后回...
阅读全文
摘要：今天,和一哥们讨论到简单工厂,正好我也对此关注了很长时间,所以有感而发,写点东西,供以后回味这段历史。 简单工厂的用途在现代语言(具有运行时强类型系统支持的语言,如Java,.Net),确实用途不大,感觉不到想起他模式一样重要,但是在不具备运行时强类型系统支持的语言(如C/C++等,C++具有编译时的强类型,运行时没有),这是一个极其重要的模式。 比如一个简单的...
阅读全文
摘要：设计:抽象共同点,封装不同点模式:实现设计的手法语言:实现模式的载体不要一开始就进行模式套用,这样只会带来复杂性,而很少会带来好处,在重构过程中应用模式才有说服力!
阅读全文
摘要：HB：真正人才是几个层面的人才：1. 思维层面：他本身的思维方式就是高端的，这种思维方式导致他学习能力、解决问题能力是比别人强的。2. 技术层面：熟悉底层的东西，底层的东西变化比上层少，而对于核心的认识，导致对于新的上层技术的理解也快。有自己精通的语言可以实现自己想要的东西3. 流程层面：可以从大的...
阅读全文
摘要：STST 这一点我有话要说,不吐不快 1,没有什么"单纯地看测试一说" 2,销售额和利润暂时不说,进度这里,测试的好处就是保证好的进度,而不是"想当然"的认为测试占用了时间,而导致进度慢,实际经验中证明恰恰相反,"猴子一样乱弹琴的测试"除外 3,测试带来好的进度,好的质量,难道不会影响到销售额和利润? FN 现在的敏捷不就是将涉及研发进度的测试都交给开发人员完成了吗？ STST 深层次...
阅读全文
摘要：我刚在.Net下做了测试,对于尾递归,在Debug模式下,不会被优化为非递归结构,在Release模式下,会被优化为非递归结构,就不存在栈溢出的问题了 STST 这是我模拟的文件结构类 STST 这是非尾递归版本 STST 这是尾递归版本 STST 这是测试代码 STST 这是CreateDir的定义 STST 结果: 1,在Debug模式下,无论是不适尾递归,...
阅读全文
摘要：今天与人再次聊到这个话题,有人在为"到底该用什么模式"而烦恼,我相信,每个都经历过这个阶段一定都会感觉很熟悉这个烦恼我认为,模式不是目的,只是工具,达到设计目标的工具,我们不会因为"为了使用锤子"而去"使用锤子",一定是因为其他目的"比如敲打钉子"而去"使用锤子".我们应该也同样不要因为"想用那个模...
阅读全文
摘要：软件工程，模式，语言，设计思想发展到今天，说白了，所有的技巧，思想，原则归根结底都是为了这个DRY 从机器语言开始:为了DRY，出现了汇编符号来代表指令，使开发人员不用“重复翻阅指令手册”为了DRY，出现了宏汇编，来使开发人员不用“重复编写同一个过程”为了DRY，出现了C，Fortran等，使开发人...
阅读全文
摘要：今天,WC的时候,突然间理解了一个一直很模糊的概念就是:强类型,弱类型,静态类型,动态类型到底具体指什么意思,哈哈,太有成就感了强类型:运行时检查目标地址的对象是不是预期的类型,如.Net,Java等弱类型:运行时没有类型的概念,只有地址的概念,如汇编,C等静态类型:对象的"多态"在编译时决定,编译...
阅读全文
摘要：Fizz-Buzz-Whizz问题描述：1. 你首先说出三个不同的特殊数，要求必须是个位数，比如3、5、7。2. 让所有学生拍成一队，然后按顺序报数。 3. 学生报数时，如果所报数字是第一个特殊数（3）的倍数，那么不能说该数字，而要说Fizz；如果所报数字是第二个特殊数（5）的倍数，那么要说Buzz...
阅读全文
摘要：STST 昨天看到这个观点,感同身受,大家讨论下 XQ 分解成小问题：进行抽象并降低耦合性。 STST 恩,所以强调 XQ 代表这一种思维方式：复杂问题简单化。 如何把小模块组合成大系统也很见功力。 STST 当然,无论什么问题,都是如何把问题逐步求精的过程,我们学数学,物理,化学也是这样 复杂问题必须简单化以后才能求解 模块合并的关键在于,小模块之间的正交性如何,具有正交性的多个...
阅读全文
摘要：瀑布模型 : 强调整体推进与阶段划分 需求->设计->实现->...->测试->交付, 项目资源(时间人力资金等)按阶段分配 每个阶段的产出作为下个阶段的输入.迭代模型 : 强调逐个推进与功能划分 子功能1->子功能2->...->子功能N 项目资源按子功能分配 每个阶完成一部分...
阅读全文
摘要：1,在编写好失败的单元测试之前,不要编写任何产品代码 如果不先写测试,那么各个函数就会耦合在一起,最后变得无法测试 如果后写测试,你也许能对大块大块的代码进行测试,但是无法对每个函数进行测试 先写测试是进攻,后写测试是防守2,只要有一个单元测试失败了,就不要再写测试代码,编译失败也是失败 一个地方漏...
阅读全文
摘要：前几天我看到了Bob大叔关于Code Dojo(练习)的表述,获益非浅,以前我只知道这样做肯定是有用,但是说不出所以然,但是Bob一针见血地说了:Dojo就是让你通过反复的练习,使一些原来看起来高阶的抽象变成一种本能,而把脑子解放出来思考更高阶的抽象. 初学者而言,语法就很抽象,通过练习,使语法成...
阅读全文
摘要：很奇怪的一个现象，在C#中使用Process来启动进程，启动文件名必须是系统指定的扩展名.EXE,而我使用原生的Win32API ::CreateProcess()并没有这个限制，以后遇到类似的问题要注意了下面例子：com.aaa,com.exe都是同一个可执行文件，只是扩展名不一样 [TestMe...
阅读全文
摘要：接口代表的就是共同性,所谓面向接口编程,就是要抽象各种不同概念的共同点 然后把这些概念的不同点用具体的类包装起来,这样一看,面向接口编程就等于面向对象编程其实说白了是一个概念 IOC就是要把对细节的倚赖推迟到运行时,在编码期间和编译期间,完全不依赖细节 AOP就是典型的"正交性"原则指导下的应用,各...
阅读全文
摘要：【潜水】杭州-Java-佳娃@英界尔还有一个问题我现在发现一个方法调用的深度很深如何优化啊！！ 【传说】英界尔 递归的调用? 【潜水】杭州-Java-佳娃 应该这么说：有个功能，跟其他功能依赖性太强了，如何解耦，就是每次改其他的功能都有些影响这个功能。 【传说】英界尔 把你这个功能和其他功能的依赖,用单独的接口描述出来 其他的功能模块实现这个接口 比如 A-->Func1()--->B...
阅读全文
摘要：1，层次结构 复杂系统总是以层次结构的形式存在。复杂系统由一些子系统组成，子系统又由一些更小的子系统组成，如此下去，直到达到某种最低层次的基本组件。2，相对原本 如何划分子系统，选择哪些作为系统的基础组件相对来说比较随意，很大程度取决于观察者的判断。对一个观察者看来很基础（本原）的东西，对另一个观察...
阅读全文
摘要：OOA,OOD,OOP三者关系OOA的分析结果可以作为OOD的需求模型OOD的设计结果作为OOP的指导蓝图OOP负责最终实现目标系统
阅读全文
摘要：下面这一份C代码，什么样的人会写出这样的代码呢？C程序员大概不会，更有可能的是汇编程序员。 C和汇编，特别是后面的宏汇编，结构上非常相似，都是典型的过程式语言，当然没有人反对进行对象式编程，但是是做对象式编程的基础设施比较薄弱。 C和汇编，都是典型的弱类型，运行时只有地址的概念，没有类型的概念 C和汇编，都是典型的静态语言，所有的行为在编译时都已经确定，运行时不再修...
阅读全文
摘要：测试是规格(需求),而不是测试测试就是测试,而不是规格(需求)看起来很矛盾,实际上是有道理的,我一度坚持测试就是规格(需求),我还曾经因为强力坚持测试反映需求的观念和人吵翻,现在我认识到我只看到了一面.以测试通过之前作为分界点,测试呈现两种不同的状态,我们需要以两个不同的角度去审视,这是>带给我的第...
阅读全文
摘要：对静态语言而言 对象向外界承诺我有什么,客户端可以依赖这些承诺,它通过它的"类型"来承诺这一点 优点是: "它承诺了有的就一定有", 缺点是:"它没有承诺的就一定没有"对动态语言而言 从不向外界承诺我有什么,我随时会变,这会我是鸭子,过会就变成了一只鸡 优点是:"它有什么客户端就可以使用什么"缺点是...
阅读全文
摘要：最强的关系: 一般与特殊的关系,在OOP里面表现为类的继承关系第二种关系: 整体与部分的关系,花瓣不是花,但是花的一部分最弱的关系: 关联关系,老师和学生有关联关系,如果去除这层关系,则就没有了任何关系
阅读全文
摘要：AB 今天听到一朋友说,"面向对象也好 面向结构也罢,主要是减少代码冗余就可以了,不用太在乎面向对象" STST 是的,但是减少冗余不是凭空就能做到的,除了复制粘贴,还有隐藏比较深的冗余 设计模式就是提高可重用性的,没有高度的可重用性,是不可能减少荣誉的 因为这个世界上做"任何两件事",总是有相似或者相同的部分,这部分不提取出来,就是冗余 ST 相似提取不出来可以理解为不同吗 相同提不出来是冗...
阅读全文
摘要：WB Decorator装饰器模式 Intent意图：Attachadditionalresponsibilitiestoanobjectdynamically.Decoratorsprovideaflexiblealternativetosubclassingforextendingfunctio...
阅读全文
摘要：1,低耦合 低耦合的概念关系简单,可单独理解,测试等2,高聚合 最不希望完全无关的一些概念塞进一个包(包,类,方法)3,充分性是否完整由客户方验证,而不是一开始设计大而全,迭代过程中充实,接口最小化(只有客户需要的)4,完整性 接口应该尽可能反映该抽象概念(接口最大化),需要和充分性进行权衡,个人偏...
阅读全文
摘要：抽象分类很难,原因有二:1,没有所谓的完美的分类抽象(尽管某些分类比另外一些更好),如果将系统划分为对象系统,那么有多少个设计人员,可能就有多少种划分方法2,明智的分类抽象需要大量的创造性思维,只有创造性思维才能在大量无关的事物之间找到共性
阅读全文
摘要：为了概念上的完整性,系统的设计必须有一个人,最多2个人来完成,问题来了,有的人会认为,那其他人员干什么?创意都被这1-2个人垄断,剩下的实现过程就很枯燥了.实际上,经验已经表明,"没有规矩,不成方圆",最差的建筑往往是那些预算远远超标的项目,因为这些项目一开始的概念就不完整.外部的体系结构的强制性(...
阅读全文
摘要：ATM print'hello,world' CB 。。 STST char*str="Hello,World"; templatevoidPrint(){cout()Print(){cout(); WF System.out.println("HelloWorld");CB echo"helloworld!"珍爱生命，远离c++ AB 远离java STST C++很强...
阅读全文
摘要：过度定义需求和过度定义问题的解决方案,都是很危险的例如,在建筑蓝图上,建筑师可能指出房间中电灯开关的大概位置,但是要到装修的时,等布线工作完成之后,才能确定开关的准确位置,在建筑蓝图上指定电灯开关的准确三维位置是愚蠢的行为.过度定义在两个方面造成危害:第一,设计者关注于过于细节的问题,而无法把精力放...
阅读全文
摘要：好的工具能做的一件事就是使不好的设计者快速创造出糟糕的设计.卓越的设计来自卓越的设计者,而不是卓越的工具.工具只是增强了个人的能力,让设计者能专注于分析或设计中真正创造i性的方面.有一些事情,工具可以做的很好,但是有一些事情,工具根本不能做.
阅读全文
摘要：CH1 1,很多人畅谈自己就职"计算机行业","电讯行业","在线电子交易行业"时,很容易沉溺于一种假象,认为他们自己就是高科技世界里的一部分,而实际上,只有那些做基础研究,创新研究的人员才算是高科技工作者,其他人只是在运用他们的成果而已. 2,关注于具体的技术问题,是因为技术问题比非技术问题简单...
阅读全文
摘要：1,规定对天才来说多余,对蠢才来说无效,只对中间这一部分有用(我至今没见到过天才,蠢才到是不少) 2,设计上顿悟的火花一闪而过,没有规律可循.良好的测试无法保证你在需要的时候灵感乍现,但是给人信心的良好测试和精心重构过的代码可以给你随时闪现的灵感做好迎接的准备,以便灵感一旦到来,你就能抓住她. 3,...
阅读全文
摘要：1,隔2个月回头看自己的设计,如果感觉不好理解,那么意味着当初设计的很不合理,是需要重新设计的前兆2,快速设计实现的诱惑很大，一刻不提醒自己严格按照TDD的原则来行事，就导致复杂难以理解的设计3,难怪Kent Benck经常提醒自己，红-绿-红编码节奏，一旦脱离这个节奏，就容易被快速设计的诱惑俘虏，结果就是生产出复杂难以理解的设计4,有人说:"考虑市场和成本,这个模块将就用吧,没有时间重新...
阅读全文
摘要：STST 这个想法认同吗？ QX 我觉得很认同 YF 赞成，但考虑重新设计要成本，特别是机会成本 QX 另外我觉得很多设计有历史局限性,当时够用，但是随着业务发展，就会不够用 STST 快速编码的诱惑很大，一刻不提醒自己严格按照TDD的原则来行事，就导致复杂难以理解的设计 QX 就是自然感受,觉得该重构了就重构,这是迭代的过程 WB 设计与实现一样，也需要不断重构，去除腐臭，持续演进。 ST...
阅读全文
摘要：JK 多线程调试，调试起来得有点多线程基础,要不然真心难弄,有多线程基础都难搞,别说那些没有多线程基础的人了 STST 一般情况下,不要使用多任务，如果需要多任务,首选多进程，多进程无法满足,最好选一个函数式语言完成多任务 无法自选语言完成任务的话,就先把线程同步机制彻底弄明白,再来动手 有没有人来一起讨论下这个话题? LD 我相信测试，多线程性能问题测试才能说明问题 STST 测试在多任...
阅读全文
摘要：HD大家遇没遇到过这种情况， 有一个类，里面有ABCD四个属性，同时有方法1设置AC的值，方法2设置D的值，方法3计算B的值，通过ACD三个属性。这种代码感觉维护性不高，有什么好的处理方式吗,感觉这堆属性跟一堆全局变量没啥区别 STST 这是内聚性低的特点 HD 但是我的属性都内聚到一个类了啊 STST 呵呵，这不是内聚的意思 HD 恩，能给稍微讲讲吗 STST 用你这个做例子的话 HD ...
阅读全文
摘要：STST 如果软件只考虑第一次交付的话，不考虑后面的变更维护，自动化什么的确实没用，但是这种理想情况存在的概率有多大？ H 自动化是为了发现问题？ BS 我觉得有这个目标 STST 自动化本质上就是用来让将人的精力从重复性的工作中解放出来 STST "自动化是为了发现问题？"这个是不可能的，发现问题的是人 HL我觉得。。。@英界尔说的是具体问题而@BlackSwan和我...
阅读全文
摘要：要点1CodeDomProviderMSDN描述CodeDomProvider可用于创建和检索代码生成器和代码编译器的实例。代码生成器可用于以特定的语言生成代码，而代码编译器可用于将代码编译为程序集。注意：在 .NET Framework 2.0版中，在代码生成器和代码编译器中可用的方法可直接从代码...
阅读全文
摘要：在《人月神话》中，布鲁克斯老先生将维护软件的" 概念完整性" 作为软件开发的核心问题。软件之所以很复杂、难以维护，根本原因就在于软件的概念完整性遭到了破坏，甚至开发团队的成员从来就没有意识到有必要去维护软件的概念完整性，他们并不是一个真正的团队，只是一些自行其事的开发人员，碰巧在一个团队中一起堆代码而已。代码的质量如果不加以控制，就一定会迅速腐烂变质。这是一个客观规律，就像在热力学第三定律...
阅读全文
摘要：深入理解领域的开发人员，即使使用过时技术所开发出来的软件，也远远好过完全不理解领域的开发人员，使用最时髦技术所开发出来的软件.---DDD Quikly
阅读全文
摘要：在项目开发最初的时候，他也有过一段狂欢般的快乐时光，不久之后，事情就越来越艰难。项目的代码越来越难以维护，工作越来越像是一种煎熬，合作的同事对他越来越不满。" 该是与这个项目，与这个公司说 bye bye 的时候了" ，他想。他换了一家公司，涨了一点工资，开始了另一段狂欢。周而复始，一年又一年过去了。随着年龄的增长，他不再能够从软件开发中享受到乐趣，软件开发的职业生涯，对于他而言痛苦...
阅读全文
摘要：STST 初级工需要大量的素材进行归纳,以提升自身的知识,这阶段需要大量的重复性的简单的工作 高级工主要通过演绎来思考,在实际中应用知识,高级工思考的时间占的比例更多一些 这个想法大家觉得认可吗?刚跟别人聊天时想到的 HL 成天演（bu）绎（yong）思（gan）考（huo）的高级工肯定认同 DH 高级工因为效率高因此有更多的时间来思考而已吧。。 HX 演绎思考是什么 不论是否演绎思考，思...
阅读全文
摘要：新的编程语言、新的开发框架层出不穷，让开发人员疲于跟随。以有涯之人生，去追随无涯的技术变迁，实在是一件很痛苦的事情.---DDD quikly所谓的新技术,都是新瓶装旧酒而已,你不学习,就永远被牵着鼻子走.如果你善于学习,最终的主动权在你在这里,你会发现其实技术没有什么变化,原来旧技术要做的3件事,采用新技术也还是3件事,只不过锤子感觉顺手一点而已
阅读全文
摘要："设计人员做好设计，结果交给编码人员，由编码人员实现"，这看起来很好！这种方法中存在的一个主要的问题是分析无法预见模型中存在的某些缺陷以及领域中的所有的复杂性。分析人员可能会过多深入到模型中某些组件的细节，但其他的部分却缺乏足够的细节。 非常重要的细节直到设计和实现过程才被发现。 瀑布设计方法，业务专家=提出=〉需求=>业务分析人员=创建=〉设计模型==〉开发人员=〉编码。在这个方...
阅读全文
摘要："银行业软件肯定会跟踪客户的住址，但它决不会关心客户的眼睛是什么颜色的。"要保留哪些内容放弃哪些内容呢？ 这些取舍是设计和软件创建过程的一部分。 ------DDD Quikly 选择性忽略吧!不要尝试对概念进行全方位的建模,那是一个无底洞,而且不会带来好处,反而带来坏处,一个拥有1000个方法的列表类肯定会被只有10个方法的列表类打败. 永远紧盯你的主要目标,不断...
阅读全文
摘要：最好能让应用中的领域部分与其余部分相比保持尽可能小（ 而不是和其余部分掺杂在一起），因为一个典型的应用包含了大量访问数据库、 访问文件或网络、 用户界面等相关的代码，而业务逻辑经常被嵌入到 UI 组件和数据库脚本的行为中，之所以经常这样做，原 因是这样可以很容易地让事情快速工作起来（挑动了多少人的神经啊）。 当领域相关的代码被混入到其他层时，要阅读和思考这...
阅读全文
摘要：1，如果设计或者设计中的核心部分没有映射到领域模型，模型就没有什么价值，而软件是否正确也就令人怀疑。 2，模型和设计功能之间的映射如果很复杂，就会很难理解 ，当设计变更了实际上模型是不可能维护的。（分析产生的）领域模型和（对领域模型的）设计之间如果出现了致命的分歧，这 样一个活动（ 分析或设计） 中产生的想法将无法对另外一个产生好的影响。 从...
阅读全文
摘要：很多问题,一开始你就不知道要干什么?一个模糊的需求介绍,概念是什么都不知道,这时候谈什么完整性,因为概念的完整性,最核心的是从根需求一直细化到最底层的叶子需求. 很多时候,开始你无法得到根的概念,客户也是零零散散的描述,这时候无所谓完整性,把每个小巧"用户故事"一个一个地实现,展示给用户,慢慢地会形成一个模糊的大概需求,这时候对需求的概念开始有了整体化(当然这个阶段可...
阅读全文
摘要：重构是小幅度进行的，其结果也必然是一系列小的改进。 有时，会有很多次小的变更 ，给设计增加的价值很小，有时，会有很少的变更，但却会造成很大的差异。 这就是突破。 ------DDD Q...
阅读全文
摘要：终于明白了,有时候不得不写一些晦涩难懂的代码,其实都是因为分析时漏掉了一些深层次的概念才导致的,缺少概念,就必然导致用一些复杂的操作去弥补 比如,一个付款的业务,你现有的概念是银行账户,目标账户,和一些验证机制,如果没有发掘一个位于这些概念之上的高层概念,就会导致你的账户具有一个复杂的方法(当然也可能是目标账户),这个方法负责验证,付款,收款等,而从业务领域的视...
阅读全文
摘要：有很多类型的内聚性。 最常用到的两个是通信性内聚（ communicational cohesion） 和 功能性内聚（ functional cohesion）。在模块中的部件操作相同的数据时，可以得到通信性内聚。 把 它们分到一组很有意义，因为它们之间存在很强的关联性。 在模块中的部件协同工作以完成定义好的任务时，可以得到功能性内聚。 功能性内聚被认为是最佳的内聚类型。...
阅读全文
摘要：一个大型的复杂项目而言，模型趋向于越来越大。 当模型发展到了某个规模，将 它作为整体来讨论很困难，理解不同部件之间的关系和交互变得很困难。 因此,强化不变量通常也是有必要的。 不变量是在数据发生变化时必须维护的那些规则。 在许多对象持有正在发生变化的数据对象的引用时，不变量是很难实现和维护的。使用 根对象可能会将内部对象的临时引用传递给外部对象，作为限...
阅读全文
摘要：一方面,脱离了模型的设计会导致软件无法真实表达它所服务的领域，很可能会得不到期望的行为。另一方面,建立模型的过程如果得不到设计的反馈或者缺少了开发人员的参与，会导致必须实现模型的人很难理解它，并且对于所用的技术而言可能不太适合....
阅读全文
摘要：最近,应航天系统登月部门的测试需求,成功模仿CPU的流水线原理做出设计,满足了对方的需求,感觉真的很爽,终于再次验证了,知识都是相通的,立竿见影的绚丽技巧性的知识都很肤浅,潜移默化的平淡基础性的知识都很王道,看来以后我得加强数学方面的学习了,目前这是一个短板,不知道大学时为什么突然不想学数学了,真的很遗憾! 流水线设计,总线设计,真的很酷,虽然看不到,但是却是很酷!
阅读全文
摘要：WZ 架构师这东西。。我司的架构师是属于啥都做的但是不参与具体的功能开发STST 不做具体的,意味着空得很 DH 做技术选型啦性能优化啊安全专项啊之类的 STST 我不相信,不做具体的,能把设计做好 DH 那是因为做过很多年具体的了 没见过刚毕业进来就挂个架构师头衔的 STST 不做具体的,就得不到具体的反馈,得不到反馈,就无法确认设计没问题 做多少年也一样,这行业没有完全一样的设计,...
阅读全文
摘要：MS STST 这难度太高了 有一个就很难的了 也许我工作的环境一般,能把SOLID简要描述一下的,都还没有遇到 SOLID还只属于OOD层次,OOA层面就更加没碰到了 Scrip 因为领域驱动设计的大神比较多 MS 用的人不多吧 A 可能是会用的人不多吧 MS 是啊，大项目也没法用吧，要协调的东西太多 STST 全世界软件工程发展到现在,OOX应该是最核心的一块了吧 ，还要Gre...
阅读全文
摘要：一个偶然的机会,调试一段多年前的程序,那段程序有一套自动化的测试,但是经过多人易手,变化已经比较大了,测试已经无法通过,那么我的切入点就放在了这些测试里面. 这是一段带界面操作的程序,目标是测试一个矢量图形控件,这个例子里我关心的大致功能接口如下: 1, PlaceTestingSystem(.....
阅读全文
摘要：MZK 原型模式就是拷贝构造吗 STST NO 模式不要和语法混在一起 MZK 此话怎讲 可以说c++中的深拷贝是原型模式的一个实例吗 STST 不是 拷贝构造是C++里面定义的一个语法而已 拷贝构造没有向用户隔离构造过程 原型模式隔离了 MZK 原型模式和ctrl+cctrl+v不是一个意思吗 STST 运行时候的ctrl+cctrl+v是太正常了 设计的时候ctrl+cctrl...
阅读全文
摘要：1，向敏捷转变的过程是一个很容易出乱子的过程，尤其对项目的领导力来说。在实施敏捷的过程中，会突然释放出一些有用的信息，将原来隐蔽起来的真相推倒聚光灯下。 2，假如执行者忽略了技术实践（比如测试驱动开发,重构，持续集成等），代码基础很容易被缺乏经验的开发人员搞坏，这时候，任何开发过程都无法自动修复。3...
阅读全文
摘要：CRS 如果功能复杂的情况下,是不是先写验收测试,然后写单元测试,最后写代码? STST 是的 从高往低走，无论是分析，还是测试，还是开发 从高往低走，带来的是干净无累赘的，底层依赖高层的优雅的结果 CRS 那模式是否1.先写feature2.实现自动化验收测试3.再写view层的ut(事实上view层的ut咋写?基本没法写啊..)4.实现view层(写死)5.实现contro...
阅读全文
摘要：最近总结了有一个现象:很多人喜欢用钳子干扳手的活,然后就坚信钳子是通用的,扳手应该是特殊的钳子,特别是对那些还在从底层开始设计的人来说,尤其突出,他们喜欢追求"通用"却不明白,通用应该从实现中提取,而不是来自于"设计"
阅读全文
摘要：STST 重复是软件最大的敌人,而复制粘贴是最最基础的重复 LF 软件可复用的 STST 通过复制粘贴来复用? HZ 软件可(粘帖)复制的 STST 从哪本书上看到有这样介绍的? 先分清下,这里的复制粘贴,不针对软件开发的结果(可直接发布的内容),而是指源代码层面的复制粘贴 STST 呵呵,把写代码的工作量当成软件开发过程的全部的话,复制粘贴有可能如你所说,能提高效率 C 哈哈哈，都这样啊。简便，...
阅读全文
摘要：躺了一会,回忆以前看过的一些描述"原本"的知识,突然想到简单的数学运算1+1=2,在程序设计里的原本是什么呢,想到这里,不睡了,按照前人的指引,我也来探索一下阿（以下代码使用C#4.0，未使用LINQ，其他语言可以找对应的语法） 直接写下最直接的代码如下这就是1+1=2,没错!这个子程序很具体,...
阅读全文
摘要：STST 想和大家讨论一下,一个测试用例里只做一个断言还是一个用例里做多个相关的断言 比如有一个查询函数Query(id)返回[姓名,性别,年龄] 那么是在一个测试用例里对这三个属性进行断言好? 还是在三个测试用例里,对每个属性进行断言好? HZ 三个检查一个用例 你是希望有10个问题每次告诉你一个人折腾10次还是一次告诉你10个折腾1次 STST 哦,但是我发现分开写,表达力更强 你说的"折腾...
阅读全文
摘要：有人想要在房顶加盖两层,施工人员经过仔细分析,得出结论,说目前加不了,要考虑先对地基进行改造以后才可行,甲方不认,说要你加就加,这就是执行力,这是执行力吗? 如果施工方不坚持己见,这不但不是执行力,而且还是极不负责的行为. 对"快速修复"坚决说不,更多的是一种能力和责任,没有能力,无法自我判断快速目标的性质到底是陷阱还是荣耀,没有责任,就会人云亦云,不坚持主见.
阅读全文
摘要：我前段时间和几个童鞋侃测试的话题,我的意思是,测试无论你用QTP,LR..,甚至是手工去操作,这些都不是核心,核心是理解测试的需求,整理测试用例,这才是核心中的核心,是测试工作中的创造性地工作,这部分创造好了,就是如何去实现测试,这就用上了前面提到的(QTP,LR...手工),这个过程实际上就是把测试需求映射到工具上的过程,这部分就比较好办了
阅读全文
摘要：绝大部分的程序员都喜欢沉浸在底层开发中,在这里受人员,社交等因素的影响小,而这不正是程序员所梦寐以求的吗? 在这里,可以按照自己的理解,"勤奋"地写代码,信心十足,一日千行甚至更多,如同行云流水... 在这里,可以考虑各种将来"可能遇到"的情况,尽情打造心中完美的需求世界... …… 但是,别忘了,你的理解并非真实世界的概念,而很可能只是自己的臆想,你考虑的千百种可能只有一两种会碰到,甚至没有...
阅读全文
摘要：LJ 实际的测试项目，做起来才是头疼 咱们的工具能不能在实际的项目里减轻测试人员的工作量，才是问题的关键 怎么体现工具的价值啊 LJ 我跟你说我的两个观点： 第一，作为产品，需求设计是第一位的，功能不好，没办法让人用。 第二，作为公司的管理人员，应该使用的是结果导向的方法 LJ 对下属的要求，应该是具体明确的,可度量的LJ 这个观点供你参考吧 STST 嗯,非常好 STST 有一个问...
阅读全文
摘要：TQ 一个类的析构函数调用完毕之后这个程序还会做什么？直接结束吗？大家怎么看待这个问题呢？ CD c++类析构跟程序退出没关系 应该是说调用这个类完毕之后还会执行该类中相关信息吗？TQ 直接结束？？？？？？？？ STST 这个概念好混乱阿 类如何能调用完毕? 类,对象,方法这得关系都没理顺啊 类是一个静态的概念,与实践无关,和来"开始""结束"？ 对象是一个空间的概...
阅读全文
摘要：CZ 能不能清晰具体区分service和实体的区别 网上有人用DCI来解决不知道对不对 STST 我复习下DDD中的服务的概念了参与讨论啊CZ 这个我也看过但是太过于笼统 STST STST 复习了一遍,我是这么理解的 STST 假设一个道路模拟系统,里面有两个重要概念,汽车,加油站 汽车有一个职责叫:void加油(intcapacity) 加油站有一个职责叫:int供油(...
阅读全文
摘要：有一种说法 : 开发经理不写代码 系统架构师不写代码 高级程序员不写代码 个人认为: 到了一定境界的程序员，代码是最基本的最基本的构造快，这时候不会去注意到代码本身，不代表他不写代码，只是不拿代码来说事。 就如同走路对你来说已经是最基本的最基本的功能，这时候你也不会去注意走路本身（先左脚还是先右脚。。。）,但不代表你不走路,只是不关心走路本身,而只会关心目的地，但这不能说你到了这个境界了就不走路了...
阅读全文
摘要：LJ "但是有时候过度考虑技术，考虑维护性扩展性，而不考虑商业问题，也是不行的 STST 其实我认为的迭代方法，早就摈弃了这种过度考虑 迭代方法论强调做好现在，让现在的状态良好，需要扩展的时候才去扩展，而不提前考虑 因为保证任何时刻的状态都很好，所以需要扩展的时候也不心虚，正常重构就行 LJ 是的，不过很多程序员都有完美强迫症的 STST 从我个人的经历体验来说的话，这种追求"完美强迫"的欲望，来...
阅读全文
摘要：状态机 在理解状态机之前，总是把状态里简单地理解为状态模式，最近，我仔细分析了状态机的实现机制，发现状态机和状态模式还是有很大的不同。 一，状态模式是具体的，针对每个需求有一个状态集，并为其实现特有的迁移机制。状态机是抽象的，不是针对特定的需求，而是对各种与相关的问题的进一步抽象，那么用状态机回...
阅读全文
摘要：TQ： 有如下定义： Class 鸟{。。。；public virtual void Fly(){};。。。} Class 麻雀{。。。；public virtual void Fly(){...};。。。} Class 大雁{。。。；public virtual void Fly(){...};。。。} 。。。。。。 如果是鸵鸟不能飞，就在飞的方法里抛出异常。。。异常不能算是一种正常编程逻...
阅读全文
摘要：抽象理论很重要，理解了这些抽象理论，可以轻松面对各种变化，从这个方向看，不能停留在具体的应用技术上但是抽象理论也不是建立在空中楼阁之上的，必须要做大量的具体的练习，才有理解这些抽象的基础能力，从这个方向看又必须从具体的技术应用上能从交流中理解抽象理论，说明在练习的这一层已经过关了只是缺乏最后的突破，这种突破一般都具有偶然性，要不从书上，要不从交流，当然也有极少数是自身的灵感爆发总结出来的 其...
阅读全文
摘要：单派与多派 (Single Dispatch and Multi Dispatch)"检查一个数据项的类型，并据此去调用某个适当的过程称为基于类型的分派"。 上面是来自《计算机程序的解释与构造》的一段话，今日有幸读到。对于Dispatch这个词，我第一次接触，是来自Com/DCom年代的自动化接口（...
阅读全文
摘要：当下时代，各种时髦技术层出不穷，尤其是IT行业，引领各种技术前沿，各种华丽的软件技术则是日新月异，让人无暇迎接，对于新入行的学徒而言更是如此。引用别人的一句话：用有穷的精力，去迎接无穷的变化，何苦呢 ！ 你会发现永远都被牵着鼻子走，而且永远慢半拍，所以在面对这些层出不穷的技术的过程中，千万不要被蒙...
阅读全文
