切尔斯基

 命名测试用例的名字应该描述需求, 不要描述实现. 取决于你要沟通交流传递的信息, Test Case 有至少两个作用  检查你的产品代码是否按预期工作, 这由函数体来完成  表达你的预期,让阅读代码的人知道你的产品能够干什么,如何使用, 甚至如何设计的;这除了函数体的assert语句外,Test case的名字更是重要的手段 但我们...

在.Net/C#项目中采用project(*.csproj)来组织代码比用同一个project不同的文件夹来组织有几个好处:从客户代码的角度, 我依赖你很少一点东西, 可以就只依赖这点东西(做成单独的project), 不需要依赖其它无关的代码从访问控制, Visibility 的角度, C#的internal关键字是针对物理模块的, 即dll的, 而不是名称空间或文件夹从避免双向依...

同一个Feature的代码要放在一起(IDE里单独的一个工程, 或者工程里单独的一个文件夹), 这些代码要么全有要么全无的, 它们合作完成一个Feature, 如果用户不再需要这个Feature了, 可以把它们整个的痛快的删掉, 不会留下谁也用不到的代码成为系统的垃圾. 如果想看一个Feature是如何实现的, 那所有相关代码都在一起, 不需要在庞大的代码库中跳来跳去.那么理想的情况就是: 你...

谁来做Validation何时做Validation如何表达错误如何传递错误如何关联错误到发生错误的对象, 尤其是对象图中非Root对象这里的Validation指的是对进入到系统中的业务数据的校验(不包括Web应用中页面数据在浏览器端的验证)谁来做Validation数据的有效性不是自身所能决定的, 而是使用它的场景(Context)决定的, 因此, 每个...

 如何不带来额外的效率损失如何在程序运行出错时记录尽可能多的信息如何方便查找特定条件的错误如何横切的添加通用信息 如何不带来额外的效率损失在之前接触的一个大型产品中见过散布着如下代码:if (Log.Level > DEBUG) { logger.write(some_method_to_build_the_log_string());}问...

网上有很多关于简单设计的争论. 观察了一下发现大家其实在说两个问题：一个是作为结果的简单设计，一个是作为过程的简单设计. 说一下我的理解.做为结果的简单设计是这么一种设计，它能被几乎所有人理解, 但只有极少数人能做出. 或者反过来说也可以. 简单设计是一种只有极少数人能做出的设计，但设计一旦做出后，<wbr></wbr>能被所有人理解. 宏观物理世界这么复杂，但牛顿...

 关于REST, 经常容易引起困惑的一个问题是：在Machine-to-machine 的 REST 应用中,客户端怎么可能在没有任何预先知识的情况下就能跟随服务器端返回的超文本来自适应的将应用程序逻辑进行下去？答案是不可能. Client端必须提前了解足够的server端返回的超文本的知识, 才能跟随其中的指示将逻辑进行下去. 那跟SOAP, WS...

 可理解性: 为什么几十万字的小说看一遍我们就可以理解, 而几千行code却要一读再读? --Objects are principally about people and their mental models, not polymorphism, coupling and cohesion 代码难以理解是软件行业的痼疾. 众多方法和方法论致力于解决这个问题, 不管主观还是客观...

接上篇: <<DCI: 代码的可理解性>>与领域驱动设计的关系Domain Driven Design是一种分析和设计方法, 它的目的也是使软件更简单更稳定更易于理解. 但它的出发点或角度是分离业务和技术细节. 业务相对技术实现细节来说是更稳定的, 也更贴近问题域. DDD实际上有两部分的内容, 领域模型和如何建造领域模型. 但有趣的是事实上DDD对最终的领域模...

商场影院博物馆等公共场所的女卫生间前总是要排队, 相信陪LP逛街看电影的同学一定深有体会. 一直很奇怪那些新兴场馆的设计者就不觉得这是个问题吗? 为什么男女卫生间的比例缺省就该是1:1呢?一直觉得这个问题解决方案很简单, 调整面积比例就可以了, 具体可以是两层楼四个卫生间的话按1:3的比例分之类的.史磊同学有另外一种方案. 他觉得问题在于卫生间的粒度设计的太大了. 一个人占据了一个坑之后,...

 无论有没有软件支持, 无论软件是好是坏, 世界各地每个领域每天都发生着数以亿计可以理解的业务领域驱动设计是一种设计方法, 试图解决的问题是软件的难以理解, 难以演化. 采用的方法是围绕业务概念来构建模型.不过你也可以从两个角度来理解领域驱动设计: 作为设计结果的DDD和作为开发方法的DDD, 即 What and How.作为结果的领域驱动设计是这样一种设计(What): 它...

