Design | 酷壳 - CoolShell

用Unix的设计思想来应对多变的需求

2012年05月03日陈皓评论 90 条评论 65,084 人阅读

之前，@风枫峰在“这是谁的错？”中说过开发团队对需求来者不拒，而@weidagang 也在“需求变更和IoC”中说过用IoC来最大程度地解决需求变更。今天我也想从Unix设计思想的角度来说说什么是好的软件设计，什么样的设计可以把需求变更对开发的影响降低。（注意：这并不能解决用户或是PM的无理需求，面对无理需求，需要仔细分析需求，而用技术的手段无法搞定这个事，但是可以减轻需求变更带来的痛苦）我曾经在《Unix传奇》的下篇中写过一些Unix的设计哲学和思想（这里重点推荐大家看一下《The Art of Unix Programming》，我推荐过多次了），以前也发过一篇《一些软件设计的原则》，不过，这些东西都太多了，记不住。其实，这么多年来，我的经验告诉我，无论是Unix设计，还是面向对象设计，还是别的什么如SOA，ECB，消息，事件，MVC，网络七层模型，数据库设计，等等，他们都在干三件事——解耦，解耦，还是解耦！所谓解耦，就是让软件的模块和模块间尽量少地依赖起来。

现实当中的例子

让我先举几个现实生活中的例子：

1、现实社会中，制造灯具的工厂完全不关心制造灯泡的工厂，制造灯泡的工厂完全不关心制造灯具的工厂，但是，灯泡和灯饰可以很完美地组合成用户所喜欢的样子（这和@weidagang 在“需求变更和IoC”说到的那个PC的例子相仿）。他们是怎么做到的？

2、互联网上，做网站的人完全不用关心用户在用什么样的操作系统，什么样的客户端浏览器（当然事实上，浏览器的不标准让网站那边很头痛，这里只是举个例），反过来，上网的人也不关心做网站的人在用什么的技术开发网站。但是大家在完全不关心对方的情况下，可以很正常地协同工作在一起。为什么？

…

阅读全文 Read More

(36 人打了分，平均分： 4.47 )

需求变化与IoC

2012年03月26日 Todd 评论 73 条评论 42,950 人阅读

【感谢 Todd投递本文 – 微博帐号：@weidagang 】

需求又变了，怎么办？

先上一个轻松的段子：

程序员XX遭遇车祸成植物人，医生说活下来的希望只有万分之一，唤醒更为渺茫。可他的Lead和亲人没有放弃，他们根据XX工作如命的作风，每天都在他身边念：“XX，需求又改了，该干活了，你快来呀！”，奇迹终于发生了，XX醒来了，第一句话：“需求又改了？”。

这个段子用幽默的方式反映了需求变化是每一个程序员、架构师或项目经理都会经常遇到的问题。面对这个问题，不同的人有不同的应对之道，最近微博上有一段关于需求变化的讨论：

@假装刺猬的猪：我们在软件开发过程中，会持续碰到客户需求变更的情况。如果没有领域建模，我们单纯将问题使用直觉将问题解决，那么等到客户需求变更或者有新的需求时，就会面临一个僵硬的前设计！无法在以前的设计上持续深入的优化模型，导致需求变更无法及时深化。设计实现均滞后与变更！

@高煥堂: <碰到客户需求变更的情况>是合理的；但<领域建模>不是美好的手段!!!

@weidagang: 要不被客户牵着鼻子走，需要自己有很强的设计能力，反过来让客户跟着你的设计来满足你的要求。能做到这点的公司很少，但这是软件行业唯一有希望的出路。

@高煥堂: <这是软件行业唯一有希望的出路>。 Great!!

如何应对需求变化？ @假装刺猬的猪的答案是领域建模，并持续优化模型，适应需求的变化。@高煥堂则认为领域建模不是美好的手段。我进一步补充，应该“反过来”让自己在需求变化中处于主导地位，而不是被动地适应。

…

阅读全文 Read More

