- 博客(211)
- 收藏
- 关注
RSS订阅原创 On Simple Design II: 简单 != 少
See also Lightening Talk: 简单设计经常碰到的一段对话是：“这里为什么要引入一个类？字符串就好了，简单设计嘛” 或者 “一个switch/case就搞定的，弄个子类干嘛？”事实通常是反过来的，引入新的类型或子类比使用字符串或switch/case更简单. 我来解释一下设计是否简单的一个判断标准是它是否更容易理解. 而我们对事物的理解建立在概念或模型之上. 比如做一个最简单的
2012-05-22 22:18:10
1588
On Simple Design II: 简单 != 少
See alsoLightening Talk: 简单设计经常碰到的一段对话是：“这里为什么要引入一个类？字符串就好了，简单设计嘛” 或者 “一个switch/case就搞定的，弄个子类干嘛？”事实通常是反过来的，引入新的类型或子类比使用字符串或switch/case更简单. 我来解释一下设计是否简单的一个判断标准是它是否更容易理解. 而我们对事物的理解建立在概念或模型之上. 比如做一个...
2012-05-22 22:18:00
192
原创 On Knowledge Interface: 知行合一
信息, 知识, 和智慧说一下在看到徐昊介绍的知识漏斗(Mystery, Heuristic, Algorithm)之前我对知识的理解.我也分了三类: 信息, 知识和智慧信息: 信息就是我们能直接感知到的东西, 包括看到的听到的嗅到的尝到的摸到的.知识: 知识是对信息的加工, 是大脑思考的产物.智慧: 智慧是对知识的运用, 它反映在人的行动上 一个例子:太阳每天从东边升起, 巡行长空, 自西方落下
2012-05-19 11:51:48
1136
On Knowledge Interface: 知行合一
信息, 知识, 和智慧说一下在看到徐昊介绍的知识漏斗(Mystery, Heuristic, Algorithm)之前我对知识的理解.我也分了三类: 信息, 知识和智慧信息: 信息就是我们能直接感知到的东西, 包括看到的听到的嗅到的尝到的摸到的.知识: 知识是对信息的加工, 是大脑思考的产物.智慧: 智慧是对知识的运用, 它反映在人的行动上 一个例子:太阳每天从东边升起, ...
2012-05-19 11:51:00
324
原创 专家系统的测试策略: 不可验证?
---专家系统给测试和测试人员带来了不同的挑战.我们日常接触到的软件大多为通用软件或者企业应用, 使用起来比较简单, 易于理解. 与之对应的, 有一类软件我们称之为专家系统, 它们协助某个领域的专家来做出判断和决策. 比如地质监测, 天气预报, 还有我们经常在电影里看到的科学家使用的各种模拟软件: 龙卷风灾难模拟, 变态教授的分子化学和新药品实验等.直观的感觉, 这类软件已经与我们日常使用的软件
2012-04-09 18:10:33
1715
专家系统的测试策略: 不可验证?
---专家系统给测试和测试人员带来了不同的挑战.我们日常接触到的软件大多为通用软件或者企业应用, 使用起来比较简单, 易于理解.与之对应的, 有一类软件我们称之为专家系统, 它们协助某个领域的专家来做出判断和决策. 比如地质监测, 天气预报, 还有我们经常在电影里看到的科学家使用的各种模拟软件: 龙卷风灾难模拟, 变态教授的分子化学和新药品实验等.直观的感觉, 这类软件已经与我们日常使用的软件...
2012-04-09 18:10:00
439
原创 Performance Tuning Technique: 几个角度
性能受到系统架构的巨大影响, 而本书并没有涉及在高性能做为一个必需的设计约束时有哪些典型的场景以及可选的架构方案. 本书将内容限定在具体的产品和调优技术上, 或者, 技巧上. 架构决定性能的级别, 需要尽早确定必需的性能级别.书中提议不要把web应用看成单个application, 而是"分布式组件集合". 通常讲性能调优的书, 都是按照应用的不同层来分别讲述, 比如客户端性能, 服务端性能, 数
2012-03-11 20:24:31
2933
Performance Tuning Technique: 几个角度
性能受到系统架构的巨大影响, 而本书并没有涉及在高性能做为一个必需的设计约束时有哪些典型的场景以及可选的架构方案. 本书将内容限定在具体的产品和调优技术上, 或者, 技巧上. 架构决定性能的级别, 需要尽早确定必需的性能级别.书中提议不要把web应用看成单个application, 而是"分布式组件集合". 通常讲性能调优的书, 都是按照应用的不同层来分别讲述, 比如客户端性能, 服务端性能...
2012-03-11 20:24:00
354
原创 IDE二三事: 性能差是一种美德, Bug是一种Feature
性能差是一种美德ReSharper已经成为.Net开发必备工具. 其贴心的功能和快捷键设计让coding过程可以行云流水般随心而动. 可最近在客户这边写代码时却总是磕磕绊绊, 只因ReSharper变得奇慢无比, 之前从来没感觉ReSharper这么慢. 原因很简单: 类太大了. 一个.cs文件普遍在4000~5000行之间, 而partial class被大量使用, 通常一个完整的class大约
2012-03-04 22:03:26
2388
1
IDE二三事: 性能差是一种美德, Bug是一种Feature
性能差是一种美德ReSharper已经成为.Net开发必备工具. 其贴心的功能和快捷键设计让coding过程可以行云流水般随心而动. 可最近在客户这边写代码时却总是磕磕绊绊, 只因ReSharper变得奇慢无比, 之前从来没感觉ReSharper这么慢. 原因很简单: 类太大了. 一个.cs文件普遍在4000~5000行之间, 而partial class被大量使用, 通常一个完整的class大...
2012-03-04 22:03:00
305
原创 On GUI Architecture: GUI应用的若干问题和模式
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI). 关于GUI应用的架构设计, 已经有了很多模式, 比如Martin Fowler的blog中有一篇"GUI Architectures", 里面介绍了Form & Control, MVC, MVP, Passive View, Presentation Model, Supervising Controller, Event Aggr
2012-02-27 13:15:53
4235
3
原创 内聚的极限: 软件开发的不确定性原理
高内聚是有极限的. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的. -- 代码内聚设计的不确定性原理 大家都知道量子力学的不确定性原理: 在微观世界里, 有几对物理量不能同时精确的测定, 包括速度与位置, 以及能量与时间. 比如当我们精确的测定一个粒子的速度使其误差很小的时候, 我们对其位置的测量误差从0到正无穷都有可能, 换句话说, 此时粒子可能位于宇宙的任何地方, 这里的极限就
2012-02-06 22:57:56
1937
内聚的极限: 软件开发的不确定性原理
高内聚是有极限的. 当代码在一个维度上高度内聚的时候, 在其它维度上是发散的. -- 代码内聚设计的不确定性原理 大家都知道量子力学的不确定性原理: 在微观世界里, 有几对物理量不能同时精确的测定, 包括速度与位置, 以及能量与时间. 比如当我们精确的测定一个粒子的速度使其误差很小的时候, 我们对其位置的测量误差从0到正无穷都有可能, 换句话说, 此时粒子可能位于宇宙的任何地方, 这里的极限...
2012-02-06 22:57:00
135
原创 On Story Estimation: 单一职责原则
估算是软件开发中还没有很好的解决的一个问题, 因此争论也很多, 水平也参差不齐. 我无法给出更好的估算技术, 只是想抛出几个问题和观点 1. 单一职责和问题优先让我们从几个常见的问题开始: 估实际工作量(人天)还是相对大小?如果两个类似的Story有一部分实现代码是可以彼此复用的, 那么它们的估算应该是一样的还是不一样的? 还是把复用的那部分拆出来单独估?修复Bug的工作量要不要估算? 要不要算进
2012-02-01 21:41:12
2300
1
On Story Estimation: 单一职责原则
估算是软件开发中还没有很好的解决的一个问题, 因此争论也很多, 水平也参差不齐. 我无法给出更好的估算技术, 只是想抛出几个问题和观点1. 单一职责和问题优先让我们从几个常见的问题开始: 估实际工作量(人天)还是相对大小?如果两个类似的Story有一部分实现代码是可以彼此复用的, 那么它们的估算应该是一样的还是不一样的? 还是把复用的那部分拆出来单独估?修复Bug的工作量要不要估算...
2012-02-01 21:41:00
75
原创 新家 http://liguanglei.name
新家 http://liguanglei.name, 这里是2012年前的存档. 利用这里的电子书制作功能, 把之前的博客汇总了一下: http://chelsea.iteye.com/blog/pdf
2012-01-30 18:55:56
111
原创 On Extension Method: 扩展方法该如何使用
Herb Sutter 曾经有一个观点, 就是一个组件的接口, 不只包括这个组件本身定义的方法, 还包括使用这个组件的客户代码, 比如以这个组件为参数的那些方法. 扩展方法是对Herb Sutter这个观点所做的语法上的支持: 把以这个组件为参数的那些客户代码转变成扩展方法后, 调用时从语法上看起来跟调用这个组件本身定义的方法一模一样了!---------------------现实的分割线---
2012-01-30 14:45:00
2365
1
On Extension Method: 扩展方法该如何使用
Herb Sutter 曾经有一个观点, 就是一个组件的接口, 不只包括这个组件本身定义的方法, 还包括使用这个组件的客户代码, 比如以这个组件为参数的那些方法. 扩展方法是对Herb Sutter这个观点所做的语法上的支持: 把以这个组件为参数的那些客户代码转变成扩展方法后, 调用时从语法上看起来跟调用这个组件本身定义的方法一模一样了!---------------------现实的分割线-...
2012-01-30 14:45:00
103
原创 测试问题域: Test Double, 以及为什么Mock之争都争错了方向
全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题为了能编译通过, 我需要依赖被满足为了能正常运行, 我希望依赖的实现不要出错为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为, 并且
2012-01-04 21:43:36
4954
测试问题域: Test Double, 以及为什么Mock之争都争错了方向
全量测试又慢又难以定位错误, 其所需的测试环境的维护成本也很高. 解决方案就是化整为零分别测试. 然而引入新的问题: 测某个"部分"时所需的依赖如何满足. 解决方案是一组被称为"测试替身(Test Double)"的技术. 我们来看一下这里面具体的问题为了能编译通过, 我需要依赖被满足为了能正常运行, 我希望依赖的实现不要出错为了覆盖到真实场景下的用例, 我需要依赖能够模拟真实场景下的行为...
2012-01-04 21:43:00
86
原创 DCI: 与领域驱动设计,四色建模的关系
接上篇: DCI: 代码的可理解性>>与领域驱动设计的关系Domain Driven Design是一种分析和设计方法, 它的目的也是使软件更简单更稳定更易于理解. 但它的出发点或角度是分离业务和技术细节. 业务相对技术实现细节来说是更稳定的, 也更贴近问题域. DDD实际上有两部分的内容, 领域模型和如何建造领域模型. 但有趣的是事实上DDD对最终的领域模型看起来是什么样子并没有过多刻画, 只有
2011-12-25 21:55:38
4946
DCI: 与领域驱动设计,四色建模的关系
接上篇: <<DCI: 代码的可理解性>>与领域驱动设计的关系Domain Driven Design是一种分析和设计方法, 它的目的也是使软件更简单更稳定更易于理解. 但它的出发点或角度是分离业务和技术细节. 业务相对技术实现细节来说是更稳定的, 也更贴近问题域. DDD实际上有两部分的内容, 领域模型和如何建造领域模型. 但有趣的是事实上DDD对最终的领域模...
2011-12-25 21:55:00
185
原创 DCI: 代码的可理解性
可理解性: 为什么几十万字的小说看一遍我们就可以理解, 而几千行code却要一读再读? --Objects are principally about people and their mental models, not polymorphism, coupling and cohesion代码难以理解是软件行业的痼疾. 众多方法和方法论致力于解决这个问题, 不管主观还是客观. 造成理解困难的原
2011-12-21 22:11:58
9407
5
DCI: 代码的可理解性
可理解性: 为什么几十万字的小说看一遍我们就可以理解, 而几千行code却要一读再读? --Objects are principally about people and their mental models, not polymorphism, coupling and cohesion 代码难以理解是软件行业的痼疾. 众多方法和方法论致力于解决这个问题, 不管主观还是客观...
2011-12-21 22:11:00
165
原创 领域驱动设计: Community discussion and Personal understanding
ServiceService历来是争论的焦点. 批评者认为Service的存在表明了职责的不清晰, 认为Service里的代码是没放对位置的代码, 都应该放到相关的Domain对象如Entity中. 总而言之Service不够OO. Service是Transaction Script. 事实上这未必是Service这个building block的问题, 而是传统的面向对象编程范式的问题. OO
2011-12-07 22:35:20
2323
2
领域驱动设计: Community discussion and Personal understanding
ServiceService历来是争论的焦点. 批评者认为Service的存在表明了职责的不清晰, 认为Service里的代码是没放对位置的代码, 都应该放到相关的Domain对象如Entity中. 总而言之Service不够OO. Service是Transaction Script. 事实上这未必是Service这个building block的问题, 而是传统的面向对象编程范式的问题. ...
2011-12-07 22:35:00
112
原创 领域驱动设计: Bounded Context and Model-Dependent Realism
Bounded Context人们总是试图建立一个统一的模型, 某种一致的描述. 物理定律表现出来的一致性震撼人心, 是相对成功的例子. 绝大多数人都相信自然界存在一个终极的理论来描述宇宙的本质. 物理学的历史也就是不断趋近这个终极理论的历史, 不断有各种彼此独立彼此矛盾的理论被新的更一致的理论所统一. 比如目前前沿物理学家正在致力于统一自然界的四种力: 强力, 弱力, 电磁力, 引力. 目前
2011-12-04 23:23:34
3032
领域驱动设计: Bounded Context and Model-Dependent Realism
Bounded Context人们总是试图建立一个统一的模型, 某种一致的描述. 物理定律表现出来的一致性震撼人心, 是相对成功的例子. 绝大多数人都相信自然界存在一个终极的理论来描述宇宙的本质. 物理学的历史也就是不断趋近这个终极理论的历史, 不断有各种彼此独立彼此矛盾的理论被新的更一致的理论所统一. 比如目前前沿物理学家正在致力于统一自然界的四种力: 强力, 弱力, 电磁力, 引力. 目前...
2011-12-04 23:23:00
100
原创 领域驱动设计: More Practice
DDD的关键问题是如何识别缺失的领域概念. Eric的书里提供了一些方法, 比如倾听表达用语, 检查不协调之处, 研究矛盾之处等等. 我们需要更多的实践来捕捉缺失的概念.新实践: 检查更换编程框架对代码带来的影响.这个实践基于以下的理念: 业务逻辑没有发生变化则领域模型也不应该变化. 因此如果更换编程框架造成了大量业务代码的变动, 则意味着有概念没有被封装在领域层. 这里并非鼓吹要应用程序可以支持
2011-11-21 22:53:31
1954
领域驱动设计: More Practice
DDD的关键问题是如何识别缺失的领域概念. Eric的书里提供了一些方法, 比如倾听表达用语, 检查不协调之处, 研究矛盾之处等等. 我们需要更多的实践来捕捉缺失的概念.新实践: 检查更换编程框架对代码带来的影响.这个实践基于以下的理念: 业务逻辑没有发生变化则领域模型也不应该变化. 因此如果更换编程框架造成了大量业务代码的变动, 则意味着有概念没有被封装在领域层. 这里并非鼓吹要...
2011-11-21 22:53:00
77
原创 领域驱动设计: Understanding DDD
无论有没有软件支持, 无论软件是好是坏, 世界各地每个领域每天都发生着数以亿计可以理解的业务领域驱动设计是一种设计方法, 试图解决的问题是软件的难以理解, 难以演化. 采用的方法是围绕业务概念来构建模型.不过你也可以从两个角度来理解领域驱动设计: 作为设计结果的DDD和作为开发方法的DDD, 即 What and How.作为结果的领域驱动设计是这样一种设计(What): 它建立了一个模型, 这个
2011-11-14 22:02:58
3560
1
领域驱动设计: Understanding DDD
无论有没有软件支持, 无论软件是好是坏, 世界各地每个领域每天都发生着数以亿计可以理解的业务领域驱动设计是一种设计方法, 试图解决的问题是软件的难以理解, 难以演化. 采用的方法是围绕业务概念来构建模型.不过你也可以从两个角度来理解领域驱动设计: 作为设计结果的DDD和作为开发方法的DDD, 即 What and How.作为结果的领域驱动设计是这样一种设计(What): 它...
2011-11-14 22:02:00
91
原创 Lightening Talk: 论卫生间的设计, 如何解决女同胞公共场所如厕难的问题
商场影院博物馆等公共场所的女卫生间前总是要排队, 相信陪LP逛街看电影的同学一定深有体会. 一直很奇怪那些新兴场馆的设计者就不觉得这是个问题吗? 为什么男女卫生间的比例缺省就该是1:1呢?一直觉得这个问题解决方案很简单, 调整面积比例就可以了, 具体可以是两层楼四个卫生间的话按1:3的比例分之类的.史磊同学有另外一种方案. 他觉得问题在于卫生间的粒度设计的太大了. 一个人占据了一个坑之后,哪怕其它
2011-11-06 22:38:43
2472
1
Lightening Talk: 论卫生间的设计, 如何解决女同胞公共场所如厕难的问题
商场影院博物馆等公共场所的女卫生间前总是要排队, 相信陪LP逛街看电影的同学一定深有体会. 一直很奇怪那些新兴场馆的设计者就不觉得这是个问题吗? 为什么男女卫生间的比例缺省就该是1:1呢?一直觉得这个问题解决方案很简单, 调整面积比例就可以了, 具体可以是两层楼四个卫生间的话按1:3的比例分之类的.史磊同学有另外一种方案. 他觉得问题在于卫生间的粒度设计的太大了. 一个人占据了一个坑之后,...
2011-11-06 22:38:00
195
原创 Lightening Talk: 简单设计
网上有很多关于简单设计的争论. 观察了一下发现大家其实在说两个问题：一个是作为结果的简单设计，一个是作为过程的简单设计. 说一下我的理解.做为结果的简单设计是这么一种设计，它能被几乎所有人理解, 但只有极少数人能做出. 或者反过来说也可以. 简单设计是一种只有极少数人能做出的设计，但设计一旦做出后，能被所有人理解. 宏观物理世界这么复杂，但牛顿用三个定律就描述清楚. 质能方程E=MC2是另外一个例
2011-09-01 12:54:31
3789
Lightening Talk: 简单设计
网上有很多关于简单设计的争论. 观察了一下发现大家其实在说两个问题：一个是作为结果的简单设计，一个是作为过程的简单设计. 说一下我的理解.做为结果的简单设计是这么一种设计，它能被几乎所有人理解, 但只有极少数人能做出. 或者反过来说也可以. 简单设计是一种只有极少数人能做出的设计，但设计一旦做出后，<wbr></wbr>能被所有人理解. 宏观物理世界这么复杂，但牛顿...
2011-09-01 12:54:00
102
原创 REST on ASP.Net MVC (and Future)
See also: Enterprise REST = Customize, Invent and Standardize Media Types>> MVC和REST是两种不同的世界观. 前者更多的是对行为的建模，后者则更强调数据（状态及状态的变迁）. 前者给出的是内部实现方面的指导, 把程序结构分离为Model, View及Controller. 后者提供的则是从外部观察系统
2011-06-14 21:18:00
7873
1
REST on ASP.Net MVC (and Future)
See also: <<Enterprise REST = Customize, Invent and Standardize Media Types>> MVC和REST是两种不同的世界观. 前者更多的是对行为的建模，后者则更强调数据（状态及状态的变迁）. 前者给出的是内部实现方面的指导, 把程序结构分离为Model, View及Controller. ...
2011-06-14 21:18:00
131
原创 Enterprise REST = Customize, Invent and Standardize Media Types
关于REST, 经常容易引起困惑的一个问题是：在Machine-to-machine 的 REST 应用中,客户端怎么可能在没有任何预先知识的情况下就能跟随服务器端返回的超文本来自适应的将应用程序逻辑进行下去？答案是不可能. Client端必须提前了解足够的server端返回的超文本的知识, 才能跟随其中的指示将逻辑进行下去. 那跟SOAP,
2011-06-07 21:17:00
2693
Enterprise REST = Customize, Invent and Standardize Media Types
关于REST, 经常容易引起困惑的一个问题是：在Machine-to-machine 的 REST 应用中,客户端怎么可能在没有任何预先知识的情况下就能跟随服务器端返回的超文本来自适应的将应用程序逻辑进行下去？答案是不可能. Client端必须提前了解足够的server端返回的超文本的知识, 才能跟随其中的指示将逻辑进行下去. 那跟SOAP, WS...
2011-06-07 21:17:00
103
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人