DDD的关键问题是如何识别缺失的领域概念. Eric的书里提供了一些方法, 比如倾听表达用语, 检查不协调之处, 研究矛盾之处等等. 我们需要更多的实践来捕捉缺失的概念.新实践: 检查更换编程框架对代码带来的影响.这个实践基于以下的理念: 业务逻辑没有发生变化则领域模型也不应该变化. 因此如果更换编程框架造成了大量业务代码的变动, 则意味着有概念没有被封装在领域层. 这里并非鼓吹要...

Bounded Context人们总是试图建立一个统一的模型, 某种一致的描述. 物理定律表现出来的一致性震撼人心, 是相对成功的例子. 绝大多数人都相信自然界存在一个终极的理论来描述宇宙的本质. 物理学的历史也就是不断趋近这个终极理论的历史, 不断有各种彼此独立彼此矛盾的理论被新的更一致的理论所统一. 比如目前前沿物理学家正在致力于统一自然界的四种力: 强力, 弱力, 电磁力, 引力. 目前...

网上已经有很多详细解释性能测试, 容量测试, 负载测试, 压力测试各自的概念, 之间的联系以及区别, 还有骡子背东西等生动的例子...这里按自己的理解re-statement一下其实所有的一切都只是几个因素的相互作用, 互为函数:并发量/数据量机器配置单个请求处理速度稳定运行时间A: 给定并发量/数据量，机器配置， 和必须的稳定运行时间，求单个请求处理速度（Exam...

IoC避不开的一个问题是如何处理应用程序的模块化, 因为IoC通常针对单个对象提供了良好的支持, 比如依赖管理,生命周期管理,部署时配置甚至运行时配置, 但往往一组内聚的互相协作的对象才构成应用程序基本的构建块. 这组内聚对象间的协作关系是实现细节, 包括单个对象的构造函数和属性也是, 如果把这些暴露出来, 固然可以提高灵活性, 但是以最后的部署阶段的复杂性以及难以维护性为代价的. 以配置文件...

1, 实际上 C# 2.0 已经部分的支持 mixin 了, 只要一直把类声明为 partial.2, 共享网络共享存储, 网格共享 CPU 计算周期和内存, P2P网络还共享带宽, 还有什么应该共享的?3, 必然如果你花 99% 的时间工作, 1% 的时间忙自己的事情, 你的Boss就会 凑巧的 必然的 在那 1% 的时间内 visit you.4,meta programmer产生其它...

2，质这种特质是任何东西中都存在的最基本的特质它决不可能相同．因为它总是在它出现的特殊场合形成自己的形状在这个地方它是平静的，在那个地方它却是激烈的；在这个人它是时机，在那个人它却是无关紧要的；对这个住房它是明亮的，对那个住房它却是黑暗的；对这个房间它是温柔宁静的、对那个房间它却是陈旧的：在这个家庭它是对野餐的嗜好．而在另外的家庭则是跳舞、或玩纸牌游戏；对于另外的一群人．它则与家庭...

Q: 为什么通过单元测试发现的 Bug 很少 ?A: 单元测试不是用来发现 Bug 的, 而是用来预防 Bug 的. 如果采用 TDD, 测试用例完成之时, 产品代码尚未编写, Bug更无从谈起. Q: 那是否写单元测试就能提高代码质量了 ?A: 关于这一点, 似乎有人不这么看, <<TDD Opinion: Quality Is a Function of Thoug...

 Q: 结对编程、责任共享，完全是胡说，代码找不到作者，开发人员哪里会有责任心!A: 这个疑问基于一个假设: 开发人员的责任心来自于问责制度, 开发人员只有在恐惧的驱使下才会细心去编码.我不知道你的职位是什么, 你或许是某个大中型企业的中高层领导, 或许手下有不少的人, 但你不会得到手下的尊敬, 他们只有"畏".或许在对死亡之类的恐惧面前, 人类会爆发出强大的力量, 对于医疗系统,...