(25 人打了分，平均分： 3.88 )

多版本并发控制(MVCC)在分布式系统中的应用

2012年03月13日 Todd 评论 98 条评论 60,402 人阅读

【感谢 Todd投递本文 – 微博帐号：weidagang 】

问题

最近项目中遇到了一个分布式系统的并发控制问题。该问题可以抽象为：某分布式系统由一个数据中心D和若干业务处理中心L1，L2 … Ln组成；D本质上是一个key-value存储，它对外提供基于HTTP协议的CRUD操作接口。L的业务逻辑可以抽象为下面3个步骤：

read: 根据keySet {k1, … kn}从D获取keyValueSet {k1:v1, … kn:vn}
do: 根据keyValueSet进行业务处理，得到需要更新的数据集keyValueSet’ {k1′:v1′, … km’:vm’} (注：读取的keySet和更新的keySet’可能不同)
update: 把keyValueSet’更新到D （注：D保证在一次调用更新多个key的原子性）

在没有事务支持的情况下，多个L进行并发处理可能会导致数据一致性问题。比如，考虑L1和L2的如下执行顺序：

L1从D读取key:123对应的值100
L2从D读取key:123对应的100
L1将key:123更新为100 + 1
L2将key:123更新为100 + 2

如果L1和L2串行执行，key:123对应的值将为103，但上面并发执行中L1的执行效果完全被L2所覆盖，实际key:123所对应的值变成了102。

…

阅读全文 Read More

(25 人打了分，平均分： 3.56 )

Bret Victor – Inventing on Principle

2012年03月09日陈皓评论 56 条评论 46,867 人阅读

Bret Victor（简历） – 苹果公司的UI交互设计师（大神级的人），在 CUSEC（Canadian University Software Engineering Conference）上做了一个题为 “Inventing on Principle” 的演讲（vimeo视频链接），这个演讲中展示了五个示例：

用程序画树。如何把程序绘图变成实时的，如何把程序和图映射起来。
游戏调试。在实时编程的基础上，可以更容易的让你看到程序参数对游戏的调整，甚至对游戏过程的可视化调试。
算法调试。在写二分查找算法时可以实时看到程序的执行过程。边写边看到。
电路图。可以实时地看到电路图中各个部件的对1/0信号的处理。
动画。一种比flash制作动画更NB 的方法。

下面是优酷上的视频——你一定会被示例中的那些编程工具所震撼！

不过，Bret并不是在说什么编程，也不是在说什么技术，他是在说 How to live your life。

…

阅读全文 Read More

(58 人打了分，平均分： 4.59 )

由12306.cn谈谈网站性能技术

2012年01月16日陈皓评论 369 条评论 298,934 人阅读

12306.cn网站挂了，被全国人民骂了。我这两天也在思考这个事，我想以这个事来粗略地和大家讨论一下网站性能的问题。因为仓促，而且完全基于本人有限的经验和了解，所以，如果有什么问题还请大家一起讨论和指正。（这又是一篇长文，只讨论性能问题，不讨论那些UI，用户体验，或是是否把支付和购票下单环节分开的功能性的东西）

业务

任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。

其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。

其二，有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，一方面会伴随着大量的查询操作，更BT的是下单的时候需要对数据库很多的一致性的操作，一方面是从起点到终点各个分段票的一致性，另一方面，买的人路线、车次、时间选择有很多，会不停地改变下单方式。而秒杀，直接杀就好了，没有那么多查询和一致性的问题。另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据，仅仅只是对用户的下单操作log），这种业务，只需要在内存cache中放好可秒杀的数量，还可以把数据分布开来放，100商品，10台服务器一台放10个，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据库。而且秒杀的商品不多。火车票这个不是像秒杀那么简单的，春运时间，几乎所有的票都是热门票，而且几乎是全国人民都来了，而且还有转车业务，多条线的库存都要做事务操作，你想想吧，这有多难。（淘宝的双十一也就3百万用户，而火车票瞬时有千万级别甚至是亿级别的）（更新：2014年1月11日：来了淘宝后，对淘宝的系统有了解，淘宝的秒杀活动，本质上是用输验证码并在CDN上把用户直接过滤掉了，比如：1千万个用户过滤了只剩2万个用户，这样数据库就顶得住了）

