1.选择商品化的技术
2.关注技术风险和市场风险
3.选择没有技术风险的想法
4.累积技术债务，快速将产品推向市场
5.仅当被黑了才重视安全
6.忘掉可扩展性
7.对好的想法说 “不”
8.没有笨重的语言
9.速度高于质量
10.用户体验高于用户界面
抽象化是一种非常的不同于模糊化的东西 … 抽象的目的并不是为了模糊，而是为了创造出一种能让我们做到百分百精确的新语义。
除数学外，对本土语言的异常的精通会是一个计算机程序员的最宝贵的财富。
程序应该是写给其他人读的，让机器来运行它只是一个附带功能。
性能的关键是精简，而不是一堆的优化用例。除非有真正显著的效果，否则一定要忍住你那些蠢蠢欲动的小微调的企图。
原型的价值就在于它对你的教育，而不是代码本身。
今天早上打算学习一些面向对象语言的基本原理，也不打算找一本著作仔细阅读了，就从网络上搜索一些有用的信息，做个记录。
过程语言是使问题与语言相适应，他关注的是数据和算法，他一般使用自上而下的设计方式，即把一个未知的大问题分解成一个一个可解或容易求解的子问题，然后最终把问题解决。
面向对象语言是使语言与问题相适应，他关注的是类，即如何描述问题域中的对象，他一般使用的是自下而上的设计方式，即先为问题域中的每个对象建立用于描述这些对象的类，然后通过类之间的交互描述整个问题。
通用式编程，或者称为模板编程，他强调的是算法方面，他提出一种通用的，与数据类型无关的算法结构。
——感觉说的有点问题？
过程式语言与面向对象语言，到底有什么区别？可能是初学者常碰到的问题。简单来说，过程式语言整个是构建在动词上的语言。比如，最常见的经典过程式语言- C语言，打印一条语句的语法是printf(), 这个方法的名字本身就是一个动词，这个动词强调了一个动作的过程，所谓过程式就是这个意思。
同样的方法在面向对象的JAVA中就是这样写：System.out.println(); 前面说过面向对象语言就是构建在名词基础上的系统，对象就是一个名词。大家都知道对象封装了操作和属性，所以System是一个对象，后面跟上分类在 out目录下的方法println。 这就是面向对象的写法。
总体而言,面向对象简单,面向过程对人员要求素质过高 面向过程就是分析出解决问题所需要的步骤，然后用函数把这些步骤一步一步实现，使用的时候一个一个依次调用就可以了。
面向对象是把构成问题事务分解成各个对象，建立对象的目的不是为了完成一个步骤，而是为了描叙某个事物在整个解决问题的步骤中的行为。
艾兰.库伯的《软件创新之路》中提到： 面向过程和面向对象的区别并不像人们想象得那么大 面向对象的大部分思想在面向过程中也能体现 但面向过程最大的问题（也许是唯一先天的缺陷）在于随着系统的膨胀，面向过程将无法应付，最终导致系统的崩溃 面向对象的提出正是试图解决这一软件危机 目前看来，似乎有一定成效 但仍任重道远。
其实我始终认为，不管是面向对象，还是面向过程，都体现了一种软件重用的思想！ 只不过面向过程中重用的是过程和函数，但是面向对象重用的是类，一种将数据和处理数据的过程及函数封装在一起的实体，其实面向对象中的过程和函数和面向过程中的分别不是很大，所以数据流图和伪代码还是有用的。 面向对象一个很大的好处就是数据 和方法的封装，由此面向对象的三大特性得到发挥
Mediator Pattern applied to Javascript
The diagram below is a general representation of the interaction between a mediator and colleagues. Each colleague stores a reference to the mediator and the mediator stores a reference to each colleague. Colleagues are unaware of each other and messages are broadcast through the mediator.
Two of the benefits of using the Mediator pattern are that that it decouples colleagues and simplifies object interaction. Instead of using the Observer pattern to explicitly set many-to-many listeners and events, Mediator allows you to broadcast events globally across colleagues. The biggest drawback of using Mediator pattern is that due to the centralized control, the mediator can become difficult to manage.
向对象开发与面向组件开发的区别
养成面向组件编程(COP)的习惯
面向组件还是面向对象
既然类和组件有着这么多类似的地方，那么传统的面向对象编程和面向组件编程有什么区别呢？简单的说，面向对象关注的是组合在一个二进制可执行文件中的各个类的关系，而面向组件的编程关注的是在彼此独立的基础上模块之间的交互性，这种交互性使得你并不需要熟悉它们内部的工作原理。
面向对象技术的基础是封装－－接口与实现分离，面向对象的核心是多态－－这是接口和实现分离的更高级升华，使得在运行时可以动态根据条件来选择隐藏在接口后面的实现，面向对象的表现形式是类和继承。面向对象的主要目标是使系统对象化，良好的对象化的结果，就是系统的各部分更加清晰化，耦合度大大降低。
组件技术的主要目标是复用－－粗粒度的复用，这不是类的复用，而是组件的复用，如一个dll、一个中间件，甚至一个框架。一个组件可以有一个类或多个类及其它元素（枚举、）组成，但是组件有个很明oo显的特征，就是它是一个独立的物理单元，经常以非源码的形式（如二进制，IL）存在。一个完整的组件中一般有一个主类，而其它的类和元素都是为了支持该主类的功能实现而存在的。
Efficient Pagination Using MySQL
基于设计的组件：首先：SOA和基于设计的组件不一样。在一个SOA架构中的服务是分布式的。而基于设计的组件中的这些组件是代码片段，通过他们所处每个系统来打包这些片段。从这种意义上来讲，EJB 能够作为服务和组件。
基于重用的组件通常比基于重用的服务简单。在服务重用时，在重用组件中变更带来的影响更是难以控制。其中可能有使用我的服务以及我没有关注的系统。在组件中，也许也是这种情况，但每个系统不得不有意识的做决定来升级组件，所以在一个系统中任何意外的破坏都与系统中那个早期的变更有关系。
耦合：这是“耦合”的真正意义。如果一个系统的改变很可能需要另一个系统的改变，那这两个系统是紧耦合的。这是一个很难通过观察代码来衡量的标准，然而很多人相信可以用代码的度量来理解耦合。
Linux内存模型
查看方式有两种，一种是直接输入umask，可以看到数字类型的权限设置分数，一种是加入 -S（Symbolic）参数，就会以符号类型的方式显示权限。
在默认权限的属性上，目录与文件是不一样的。由于我们不希望文件具有可执行的权力，默认情况中，文件是没有可执行（x）权限的。因此：
• 若用户建立为”文件”则默认“没有可执行（x）项目”，即只有rw这两个项目，也就是最大为666分，默认属性如下：
-rw-rw-rw-
• 若用户建立为”目录”，则由于x与是否可以进入此目录有关，因此默认为所有权限均开放，即为777分，默认属性如下：umask指定的是“该默认值需要减掉的权限”。因为r、w、x分别是4、2、1，所以。也就是说，当要去掉能写的权限，就是输入2，而如果要去掉能读的权限，也就是4，那么要去掉读与写的权限，也就是6，
IOU 思想是人们在处理日常债务关系时行之有效的一种方法，即：
- 债务人通过可靠的第三方保管账户，向债权人发放 IOU 债务凭证；
- 债务人通过向第三方保管账户提交结果以终止 IOU 债务；
- 债权人凭此 IOU 债务凭证通过第三方保管账户履行债权并进行结果赎回。
债务人和债权人之间的债务关系，通过可靠的第三方保管账户，实现了在时间和空间上最大程度的分离和解耦。
IOU 设计模式是 IOU 思想在软件设计领域的应用，最早由 Allan Vermeulen 于 1996 年首次提出。在软件设计领域，债务关系发生在方法调用者和方法体之间，债务对象就是方法的返回结果。普通方法的调用模型是方法体同步执行然后返回结果，调用者必须等待结果返回后才能继续执行。在 IOU 设计模式下，方法体将立即返回一个 IOU 对象，并且承诺 IOU 对象最终一定会被终止，调用者在 IOU 对象被终止后可进行结果的赎回。在此期间，调用者无需等待就能够继续进行其它有价值的事务，从而达到了提高程序整体的并发性和异步性的目的。
IOU 设计模式完全不依赖于任何一种异步机制，IOU 对象的提供者可以选择任意有效的方式来执行服务并最终终止 IOU 对象，比如启用独立的线程/进程执行、驱动异步事件产生、通过远程方法调用或是等待用户终端输入等等。这是 IOU 模式具备普遍适用性的一个重要因素。
Services Applications Perform a single or a few specialized operations. Perform a wide range of operations, and may even expose some of these operations as services. Most often accessed by other programs. Often (but not always) accessed by humans. Often (but not always) targets part of a larger problem domain. Often (but not always) targets a whole problem domain.
- 让整个小组参与。
- 在不同层次上进行规划。
- 使用不同度量单位，让对规模和持续时间的估计保持独立。
- 用功能或者日期来体现不确定性。
- 经常重规划。
- 跟踪进度并沟通
- 承认学习的重要性。
- 规划具有适当规模的功能。
- 确定功能优先级。
- 把估计和计划建立在事实上
- 保留一些松弛度。
- 通过前瞻规划协调做个小组。
- 缺乏技术实践:Scrum是一个项目管理框架，在技术方面没给任何建议。Bob建议团队“需要从其他诸如XP的方法中借鉴技术实践。这套技术实践可能包括：TDD、持续集成、验收测试、结对编程、重构。”
- 30天的冲刺周期太长：多数讲师现在建议冲刺周期1-2周，大多数团队采用的是2周。
- Scrum教练有时变成了项目经理:有些Scrum教练把Scrum当作微管理和控制的一种形式。“这不是Scrum固有的问题，而是Scrum发展中遇到的问题。或者这要怪‘master’这个单词了。”
- 对产品Backlog的指导太少：“经过多年实践，我们知道了backlogs有很多分层次的实体，包括史诗、主题、故事等等。我们学会了怎么对它们估计；学会了怎么把高层次的实体拆解成低层次：史诗->主题->故事->任务。”
- Scrum暗中包含反管理：“Scrum过度强调了团队自管理的角色。自组织和自管理的团队本身是好的,但是具有局限性…Scrum的描述并没有给与很好的平衡。”
- 自动化测试：没有高质量的自动化测试，很难以短的迭代周期工作，很难知道故事是否真的做完了。
- 多团队：Scrum和通用的敏捷方法很少谈及怎样扩展，虽然很多实践者有一些想法，但是还没有达成广泛的一致。
Composition versus Inheritance
Programming to an Interface, Not an Implementation
Creational Patterns Considered Obsolete
Inversion of Control Containers
Composition Realized
[Inheritance] can cause problems when you’re trying to reuse a subclass. Should any aspect of the inherited implementation not be appropriate for new problem domains, the parent class must be rewritten or replaced by something more appropriate. This dependency limits flexibility and ultimately reusability.Object composition is defined dynamically at run-time (at startup, config-time in most IoC containers –Chad) through objects acquiring references to other objects. Composition requires objects to respect each others’ interfaces, which in turn requires carefully designed interfaces that don’t stop you from using one object with many others. But there is a payoff. Because objects are accessed solely through their interfaces, we don’t break encapsulation. Any object can be replaced at run-time by another as long as it has the same type. Moreover, because an object’s implementation will be written in terms of object interfaces, there are substantially fewer implementation dependencies (!!! Very important –Chad)
Object composition has another effect on system design. Favoring object composition over class inheritance helps you keep each class encapsulated and focused on one task. Your classes and class hierarchies will remain small and will be less likely to grow into unmanageable monsters. On the other hand, a design based on object composition will have more objects (if fewer classes), and the system’s behavior will depend on their interrelationships instead of being defined in one class (configured and managed by the IoC container –Chad).
看似普通的Tag其实有着丰富的哲学含义
最近打算给开发和QA的同学介绍一下面向对象和UML相关的内容。这是第一篇，介绍主要面向对象的基础概念和UML类图的绘制。
概念：类似对象的一种软件抽象，创建对象的模板。
UML图：属性和操作之前可附加一个可见性修饰符。加号（+）表示具有公共可见性。减号（-）表示私有可见性。#号表示受保护的可见性。省略这些修饰符表示具有package（包）级别的可见性。如果属性或操作具有下划线，表明它是静态的。在操作中，可同时列出它接受的参数，以及返回类型。
概念：定义了一套内聚行为的一个或多个操作特性标记的集合。接口是确保送耦合的一种强大的方法。它们允许类参与一套共同的功能集，除了支持接口意外，不需要别的类知道任何有关他的事情。接口的设计要遵循“接口分离原则”，参见什么是面相对象设计的SOLID原则(s)
UML图：接口的UML图展现的样式会有几种变化，但内容都是一样的。
注：在StarUML中可以通过选择Interface元素的Format->【Stereotype Display】、【Suppress Attributes】、【Suppress Operations】来调整。
概念：实体之间的一个结构化关系表明对象是相互连接的。箭头是可选的，它用于指定导航能力。如果没有箭头，暗示是一种双向的导航能力。
UML图：
概念：有时对象会有其他对象组成。例如，飞机由机身、机翼、引擎、起落架等组成。这些全部都是聚合这个概念的例子，它表示“is part of”关系。
UML图：
class Node { private: vector<Node*> itsNodes; };
上述代码只有当子节点不会成为父节点的父节点时（即，必须是树结构，不能是图结构），才能称之
为聚合。
概念：组合是更强形式的聚合，其中“整体”负责部分，每个“部分”对象也仅与一个整体对象联系。例如，
在任何给定时间，引擎是且仅是飞机的一部分。而且，除了飞机以外，其他对象都不能直接与引擎对象发
生交互。
UML图：
class Car { public: virtual ~Car() {delete itsCarb;} private: Carburetor* itsCarb };
概念：对象之间存在临时关系，只有一个原因，它们可能会相互协作。一个对象与另一个对象进行协作，它需要了解这个对象。这意味着两个对象之间必须存在对象关系或part-of关系。当两个对象之间不存在持久关联的时候，我们需要在两个类之间建立依赖。
UML图：
概念：表示一个更泛化的元素和一个更具体的元素之间的关系。
UML图：
AbstractKmsTheme被标记为抽象的（名字是斜体）。
概念：指定两个实体之间的一个合同。换言之，一个实体定义一个合同，而另一个实体保证履行该合同。
UML图
| 术语 | 描述 |
| Abstract Class抽象类 | 不能实例化的类 |
| Abstraction抽象 | 一个项目（可能是类或者操作）的本质特征 |
| Aggregation聚合 | 两个类或者组件之间的关系，定义为“is part of” |
| Association关联 | 两个类或者对象之间的关系 |
| Attribute属性 | 类了解的东西（数据/信息) |
| Cardinality基数 | 表示“有多少”的概念 |
| Class类 | 类似对象的一种软件抽象，创建对象的模板 |
| Cohesion内聚 | 封装单元（如组件或者类）的相关程度 |
| Component组件 | 一种内聚功能单元，可以独立开发、发布、由其他组件编辑组成更大的单元。 |
| Composition组合 | 强类型的聚合，其中“整体”完全负责各个组成部分，每个部分对象仅与一个“整体”对象相关联 |
| Concrete Class具体类 | 可以从中实例化对象的类 |
| Coupling耦合 | 两个项目之间的依赖程度 |
| Generalization泛化 | 表示一个更泛化的元素和一个更具体的元素之间的关系。 |
| Inheritance继承 | 定义为“is a”或者“is like”的关系 |
| Instance实例 | 一个对象，它是某个类的一个示例 |
| Instantiate实例化 | 从类定义中创建对象 |
| Interface接口 | 定义了一套内聚行为的一个或多个操作特性标记的集合 |
| Message消息 | 请求星系或者执行任务 |
| Messaging消息传递 | 对象之间通过发送消息相互协作的过程 |
| Method方法 | 有执行值操作的类实现的一个过程（与结构化编程中的函数相似） |
| Multiple Inheritance多重继承 | 直接继承自一个以上的类 |
| Object对象 | 基于类定义的人物、地点、事件、事物等等 |
| Optionality选择性 | 概念“你需要它吗？” |
| Override | 在子类中重新定义属性和/或方法，以使它们与父类中的定义有区别 |
| Pattern | 在考虑相关因素的情况下，通用问题的一个可行性解决方案 |
| Polymorphism多态 | 不同的对象可以以不同的方式响应同一消息，使对象可以交互而不需要知道确切的类型 |
| Property | 在UML2中，是一个命名的值，例如，属性和关联，包括组合，指定元素（例如类或者组件）的一个特征。在Java中，属性的组合包括Getter和Setter |
| Single Inheritance多重继承 | 仅从一个类直接继承 |
| Stereotype构造型 | 建模元素的一种通用用法 |
| Subclass子类 | 继承自另一个类的类 |
| Superclass父类 | 另一个类从中继承的类 |
The Ojbect Primer中文版第二章
从编程技术到项目管理，Roy Singham、Martin Fowler、Rebecca Parsons等来自ThoughtWorks的思想领袖通过本书中的13篇美文，将自己多年沉思和实践所得倾囊相授，引领你走向敏捷软件开发的成功之路。
本书内容丰富，涵盖了软件开发的各个阶段，既包含DSL、SOA、多语言开发和领域驱动设计等热门主题，也有对象设计、一键发布、性能测试和项目管理等方面的经验之谈和独到见解。不论你是开发人员还是项目管理人员，都将从本书中获益匪浅。
S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。
| SRP | The Single Responsibility Principle | 单一责任原则 |
| OCP | The Open Closed Principle | 开放封闭原则 |
| LSP | The Liskov Substitution Principle | 里氏替换原则 |
| DIP | The Dependency Inversion Principle | 依赖注入原则 |
| ISP | The Interface Segregation Principle | 接口分离原则 |
当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASON FOR A CLASS TO CHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。
http://www.diybl.com/course/4_webprogram/jsp/jsp_js/20090304/157704.html
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。我对这个原则的理解还是很模糊，还需要在日后的工作、学习过程中慢慢体验:-)。
http://www.cnblogs.com/adam/archive/2008/04/18/1159280.html
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系
http://lensping.blog.sohu.com/73111028.html
1. 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
2. 抽象不应该依赖于细节，细节应该依赖于抽象
http://hi.baidu.com/mickeycn/blog/item/e60900129241da56f819b884.html
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。
http://blog.csdn.net/xiaolu123456789/archive/2009/02/26/3941014.aspx
The Principles of OOD 这篇文章中介绍了其他一些面向对象设计的原则，有兴趣的同学可以进一步的学习。
这几条原则是非常基础而且重要的面向对象设计原则。正是由于这些原则的基础性，理解、融汇贯通这些原则需要不少的经验和知识的积累。希望能在日后的工作、学习过程中真正的掌握和运用这些原则。
