摘要：
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 组件和数据库脚本的行为中，之所以经常这样做，原 因是这样可以很容易地让事情快速工作起来（挑动了多少人的神经啊）。 当领域相关的代码被混入到其他层时，要阅读和思考这... 阅读全文