其三，有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性，没有锁，很容易水平扩展。

其四，订票系统应该和电子商务的订单系统很相似，都是需要对库存进行：1）占住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数据一致性在并发下是一个瓶颈。

…

阅读全文 Read More

(110 人打了分，平均分： 4.60 )

多些时间能少写些代码

2011年10月25日陈皓评论 118 条评论 90,848 人阅读

我在我的微博上说过这样一段话，我想在这里把我的这个观点阐述地更完整一些。

@左耳朵耗子：聪明的程序员使用50%-70%的时间用来思考，尝试和权衡各种设计和实现，而用30% – 50%的时间是在忙碌着编码，调试和测试。聪明的老板也会让团队这样做。而傻逼的老板，苦逼的程序员会拿出来100%-150%的时间来忙着赶进度，返工，重构，fix 大量的bug… 所以，越差的团队一般会越忙，而且还忙不完。

在现在这个浮躁的时期，再加上敏捷咨询师们念的歪经，他们让人感觉上就像是软件产品是可以在很短的时间内高质量的完成的，这令那些管理者们很兴奋，就像巴甫洛夫的条件反射实验中的狗看到了肉就会流口水那样兴奋。他们使用TDD，快速迭代，不断重构，持续集成直至持续部署的方法在进行软件开发。

软件开发真是这样的吗？难道不需要花时间去思考吗？对此，有些观点在Todd的《“品质在于构建过程”吗？》以及《Bob大叔和Jim Coplien对TDD的论战》中谈到过了。我只想想表达下面的观点：

软件的精髓在于设计，设计是一件很费大脑的事件。对于软件来说，设计没有完美的，它总是一件需要取舍需要权衡的事，比如：时间换空间，空间换时间，TCP或UDP，同步还是异步，数据冗余还不冗余等等。那怕是一个小小的observers模式是pull方式还是push方式都需要仔细讨论。这些的东西需要时间和做前期尝试。

TDD、快速原型和迭代可能会对软件和团队产生负面影响。在一开始，你需要花很大的精力来让你的软件从无到有（做过软件的人都知道，从零开始写代码是很痛苦的事），但是因为你没有想好，先做再说，所以，后期你会面临更多的质量问题而让你需要花更多的时间精力。当然，那些咨询师会让你用持续集成和持续部署这样的方法。但我想告诉你，这并不解决你软件设计的缺陷。举个例子——TDD、迭代、原型只关注功能性需求，其不会关注非功能性需求，比如性能问题，高可用性问题，系统维护问题（模块的耦合问题），等等。而这些问题往往都可以让你的软件设计重新来过。

重构是恶梦，重构应该越少越好。当你维护一个复杂的系统时你会知道重构是一件多么恐怖的事情（参看《重构代码的7个阶段》）。如果一开始没有想好，你要面临的不单单是re-design, re-architect，还要面对时间和人力成本的增加，最难的是你还要面对的是团队士气因为不断的rework而逐渐低落并产生厌倦和懈怠情绪。

…

阅读全文 Read More

(28 人打了分，平均分： 3.82 )

千万不要把 bool 设计成函数参数

2011年09月08日陈皓评论 94 条评论 63,437 人阅读

我们有很多Coding Style 或代码规范。但这一条可能会经常被我们所遗忘，就是我们经常会在函数的参数里使用bool参数，这会大大地降低代码的可读性。不信？我们先来看看下面的代码。

当你读到下面的代码，你会觉得这个代码是什么意思？

widget->repaint(false);

是不要repaint吗？还是别的什么意思？看了文档后，我们才知道这个参数是immediate，也就是说，false代表不立即重画，true代码立即重画。

