摘要：
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 的时候了" ，他想。他换了一家公司，涨了一点工资，开始了另一段狂欢。周而复始，一年又一年过去了。随着年龄的增长，他不再能够从软件开发中享受到乐趣，软件开发的职业生涯，对于他而言痛苦... 阅读全文
摘要：
新的编程语言、新的开发框架层出不穷，让开发人员疲于跟随。以有涯之人生，去追随无涯的技术变迁，实在是一件很痛苦的事情.---DDD quikly所谓的新技术,都是新瓶装旧酒而已,你不学习,就永远被牵着鼻子走.如果你善于学习,最终的主动权在你在这里,你会发现其实技术没有什么变化,原来旧技术要做的3件事,采用新技术也还是3件事,只不过锤子感觉顺手一点而已 阅读全文
摘要：
STST 初级工需要大量的素材进行归纳,以提升自身的知识,这阶段需要大量的重复性的简单的工作 高级工主要通过演绎来思考,在实际中应用知识,高级工思考的时间占的比例更多一些 这个想法大家觉得认可吗?刚跟别人聊天时想到的 HL 成天演（bu）绎（yong）思（gan）考（huo）的高级工肯定认同 DH 高级工因为效率高因此有更多的时间来思考而已吧。。 HX 演绎思考是什么 不论是否演绎思考，思... 阅读全文
摘要：
"银行业软件肯定会跟踪客户的住址，但它决不会关心客户的眼睛是什么颜色的。"要保留哪些内容放弃哪些内容呢？ 这些取舍是设计和软件创建过程的一部分。 ------DDD Quikly 选择性忽略吧!不要尝试对概念进行全方位的建模,那是一个无底洞,而且不会带来好处,反而带来坏处,一个拥有1000个方法的列表类肯定会被只有10个方法的列表类打败. 永远紧盯你的主要目标,不断... 阅读全文
摘要：
"设计人员做好设计，结果交给编码人员，由编码人员实现"，这看起来很好！这种方法中存在的一个主要的问题是分析无法预见模型中存在的某些缺陷以及领域中的所有的复杂性。分析人员可能会过多深入到模型中某些组件的细节，但其他的部分却缺乏足够的细节。 非常重要的细节直到设计和实现过程才被发现。 瀑布设计方法，业务专家=提出=〉需求=>业务分析人员=创建=〉设计模型==〉开发人员=〉编码。在这个方... 阅读全文
摘要：
最好能让应用中的领域部分与其余部分相比保持尽可能小（ 而不是和其余部分掺杂在一起），因为一个典型的应用包含了大量访问数据库、 访问文件或网络、 用户界面等相关的代码，而业务逻辑经常被嵌入到 UI 组件和数据库脚本的行为中，之所以经常这样做，原 因是这样可以很容易地让事情快速工作起来（挑动了多少人的神经啊）。 当领域相关的代码被混入到其他层时，要阅读和思考这... 阅读全文
摘要：
1，如果设计或者设计中的核心部分没有映射到领域模型，模型就没有什么价值，而软件是否正确也就令人怀疑。 2，模型和设计功能之间的映射如果很复杂，就会很难理解 ，当设计变更了实际上模型是不可能维护的。（分析产生的）领域模型和（对领域模型的）设计之间如果出现了致命的分歧，这 样一个活动（ 分析或设计） 中产生的想法将无法对另外一个产生好的影响。 从... 阅读全文
摘要：
很多问题,一开始你就不知道要干什么?一个模糊的需求介绍,概念是什么都不知道,这时候谈什么完整性,因为概念的完整性,最核心的是从根需求一直细化到最底层的叶子需求. 很多时候,开始你无法得到根的概念,客户也是零零散散的描述,这时候无所谓完整性,把每个小巧"用户故事"一个一个地实现,展示给用户,慢慢地会形成一个模糊的大概需求,这时候对需求的概念开始有了整体化(当然这个阶段可... 阅读全文
摘要：
重构是小幅度进行的，其结果也必然是一系列小的改进。 有时，会有很多次小的变更 ，给设计增加的价值很小，有时，会有很少的变更，但却会造成很大的差异。 这就是突破。 ------DDD Q... 阅读全文
摘要：
终于明白了,有时候不得不写一些晦涩难懂的代码,其实都是因为分析时漏掉了一些深层次的概念才导致的,缺少概念,就必然导致用一些复杂的操作去弥补 比如,一个付款的业务,你现有的概念是银行账户,目标账户,和一些验证机制,如果没有发掘一个位于这些概念之上的高层概念,就会导致你的账户具有一个复杂的方法(当然也可能是目标账户),这个方法负责验证,付款,收款等,而从业务领域的视... 阅读全文
摘要：
有很多类型的内聚性。 最常用到的两个是通信性内聚（ communicational cohesion） 和 功能性内聚（ functional cohesion）。在模块中的部件操作相同的数据时，可以得到通信性内聚。 把 它们分到一组很有意义，因为它们之间存在很强的关联性。 在模块中的部件协同工作以完成定义好的任务时，可以得到功能性内聚。 功能性内聚被认为是最佳的内聚类型。... 阅读全文
摘要：
一个大型的复杂项目而言，模型趋向于越来越大。 当模型发展到了某个规模，将 它作为整体来讨论很困难，理解不同部件之间的关系和交互变得很困难。 因此,强化不变量通常也是有必要的。 不变量是在数据发生变化时必须维护的那些规则。 在许多对象持有正在发生变化的数据对象的引用时，不变量是很难实现和维护的。使用 根对象可能会将内部对象的临时引用传递给外部对象，作为限... 阅读全文
摘要：
一方面,脱离了模型的设计会导致软件无法真实表达它所服务的领域，很可能会得不到期望的行为。另一方面,建立模型的过程如果得不到设计的反馈或者缺少了开发人员的参与，会导致必须实现模型的人很难理解它，并且对于所用的技术而言可能不太适合.... 阅读全文
摘要：
最近,应航天系统登月部门的测试需求,成功模仿CPU的流水线原理做出设计,满足了对方的需求,感觉真的很爽,终于再次验证了,知识都是相通的,立竿见影的绚丽技巧性的知识都很肤浅,潜移默化的平淡基础性的知识都很王道,看来以后我得加强数学方面的学习了,目前这是一个短板,不知道大学时为什么突然不想学数学了,真的很遗憾! 流水线设计,总线设计,真的很酷,虽然看不到,但是却是很酷! 阅读全文
摘要：
WZ 架构师这东西。。我司的架构师是属于啥都做的但是不参与具体的功能开发STST 不做具体的,意味着空得很 DH 做技术选型啦性能优化啊安全专项啊之类的 STST 我不相信,不做具体的,能把设计做好 DH 那是因为做过很多年具体的了 没见过刚毕业进来就挂个架构师头衔的 STST 不做具体的,就得不到具体的反馈,得不到反馈,就无法确认设计没问题 做多少年也一样,这行业没有完全一样的设计,... 阅读全文