新年伊始, 可能你又要制定一些计划了, 实际上, 你的生活在开始一个新的迭代迭代, 不是软件业的发明, 而是万物根本社会的迭代 : 王朝的替换, 制度的变革去年你是天王, 今年我是至尊开元盛世, 贞观之治自然界的迭代 : 基因的变迁, DNA的双螺旋地球公转, 四季轮换, 日复一日, 年复一年生理的迭代 : 日升日落, 月圆月缺. 女人, 月当月快乐感情的迭代 :前尘后世轮回中, 谁在宿命里安排....

 卡尔.波普尔的理论能很好的解释目前的科学, 艺术, 政治, 社会等方面一般性的问题. 它对软件开发过程中一些显而易见的问题有着明确的答案. 比如, 我们都知道我们无法证明软件已经没有Bug, 用波普尔的话说就是: 科学理论都是假说, 爱因斯坦的竞争理论表明对牛顿理论的即使如海王星发现般严格的检验都不能确保其正确性, 即对白天鹅的一千次观察都不足以断言黑天鹅的不存在. 能否证伪是科...

敏捷外传之FBI: 世界上最敏捷的团队 事实上, 世界上有一支最著名的敏捷团队, 一直很少有人意识到, 这就是美国的 FBI. 虽然我们不知道它内部实际的情况, 也有不少电影把FBI 描述的很白痴, 但是至少在<<越狱>>中他们的做事方法所反应出来的思想, 与敏捷如出一辙.跨功能的团队:各方面的专家组成一个抓捕团队, 归一个人指挥, 而...

HTML clipboard1. HTTP本身无连接无状态, 如何在不同请求间识别用户以支持需要多个请求才能完成的业务?其它所有问题都是这个问题的某种解决方案引入的. 这个论断有一个推论, 就是不需要识别用户的Web应用是最简单的Web应用. 一种方案是所有的业务都设计成一次请求就可以完成, 比如让用户每次都输入用户名密码, 填写所有的表单, 然后一次性提交. 从用户体验的...

Q: 我的产品是电信级的设备, 几百人分成几十个项目组在开发, 各个项目组进度不统一, 如何集成?A: 你要做的其实跟技术无关, 更多的是管理工作, 就是制定你的产品级别的集成策略.这涉及到需求分析和发布计划(依赖管理, 价值和风险识别), 开发方法(自顶向下还是自底向上, 横向分层还是垂直特性), 集成粒度划分(完整特性的集成还是API的集成), 集成间隔计划, 版本控制策略, 还有...

 迭代在于我们明确的承认信息和知识的不完备性, 不可完备性. 而项目的成功, 需要某种程度的完备性.这种认知的局限与成功的条件之间的矛盾, 促成了人们解决这类问题的通用方法: 渐进的试错法 试错法参考一: http://en.wikipedia.org/wiki/Trial_and_error.试错法参考二: http://zh.wikipedia.org/wiki/%E8%A...

 单个团队内部的持续集成已经是成熟的实践. 跨团队的集成则碰到了很多问题, 包括全部测试运行时间过长, 合并成本高等问题. 针对这些问题有一些对应的解决方案, 如合理的分支策略, 分层的集成等.这里想讨论一下几个基本的矛盾, 和理想中的解决方案 1. 并行开发 与 集成 之间的矛盾这是本质问题, 如果所有功能都是由单一开发者循序渐进的完成, 则集成并不是大问题. 由于团...

 假设我们必须处理对象的存储, 加载, 和查询. 性能和引用完整性的约束, 给接口的实现带来了以下问题:加载根对象时如何避免加载大半个数据库存储时如何更新整个对象图存储时如何高效的更新整个对象图何时同步对象的内存状态和持久存储状态如何确保在出错时保持对象内存状态和持久存储状态之间的一致性如何保证引用的唯一性以避免可能的更新冲...

ServiceService历来是争论的焦点. 批评者认为Service的存在表明了职责的不清晰, 认为Service里的代码是没放对位置的代码, 都应该放到相关的Domain对象如Entity中. 总而言之Service不够OO. Service是Transaction Script. 事实上这未必是Service这个building block的问题, 而是传统的面向对象编程范式的问题. ...