Windows API中也有这样一个函数：InvalidateRect，当你看到下面的代码，你会觉得是什么意思？

InvalidateRect(hwnd, lpRect, false);

我们先不说InvalidateRect这个函数名取得有多糟糕，我们先说一下那个false参数？invalidate意为“让XXX无效”，false是什么意思？双重否定？是肯定的意思？如果你看到这样的代码，你会相当的费解的。于是，你要去看一下文档，或是InvalidateRect的函数定义，你会看到那个参数是 BOOL bErase，意思是，是否要重画背景。

这样的事情有很多，再看下面的代码，想把str中的”%USER%”替换成真实的用户名：

str.replace("%USER%", user, false); // Qt 3

TNND，那个false是什么意思？不替换吗？还是别的什么意思，看了文档才知道，false代码大小写不敏感的替换。

其实，如果你使用枚举变量/常量，而不是bool变量，你会让你的代码更易读，如：

…

阅读全文 Read More

(31 人打了分，平均分： 3.87 )

软件真的好难做啊

2011年06月10日陈皓评论 79 条评论 57,553 人阅读

还记得以前本站的那一篇“编程好难啊”吗，那是一篇众程序员调侃程序新手的文章，有恶搞的成分在里面。今天要和大家说的这个事没有一些恶搞和调侃的意思，是比较严肃的话题，你一定可以从中收获一些东西。这个话题来自StackOverflow上的一个问题——Cycle in Family Tree Software，这个程序员问了下面这个问题：

我是一个写家族族谱软件的程序员（我用的是C++和Qt），这个软件基本上没有什么问题，直到有一天有个用户报告了一个bug。这个问题是这样的——我这个用户和他女儿生了两个孩子。

于是，我程序员的一些断言和硬性条件导致程序报错，因为我的程序在处理这个关系的时候，其发现X即是Y的爸爸，又是Y的爷爷，所以只能报错。

请问，在不需要移除我的断言和数据验证的情况下，我怎么才能解决这个问题？

看到这里，请重点阅读一下下面的两点：

如果你看到这里开始兴奋了，请你为你阴暗的心理去面壁反省10分钟，因为这是一个很技术的问题。
如果你开始陷入了深深的思考如何解决这个问题，那么你绝对是一个合格的程序员，因为你已陷入技术已经很深了，有点呆了。

我在前面说过，“这个是一个严肃的话题，你可以从中收获一些东西”，当然，我并不希望你来收获乱伦的知识和心得，酷壳是一个技术博客，应该是收获技术方面的东西。

…

阅读全文 Read More

(29 人打了分，平均分： 4.38 )

读书笔记：对线程模型的批评

2011年05月03日 Ian.sino 评论 37 条评论 32,700 人阅读

——感谢Ian.Sian投递本文——

多线程模型是主流的并发编程模型。在过去几十年来，多线程模型一直是开发并发程序的有力工具。然而，它的历史并非总那么美好。1997年，NASA 的“火星探路者”号在执行任务的途中遭遇了严重的时序异常（参见 “What really happend on Mars“，注目 follow-up 中的现身说法），无法发回探测数据。如果不是 NASA 远程刷新了程序，它的结局就只能是报废在火星上。这一切都是由程序中潜藏的一个优先级反转 bug 造成的。更早的例子还有80年代的一系列 Therac-25 型医用粒子加速器事故。在这些加速器释放出的过量辐射照射之下，数位病人死亡。事后调查显示，至少有一次发生事故的原因，是加速器的控制软件中，存在一个只能由特定操作序列引发的竞争条件 bug。你也许认为这些只是陈年往事，但是直到现在，即便是世界500强公司们高价买来的信息系统，也同样避免不了这些问题。这导致许多程序员认为线程是个潘多拉魔盒，对它采取能躲就躲的态度。然而近来计算机的发展使得躲猫猫的空间越来越小：随便从市场上淘一个CPU，它里面也有不止一个核心。未来的程序员只会有越来越多的机会接触到并发编程，而无法再独善其身了。

