摘要：
HD大家遇没遇到过这种情况， 有一个类，里面有ABCD四个属性，同时有方法1设置AC的值，方法2设置D的值，方法3计算B的值，通过ACD三个属性。这种代码感觉维护性不高，有什么好的处理方式吗,感觉这堆属性跟一堆全局变量没啥区别 STST 这是内聚性低的特点 HD 但是我的属性都内聚到一个类了啊 STST 呵呵，这不是内聚的意思 HD 恩，能给稍微讲讲吗 STST 用你这个做例子的话 HD ... 阅读全文
posted @ 2015-10-23 23:03
赛提斯特
阅读(209)
评论(0)
推荐(0)
摘要：
STST 如果软件只考虑第一次交付的话，不考虑后面的变更维护，自动化什么的确实没用，但是这种理想情况存在的概率有多大？ H 自动化是为了发现问题？ BS 我觉得有这个目标 STST 自动化本质上就是用来让将人的精力从重复性的工作中解放出来 STST "自动化是为了发现问题？"这个是不可能的，发现问题的是人 HL我觉得。。。@英界尔说的是具体问题而@BlackSwan和我... 阅读全文
posted @ 2015-10-23 22:55
赛提斯特
阅读(744)
评论(0)
推荐(0)
摘要：
要点1CodeDomProviderMSDN描述CodeDomProvider可用于创建和检索代码生成器和代码编译器的实例。代码生成器可用于以特定的语言生成代码，而代码编译器可用于将代码编译为程序集。注意：在 .NET Framework 2.0版中，在代码生成器和代码编译器中可用的方法可直接从代码... 阅读全文
posted @ 2015-10-23 22:11
赛提斯特
阅读(1785)
评论(0)
推荐(0)
摘要：
在《人月神话》中，布鲁克斯老先生将维护软件的" 概念完整性" 作为软件开发的核心问题。软件之所以很复杂、难以维护，根本原因就在于软件的概念完整性遭到了破坏，甚至开发团队的成员从来就没有意识到有必要去维护软件的概念完整性，他们并不是一个真正的团队，只是一些自行其事的开发人员，碰巧在一个团队中一起堆代码而已。代码的质量如果不加以控制，就一定会迅速腐烂变质。这是一个客观规律，就像在热力学第三定律... 阅读全文
posted @ 2015-10-23 20:18
赛提斯特
阅读(314)
评论(0)
推荐(0)
摘要：
深入理解领域的开发人员，即使使用过时技术所开发出来的软件，也远远好过完全不理解领域的开发人员，使用最时髦技术所开发出来的软件.---DDD Quikly 阅读全文
posted @ 2015-10-23 20:18
赛提斯特
阅读(380)
评论(0)
推荐(0)
摘要：
在项目开发最初的时候，他也有过一段狂欢般的快乐时光，不久之后，事情就越来越艰难。项目的代码越来越难以维护，工作越来越像是一种煎熬，合作的同事对他越来越不满。" 该是与这个项目，与这个公司说 bye bye 的时候了" ，他想。他换了一家公司，涨了一点工资，开始了另一段狂欢。周而复始，一年又一年过去了。随着年龄的增长，他不再能够从软件开发中享受到乐趣，软件开发的职业生涯，对于他而言痛苦... 阅读全文
posted @ 2015-10-23 20:17
赛提斯特
阅读(138)
评论(0)
推荐(0)
摘要：
STST 初级工需要大量的素材进行归纳,以提升自身的知识,这阶段需要大量的重复性的简单的工作 高级工主要通过演绎来思考,在实际中应用知识,高级工思考的时间占的比例更多一些 这个想法大家觉得认可吗?刚跟别人聊天时想到的 HL 成天演（bu）绎（yong）思（gan）考（huo）的高级工肯定认同 DH 高级工因为效率高因此有更多的时间来思考而已吧。。 HX 演绎思考是什么 不论是否演绎思考，思... 阅读全文
posted @ 2015-10-23 20:16
赛提斯特
阅读(442)
评论(0)
推荐(0)
摘要：
新的编程语言、新的开发框架层出不穷，让开发人员疲于跟随。以有涯之人生，去追随无涯的技术变迁，实在是一件很痛苦的事情.---DDD quikly所谓的新技术,都是新瓶装旧酒而已,你不学习,就永远被牵着鼻子走.如果你善于学习,最终的主动权在你在这里,你会发现其实技术没有什么变化,原来旧技术要做的3件事,采用新技术也还是3件事,只不过锤子感觉顺手一点而已 阅读全文
posted @ 2015-10-23 20:16
赛提斯特
阅读(167)
评论(0)
推荐(0)
摘要：
"设计人员做好设计，结果交给编码人员，由编码人员实现"，这看起来很好！这种方法中存在的一个主要的问题是分析无法预见模型中存在的某些缺陷以及领域中的所有的复杂性。分析人员可能会过多深入到模型中某些组件的细节，但其他的部分却缺乏足够的细节。 非常重要的细节直到设计和实现过程才被发现。 瀑布设计方法，业务专家=提出=〉需求=>业务分析人员=创建=〉设计模型==〉开发人员=〉编码。在这个方... 阅读全文
posted @ 2015-10-23 20:03
赛提斯特
阅读(530)
评论(0)
推荐(0)
摘要：
"银行业软件肯定会跟踪客户的住址，但它决不会关心客户的眼睛是什么颜色的。"要保留哪些内容放弃哪些内容呢？ 这些取舍是设计和软件创建过程的一部分。 ------DDD Quikly 选择性忽略吧!不要尝试对概念进行全方位的建模,那是一个无底洞,而且不会带来好处,反而带来坏处,一个拥有1000个方法的列表类肯定会被只有10个方法的列表类打败. 永远紧盯你的主要目标,不断... 阅读全文
posted @ 2015-10-23 20:03
赛提斯特
阅读(121)
评论(0)
推荐(0)
摘要：
最好能让应用中的领域部分与其余部分相比保持尽可能小（ 而不是和其余部分掺杂在一起），因为一个典型的应用包含了大量访问数据库、 访问文件或网络、 用户界面等相关的代码，而业务逻辑经常被嵌入到 UI 组件和数据库脚本的行为中，之所以经常这样做，原 因是这样可以很容易地让事情快速工作起来（挑动了多少人的神经啊）。 当领域相关的代码被混入到其他层时，要阅读和思考这... 阅读全文
posted @ 2015-10-23 20:02
赛提斯特
阅读(145)
评论(0)
推荐(0)
摘要：
1，如果设计或者设计中的核心部分没有映射到领域模型，模型就没有什么价值，而软件是否正确也就令人怀疑。 2，模型和设计功能之间的映射如果很复杂，就会很难理解 ，当设计变更了实际上模型是不可能维护的。（分析产生的）领域模型和（对领域模型的）设计之间如果出现了致命的分歧，这 样一个活动（ 分析或设计） 中产生的想法将无法对另外一个产生好的影响。 从... 阅读全文
posted @ 2015-10-23 20:02
赛提斯特
阅读(154)
评论(0)
推荐(0)
摘要：
很多问题,一开始你就不知道要干什么?一个模糊的需求介绍,概念是什么都不知道,这时候谈什么完整性,因为概念的完整性,最核心的是从根需求一直细化到最底层的叶子需求. 很多时候,开始你无法得到根的概念,客户也是零零散散的描述,这时候无所谓完整性,把每个小巧"用户故事"一个一个地实现,展示给用户,慢慢地会形成一个模糊的大概需求,这时候对需求的概念开始有了整体化(当然这个阶段可... 阅读全文
posted @ 2015-10-23 20:01
赛提斯特
阅读(196)
评论(0)
推荐(0)
摘要：
重构是小幅度进行的，其结果也必然是一系列小的改进。 有时，会有很多次小的变更 ，给设计增加的价值很小，有时，会有很少的变更，但却会造成很大的差异。 这就是突破。 ------DDD Q... 阅读全文
posted @ 2015-10-23 20:00
赛提斯特
阅读(135)
评论(0)
推荐(0)
摘要：
终于明白了,有时候不得不写一些晦涩难懂的代码,其实都是因为分析时漏掉了一些深层次的概念才导致的,缺少概念,就必然导致用一些复杂的操作去弥补 比如,一个付款的业务,你现有的概念是银行账户,目标账户,和一些验证机制,如果没有发掘一个位于这些概念之上的高层概念,就会导致你的账户具有一个复杂的方法(当然也可能是目标账户),这个方法负责验证,付款,收款等,而从业务领域的视... 阅读全文
posted @ 2015-10-23 20:00
赛提斯特
阅读(213)
评论(0)
推荐(0)
摘要：
一个大型的复杂项目而言，模型趋向于越来越大。 当模型发展到了某个规模，将 它作为整体来讨论很困难，理解不同部件之间的关系和交互变得很困难。 因此,强化不变量通常也是有必要的。 不变量是在数据发生变化时必须维护的那些规则。 在许多对象持有正在发生变化的数据对象的引用时，不变量是很难实现和维护的。使用 根对象可能会将内部对象的临时引用传递给外部对象，作为限... 阅读全文
posted @ 2015-10-23 19:59
赛提斯特
阅读(716)
评论(0)
推荐(0)
摘要：
有很多类型的内聚性。 最常用到的两个是通信性内聚（ communicational cohesion） 和 功能性内聚（ functional cohesion）。在模块中的部件操作相同的数据时，可以得到通信性内聚。 把 它们分到一组很有意义，因为它们之间存在很强的关联性。 在模块中的部件协同工作以完成定义好的任务时，可以得到功能性内聚。 功能性内聚被认为是最佳的内聚类型。... 阅读全文
posted @ 2015-10-23 19:59
赛提斯特
阅读(749)
评论(0)
推荐(0)
摘要：
一方面,脱离了模型的设计会导致软件无法真实表达它所服务的领域，很可能会得不到期望的行为。另一方面,建立模型的过程如果得不到设计的反馈或者缺少了开发人员的参与，会导致必须实现模型的人很难理解它，并且对于所用的技术而言可能不太适合.... 阅读全文
posted @ 2015-10-23 19:58
赛提斯特
阅读(144)
评论(0)
推荐(0)
摘要：
最近,应航天系统登月部门的测试需求,成功模仿CPU的流水线原理做出设计,满足了对方的需求,感觉真的很爽,终于再次验证了,知识都是相通的,立竿见影的绚丽技巧性的知识都很肤浅,潜移默化的平淡基础性的知识都很王道,看来以后我得加强数学方面的学习了,目前这是一个短板,不知道大学时为什么突然不想学数学了,真的很遗憾! 流水线设计,总线设计,真的很酷,虽然看不到,但是却是很酷! 阅读全文
posted @ 2015-10-23 19:57
赛提斯特
阅读(151)
评论(0)
推荐(0)
摘要：
WZ 架构师这东西。。我司的架构师是属于啥都做的但是不参与具体的功能开发STST 不做具体的,意味着空得很 DH 做技术选型啦性能优化啊安全专项啊之类的 STST 我不相信,不做具体的,能把设计做好 DH 那是因为做过很多年具体的了 没见过刚毕业进来就挂个架构师头衔的 STST 不做具体的,就得不到具体的反馈,得不到反馈,就无法确认设计没问题 做多少年也一样,这行业没有完全一样的设计,... 阅读全文
posted @ 2015-10-23 19:56
赛提斯特
阅读(184)
评论(0)
推荐(0)
摘要：
MS STST 这难度太高了 有一个就很难的了 也许我工作的环境一般,能把SOLID简要描述一下的,都还没有遇到 SOLID还只属于OOD层次,OOA层面就更加没碰到了 Scrip 因为领域驱动设计的大神比较多 MS 用的人不多吧 A 可能是会用的人不多吧 MS 是啊，大项目也没法用吧，要协调的东西太多 STST 全世界软件工程发展到现在,OOX应该是最核心的一块了吧 ，还要Gre... 阅读全文
posted @ 2015-10-23 19:43
赛提斯特
阅读(217)
评论(0)
推荐(0)
摘要：
一个偶然的机会,调试一段多年前的程序,那段程序有一套自动化的测试,但是经过多人易手,变化已经比较大了,测试已经无法通过,那么我的切入点就放在了这些测试里面. 这是一段带界面操作的程序,目标是测试一个矢量图形控件,这个例子里我关心的大致功能接口如下: 1, PlaceTestingSystem(..... 阅读全文
posted @ 2015-10-23 19:30
赛提斯特
阅读(1267)
评论(0)
推荐(0)
摘要：
MZK 原型模式就是拷贝构造吗 STST NO 模式不要和语法混在一起 MZK 此话怎讲 可以说c++中的深拷贝是原型模式的一个实例吗 STST 不是 拷贝构造是C++里面定义的一个语法而已 拷贝构造没有向用户隔离构造过程 原型模式隔离了 MZK 原型模式和ctrl+cctrl+v不是一个意思吗 STST 运行时候的ctrl+cctrl+v是太正常了 设计的时候ctrl+cctrl... 阅读全文
posted @ 2015-10-23 19:28
赛提斯特
阅读(155)
评论(0)
推荐(0)
摘要：
1，向敏捷转变的过程是一个很容易出乱子的过程，尤其对项目的领导力来说。在实施敏捷的过程中，会突然释放出一些有用的信息，将原来隐蔽起来的真相推倒聚光灯下。 2，假如执行者忽略了技术实践（比如测试驱动开发,重构，持续集成等），代码基础很容易被缺乏经验的开发人员搞坏，这时候，任何开发过程都无法自动修复。3... 阅读全文
posted @ 2015-10-23 19:18
赛提斯特
阅读(136)
评论(0)
推荐(0)
摘要：
CRS 如果功能复杂的情况下,是不是先写验收测试,然后写单元测试,最后写代码? STST 是的 从高往低走，无论是分析，还是测试，还是开发 从高往低走，带来的是干净无累赘的，底层依赖高层的优雅的结果 CRS 那模式是否1.先写feature2.实现自动化验收测试3.再写view层的ut(事实上view层的ut咋写?基本没法写啊..)4.实现view层(写死)5.实现contro... 阅读全文
posted @ 2015-10-23 16:56
赛提斯特
阅读(768)
评论(0)
推荐(0)
摘要：
最近总结了有一个现象:很多人喜欢用钳子干扳手的活,然后就坚信钳子是通用的,扳手应该是特殊的钳子,特别是对那些还在从底层开始设计的人来说,尤其突出,他们喜欢追求"通用"却不明白,通用应该从实现中提取,而不是来自于"设计" 阅读全文
posted @ 2015-10-23 16:36
赛提斯特
阅读(123)
评论(0)
推荐(0)
摘要：
STST 重复是软件最大的敌人,而复制粘贴是最最基础的重复 LF 软件可复用的 STST 通过复制粘贴来复用? HZ 软件可(粘帖)复制的 STST 从哪本书上看到有这样介绍的? 先分清下,这里的复制粘贴,不针对软件开发的结果(可直接发布的内容),而是指源代码层面的复制粘贴 STST 呵呵,把写代码的工作量当成软件开发过程的全部的话,复制粘贴有可能如你所说,能提高效率 C 哈哈哈，都这样啊。简便，... 阅读全文
posted @ 2015-10-23 16:35
赛提斯特
阅读(226)
评论(0)
推荐(0)
摘要：
躺了一会,回忆以前看过的一些描述"原本"的知识,突然想到简单的数学运算1+1=2,在程序设计里的原本是什么呢,想到这里,不睡了,按照前人的指引,我也来探索一下阿（以下代码使用C#4.0，未使用LINQ，其他语言可以找对应的语法） 直接写下最直接的代码如下这就是1+1=2,没错!这个子程序很具体,... 阅读全文
posted @ 2015-10-23 16:03
赛提斯特
阅读(514)
评论(1)
推荐(0)
摘要：
STST 想和大家讨论一下,一个测试用例里只做一个断言还是一个用例里做多个相关的断言 比如有一个查询函数Query(id)返回[姓名,性别,年龄] 那么是在一个测试用例里对这三个属性进行断言好? 还是在三个测试用例里,对每个属性进行断言好? HZ 三个检查一个用例 你是希望有10个问题每次告诉你一个人折腾10次还是一次告诉你10个折腾1次 STST 哦,但是我发现分开写,表达力更强 你说的"折腾... 阅读全文
posted @ 2015-10-23 16:01
赛提斯特
阅读(617)
评论(0)
推荐(0)
摘要：
有人想要在房顶加盖两层,施工人员经过仔细分析,得出结论,说目前加不了,要考虑先对地基进行改造以后才可行,甲方不认,说要你加就加,这就是执行力,这是执行力吗? 如果施工方不坚持己见,这不但不是执行力,而且还是极不负责的行为. 对"快速修复"坚决说不,更多的是一种能力和责任,没有能力,无法自我判断快速目标的性质到底是陷阱还是荣耀,没有责任,就会人云亦云,不坚持主见. 阅读全文
posted @ 2015-10-23 15:30
赛提斯特
阅读(137)
评论(0)
推荐(0)
摘要：
我前段时间和几个童鞋侃测试的话题,我的意思是,测试无论你用QTP,LR..,甚至是手工去操作,这些都不是核心,核心是理解测试的需求,整理测试用例,这才是核心中的核心,是测试工作中的创造性地工作,这部分创造好了,就是如何去实现测试,这就用上了前面提到的(QTP,LR...手工),这个过程实际上就是把测试需求映射到工具上的过程,这部分就比较好办了 阅读全文
posted @ 2015-10-23 15:29
赛提斯特
阅读(223)
评论(0)
推荐(0)
摘要：
我的逻辑编程,在一些场景下非常惯用 阅读全文
posted @ 2015-10-23 15:28
赛提斯特
阅读(163)
评论(0)
推荐(0)
摘要：
绝大部分的程序员都喜欢沉浸在底层开发中,在这里受人员,社交等因素的影响小,而这不正是程序员所梦寐以求的吗? 在这里,可以按照自己的理解,"勤奋"地写代码,信心十足,一日千行甚至更多,如同行云流水... 在这里,可以考虑各种将来"可能遇到"的情况,尽情打造心中完美的需求世界... …… 但是,别忘了,你的理解并非真实世界的概念,而很可能只是自己的臆想,你考虑的千百种可能只有一两种会碰到,甚至没有... 阅读全文
posted @ 2015-10-23 15:26
赛提斯特
阅读(165)
评论(0)
推荐(0)
摘要：
LJ 实际的测试项目，做起来才是头疼 咱们的工具能不能在实际的项目里减轻测试人员的工作量，才是问题的关键 怎么体现工具的价值啊 LJ 我跟你说我的两个观点： 第一，作为产品，需求设计是第一位的，功能不好，没办法让人用。 第二，作为公司的管理人员，应该使用的是结果导向的方法 LJ 对下属的要求，应该是具体明确的,可度量的LJ 这个观点供你参考吧 STST 嗯,非常好 STST 有一个问... 阅读全文
posted @ 2015-10-23 15:15
赛提斯特
阅读(147)
评论(0)
推荐(0)
摘要：
TQ 一个类的析构函数调用完毕之后这个程序还会做什么？直接结束吗？大家怎么看待这个问题呢？ CD c++类析构跟程序退出没关系 应该是说调用这个类完毕之后还会执行该类中相关信息吗？TQ 直接结束？？？？？？？？ STST 这个概念好混乱阿 类如何能调用完毕? 类,对象,方法这得关系都没理顺啊 类是一个静态的概念,与实践无关,和来"开始""结束"？ 对象是一个空间的概... 阅读全文
posted @ 2015-10-23 15:09
赛提斯特
阅读(138)
评论(0)
推荐(0)
摘要：
CZ 能不能清晰具体区分service和实体的区别 网上有人用DCI来解决不知道对不对 STST 我复习下DDD中的服务的概念了参与讨论啊CZ 这个我也看过但是太过于笼统 STST STST 复习了一遍,我是这么理解的 STST 假设一个道路模拟系统,里面有两个重要概念,汽车,加油站 汽车有一个职责叫:void加油(intcapacity) 加油站有一个职责叫:int供油(... 阅读全文
posted @ 2015-10-23 13:30
赛提斯特
阅读(649)
评论(1)
推荐(1)
摘要：
有一种说法 : 开发经理不写代码 系统架构师不写代码 高级程序员不写代码 个人认为: 到了一定境界的程序员，代码是最基本的最基本的构造快，这时候不会去注意到代码本身，不代表他不写代码，只是不拿代码来说事。 就如同走路对你来说已经是最基本的最基本的功能，这时候你也不会去注意走路本身（先左脚还是先右脚。。。）,但不代表你不走路,只是不关心走路本身,而只会关心目的地，但这不能说你到了这个境界了就不走路了... 阅读全文
posted @ 2015-10-23 13:19
赛提斯特
阅读(258)
评论(0)
推荐(0)
摘要：
LJ "但是有时候过度考虑技术，考虑维护性扩展性，而不考虑商业问题，也是不行的 STST 其实我认为的迭代方法，早就摈弃了这种过度考虑 迭代方法论强调做好现在，让现在的状态良好，需要扩展的时候才去扩展，而不提前考虑 因为保证任何时刻的状态都很好，所以需要扩展的时候也不心虚，正常重构就行 LJ 是的，不过很多程序员都有完美强迫症的 STST 从我个人的经历体验来说的话，这种追求"完美强迫"的欲望，来... 阅读全文
posted @ 2015-10-23 13:13
赛提斯特
阅读(391)
评论(0)
推荐(0)
浙公网安备 33010602011771号