坪溪笔谈

从2004年初（大学二年级第二学期）加入学校就业信息网站，靠写代码获得第一笔收入，迄今已经将近六年。

第一条原则，首先弄清你的问题是什么。这一条规则无论怎么强调都不过分。

在《Programming Pearls》第二版的开篇，Jon Bentley 讲的就是，首先弄清你的问题是什么！ 在你没有详细、明确地定义好你的问题之前，你所做的大部分工作只产出废物。这些年，最头疼的事情，就是经常搞了一大堆东西，累死累活，甚至加班加点，最后总才发现很多事情偏离了目标。但这样的事情，总是在周围一遍一遍地发生。

一个工程师，如果在接到一个问题时首先不是尽可能挖到细致的资料，定义问题，并向了解问题的人去反馈，详细讨论问题的定义。虽然问题定义不是那么容易，但不首先定义好问题，那就是不合格的工程师。

还有很多原则，大抵都是这个原则的派生品。

第二条规则， 弄清你要干什么，以及哪些先干，哪些后干，哪些根本就不需要干。

说白了，就是把问题分解，列个表，排个先后顺序。这是大部分程序员最蹩脚的部分。高效的本质不是捧着ThoughtWorks那本《卓有成效的程序员》，而是我这条原则。我对Joel的书里印象最深刻的就是有关用Excel列任务列表的部分。

这条仍然是如此重要，以致于著名的YAGNI, (You ain’t gonna need it ）仅仅是一条推论而已。

当然，区分的标准是什么？It depends. 但是最重要的参照是，怎么做你能获得最大产出？也许你会在所谓的扩展性、适应需求变化与可工作的代码，用户的需求之间抉择。 最重要的还是可工作的代码，能够按时 ship the beta!

记住，先列出来要干什么；然后分清先后顺序，然后淘汰那些可以不干的。

第三条规则，KISS。 Keep It Simple Stupid。
用郭靖和杨过来比喻，代码要像郭靖一样用最简单直接的方式强壮地工作，不需要太多的波折。你的程序要是像杨过的人生那么复杂、聪明，早死翘翘了。 你的程序要简单强壮地干活，思想越简单越好，功能和特性越少越好。

这一条对于设计是至关重要的，浮躁的程序员们经常要在架构设计中引入模式、分层，又或者是绚丽的Ajax效果之类，完全是无知下的自虐。我也是好些年后才明白这条道理，直到后来开始使用Unix下的那些让无数人着迷的工具，才真真地看到了这条规则的巨大威力。

要特别澄清一下，KISS 与你的程序是否好用，是否易于复用，不但不矛盾，而且是相辅相成的。你要知道的只是你的程序应该做什么，然后努力做好。借用《Programming Pearls》开篇里法国作家兼飞机设计师的话：“设计者确定其设计已经达到了完美的标准不是不能再增加任何东西,而是不能再减少任何东西”。又如Chuck Yeager将军（第一个超音速飞行的人）赞扬一架飞机的机械系统时的用词是“结构简单、部件很少、易于维护、非常坚固”。

第四条规则，一键集成和适当的自动化测试。

这条不多说了，在有条件的情况下做会受益非浅。

其他还有一些很有名的原则，例如 DRY （Don’t Repeat Yourself)， 也许是因为一开始我就懂得了这个道理（尤记得大学的时候把ASP代码提取函数，封装Head和Foot，将写HTML Table的封装成方法来根据不同的数据集打印，好傻。），感触没那么深。

六年了，好快。

(Update 2009-12-23)
第五条： 一定需要且只需要数页简单明了的设计说明书。

这个设计说明最好不用word，最好是放在源代码下的html或者txt格式。简单粗线条的UML最适宜用在这种地方。当然设计文档也可以放在别的地方。

P.S.
用原则这个词，是为了强调重要性。遣词或有问题，慎自斟酌之。

作为一名工科生，从没有十分直接地感受到一些相隔很远的概念的价值。

边码代码边听着《致我们终将逝去的青春》广播剧，优美的音乐，不一样的爱情故事。忽然没来由地觉得沟通是一个如此重要的事情，而相关的产业也如此地受到人们关注。