加州大学伯克利分校教授，爱德华 A. 李在2006年做了一次题为《线程的麻烦 (The Problem with Threads)》的学术报告。在报告中他提到：看上去，多线程只是对核心语言的小小扩展，甚至可以以第三方库的形式存在。但实质上，多线程程序和原有的核心语言编写的程序已经完全不同了。其原因在于，由于多线程程序可能以任意的次序交错执行，程序再也无法像顺序执行时那样产生确定的结果。多线程程序容易编写(因为写的是顺序程序)，但是难分析，难调试，更容易出错。

在我的想法中，产生问题的根源，是多线程模型作为对并发问题的一个抽象，是很不完善的。 …

阅读全文 Read More

(25 人打了分，平均分： 3.92 )

一些软件设计的原则

2011年04月25日陈皓评论 69 条评论 82,870 人阅读

以前本站向大家介绍过一些软件开发的原则，比如优质代码的十诫和Unix传奇(下篇)中所以说的UNIX的设计原则。相信大家从中能够从中学了解到一些设计原理方面的知识，正如我在《再谈“我是怎么招聘程序”》中所说的，一个好的程序员通常由其操作技能、知识水平，经验层力和能力四个方面组成。在这里想和大家说说设计中的一些原则，我认为这些东西属于长期经验总结出来的知识。这些原则，每一个程序员都应该了解。但是请不要教条主义，在使用的时候还是要多多考虑实际情况。其实，下面这些原则，不单单只是软件开发，可以推广到其它生产活动中，甚至我们的生活中。

Don’t Repeat Yourself (DRY)

DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。

参考：http://en.wikipedia.org/wiki/Don%27t_repeat_yourself

Keep It Simple, Stupid (KISS)

KISS原则在设计上可能最被推崇的，在家装设计，界面设计，操作设计上，复杂的东西越来越被众人所BS了，而简单的东西越来越被人所认可，比如这些UI的设计和我们中国网页（尤其是新浪的网页）者是负面的例子。“宜家”（IKEA）简约、效率的家居设计、生产思路；“微软”（Microsoft）“所见即所得”的理念；“谷歌”（Google)简约、直接的商业风格，无一例外的遵循了“kiss”原则，也正是“kiss”原则，成就了这些看似神奇的商业经典。而苹果公司的iPhone/iPad将这个原则实践到了极至。

…

阅读全文 Read More

(33 人打了分，平均分： 4.39 )

酷壳 – CoolShell

享受编程和技术所带来的快乐 – Coding Your Ambition

Browsed by
标签： Design

用Unix的设计思想来应对多变的需求

2012年05月03日陈皓评论 90 条评论 65,084 人阅读

现实当中的例子

需求变化与IoC

2012年03月26日 Todd 评论 73 条评论 42,950 人阅读

需求又变了，怎么办？

多版本并发控制(MVCC)在分布式系统中的应用

2012年03月13日 Todd 评论 98 条评论 60,402 人阅读

问题

Bret Victor – Inventing on Principle

2012年03月09日陈皓评论 56 条评论 46,867 人阅读

由12306.cn谈谈网站性能技术

2012年01月16日陈皓评论 369 条评论 298,934 人阅读

业务

多些时间能少写些代码

2011年10月25日陈皓评论 118 条评论 90,848 人阅读

千万不要把 bool 设计成函数参数

2011年09月08日陈皓评论 94 条评论 63,437 人阅读

软件真的好难做啊

2011年06月10日陈皓评论 79 条评论 57,553 人阅读

读书笔记：对线程模型的批评

2011年05月03日 Ian.sino 评论 37 条评论 32,700 人阅读

一些软件设计的原则

2011年04月25日陈皓评论 69 条评论 82,870 人阅读

Don’t Repeat Yourself (DRY)

Keep It Simple, Stupid (KISS)