酷壳 – CoolShell.cn

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

现实当中的例子

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

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

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

阅读全文…

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

需求又变了，怎么办？

先上一个轻松的段子：

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

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

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

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

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

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

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

阅读全文…

下面是我这段时间来收集的一些有意思的东西。本站这样的文章还很多，如这个，这个，这个。

Javascript Garden，这是学习Javascript最好的网站了。http://bonsaiden.github.com/JavaScript-Garden，这个文档由两具StackOverflow的人写成, Ivo Wetzel(Writing) 和 Zhang Yi Jiang (Design)，表示敬意。

想看看Web开发有哪些技术吗？你得看看这个网站：http://stackparts.com/，他对目前几乎所有Web上用得到的技术都分了个类。下面是个抓图。

Mozilla的安全编程规范 https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines Downloads associated to Software development

PHP,Perl, Ruby, Python语法比较http://hyperpolyglot.org/scripting?utm_source

阅读全文…

下面这篇文章来自这里：http://www.lsd.ic.unicamp.br/~oliva/fun/prog/resign-patterns，这篇文章有点意思了，山寨了我们著名的Design Pattern。这篇文章并不是很容易翻译，也许我翻译的不好，大家多指正。另外，这篇文章将失去原有的趣味在于其使用了经典设计模式的单词很相似的单词，一走眼你还以为是正二八经的设计模式。呵呵。所以，我在下文中，我会保留原有的英文单词，并把真正的23个经典设计模式的英文名放在旁边（灰色）。这篇文章和之前的如何写出无法维护的代码有异曲同工，个人感觉都是比较欢乐的。

辞职模式
Resign Patterns
Design Patterns

概要

1. Cremational Patterns 火葬模式 | Creational patterns 创建模式

1.1 Abject Poverty  一贫如洗 | Abstract Factory 抽象工厂

Abject Poverty 模式能让你的软件相当难测试和维护， 并且需要巨大的财政支出，预算已经完全赤字。

1.2 Blinder 眼罩模式 | Builder 建造模式

Blinder 模式是一个应急有效的解决方案，其不需要考虑需求在未来的变化。目前，我们还不太清楚我们为什么叫Blinder模式，一种说法是他们会在写代码的时候被设计人员戴上眼罩，另一种说法是他们希望在维护代码的时候挖出双眼。

1.3 Fallacy Method 错误方法 | Factory method 工厂方法

Fallacy方法主要是在于处理一些不明显的案例。代码逻辑看上去是正确的，当只要某想要去测试一下，或是某个不明显的案例发生了，那些代码中的错误也就出现了。

阅读全文…

下面是JDK中有关23个经典设计模式的示例，在stakeoverflow也有相应的讨论：
http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns

Structural（结构模式）

阅读全文…

所以设计模式，实是是一种方法，一种为了解决某种或某类物定问题所使用的设计模型。据说，在编程语言方面有100多种设计模式，而在现实生活中，传说有上成千上万个模式，比如写书有写书的设计模式，写武侠的一种，言情的另一种，连官方的新闻稿件也有。

阅读全文…