沟通，是人成长的催化剂。不只是学校里的教诲，书本里的知识，还有朋友之间的交流，陌生人之间的言语。没有沟通变没有人的成长。

沟通，无处不在的沟通。无比重要的沟通。为什么沟通需要特别的监管？只能是因为沟通的力量是如此重大。

因为人是社会的动物。社会性是沟通如此重要的根本。

沟通对于产业的影响力，不仅仅在传媒产业里显而易见。我所从事的行业，互联网正是因为沟通而产生，沟通正是其立身之本。Google, Baidu, Facebook, Twitter, Renren, Kaixin001 等这些公司，无疑不是靠沟通吃饭的。 Google/Baidu是在帮助人们传递信息，减少沟通成本；如果说这还有点间接的话，Facebook, Twitter, Renren, Kaixin001 等都是直接地在拉近人们之间的距离。

系统，其很重要的用途是帮助人们沟通，业务设计的根本，其中之一就是沟通。
设计文档、代码可读易懂，正是设计工作中最重要的一个部分，因为是为了沟通。
工程管理中最重要的工作，自然也有沟通。各种各样的沟通，与客户沟通，与程序员沟通，与分析师沟通，与老板沟通，与客户的老板沟通； 与前任沟通，为后任留下可以沟通的介质； 读懂系统，读懂业务，正是沟通。

云计算似乎回归到一种与沟通无关的计算机产业。

Reliability, according the Wikipedia:

In general, reliability (systemic def.) is the ability of a person or system to perform and maintain its functions in routine circumstances, as well as hostile or unexpected circumstances.

The IEEE defines it as “. . . the ability of a system or component to perform its required functions under stated conditions for a specified period of time.”

On the page, it also tells:

Reliability may refer to:
Data reliability, a property of some disk arrays in computer storage

Availability, according to Wikipedia:

In telecommunications and reliability theory, the term availability has the following meanings:

1. The degree to which a system, subsystem, or equipment is operable and in a committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition.

Note 1: The conditions determining operability and committability must be specified.

Note 2: Expressed mathematically, availability is 1 minus the unavailability.

2. The ratio of (a) the total time a functional unit is capable of being used during a given interval to (b) the length of the interval.

Note 1: An example of availability is 100/168 if the unit is capable of being used for 100 hours in a week.

Note 2: Typical availability objectives are specified either in decimal fractions, such as 0.9998, or sometimes in a logarithmic unit called nines, which corresponds roughly to a number of nines following the decimal point, such as “five nines” for 0.99999 reliability.

There is another page about High Avaliability on Wikipedia:

High availability is a system design protocol and associated implementation that ensures a certain degree of operational continuity during a given measurement period.

Users want their systems, for example wrist watches, hospitals, airplanes or computers, to be ready to serve them at all times. Availability refers to the ability of the user community to access the system, whether to submit new work, update or alter existing work, or collect the results of previous work. If a user cannot access the system, it is said to be unavailable. Generally, the term downtime is used to refer to periods when a system is unavailable.

Scalability, according to Wikipedia:

In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged.

Methods of adding more resources for a particular application fall into two broad categories: Scale Up (Vertically) and Scale Out (Horizontally). Scale Out could be the better choices in many larger situations.

References:

1. System Reliability and Availability
2. Reliability and Availability Basics

来源：http://snowolf.javaeye.com/blog/403184

1. “开-闭”原则（Open-Closed Principle，或者OCP）：Software entities should be open for extension,but closed for modification.
2. 里氏代换原则（Liskov Subsitution Principle，或者LSP）    任何基类出现的地方，子类一定可以出现。
3. 依赖倒转原则（Dependency Inversion Principle，或者DIP）    要依赖于抽象，不要依赖于实现。
4. 接口隔离原则（Interface Segregation Principle，或者ISP）    应当为客户端提供尽可能小的单独的接口，而不要提供大的总接口。
5. 组合/聚合复用原则（Composition/Aggregation Principle，或者CARP）    要尽量使用合成/聚合，而不是继承关系达到复用的目的。
6. 迪米特法则（Law of Demeter，或者LoD）    一个软件实体应当与尽可能少的其他实体发生相互作用。
7. 单一职责原则（Single Responsibility Principle，或者SRP）  要使每一个软件实体只负责一种职责的实现。