程序员是如何成为框架设计师或者是项目经理的？

做框架的人基本上是内向的比较多.不懂得和别人交流.更不懂得管理之道, 津津乐道与自己的创作之中.

框架设计师,是在不断的写代码和重构中成长的.甚至应该说是在不断的修改已有烂代码的过程中成长的.做框架设计师和普通程序员的区别就是必须知道面向对象设计模式中的最基本的原则：

开闭原则（Open Closed Principle）

软件系统必须对扩展开放，对修改关闭。

换句话说，我们的系统必须是可扩展的系统，而不是可修改的系统。

做到开闭原则，就注意以下两点。

1）多使用抽象类

在设计类时，对于拥有共同功能的相似类进行抽象化处理，将公用的功能部分放到抽象类中，所有的操作都调用子类。这样，在需要对系统进行功能扩展时，只需要依据抽象类实现新的子类即可。如图10-1所示，在扩展子类时，不仅可以拥有抽象类的共有属性和共有函数，还可以拥有自定义的属性和函数。

2）多使用接口

与抽象类不同，接口只定义子类应该实现的接口函数，而不实现公有的功能。在现在大多数的软件开发中，都会为实现类定义接口，这样在扩展子类时实现该接口。如果要改换原有的实现，只需要改换一个实现类即可。如图10-2所示，各子类由接口类定义了接口函数，只需要在不同的子类中编写不同的实现即可，当然也可以实现自有的函数。

 

里氏代换原则（Liskov Substitution Principle）

在一个软件系统中，子类应该可以替换任何基类能够出现的地方，并且经过替换以后，代码还能正常工作。子类也能够在基类的基础上增加新的行为。

里氏代换原则是对开闭原则的补充，它讲的是基类和子类的关系。只有当这种关系存在时，里氏代换关系才存在。"正方形是长方形"是一个理解里氏代换原则的最经典的例子。我们尽量从抽象类继承，而不是从具体类继承。如果从继承等级树来看，所有叶子节点应当是具体类，而所有的树枝节点应当是抽象类或者接口。当然这只是一个一般性的指导原则，使用的时候还要具体情况具体分析。

依赖倒置（Dependence Inversion Principle）

开闭原则的主要机制就是依赖倒转原则，这个原则的内容是：要依赖于抽象，不要依赖于具体，即要针对接口编程，不针对实现编程。

依赖也就是耦合，共分为下面3种。

零耦合（Nil Coupling）关系：两个类没有依赖关系。

具体耦合（Concrete Coupling）关系：两个具体的类之间有依赖关系，如果一个具体类直接引用另外一个具体类，就是这种关系。

抽象耦合（Abstract Coupling）关系：这种关系发生在一个具体类和一个抽象类之间，这样就使必须发生关系的类之间保持最大的灵活性。

依赖倒转原则要求客户端依赖于抽象耦合，抽象不应当依赖于细节，细节应当依赖于抽象。这个原则的另外一个表述就是：要针对接口编程，不要对实现编程。程序在需要引用一个对象时，应当尽可能地使用抽象类型作为变量的静态类型，这就是针对接口编程的含义。依赖倒转原则是达到开闭原则的途径。

要做到依赖倒转原则，使用抽象方式耦合是关键。由于一个抽象耦合总要涉及具体类从抽象类继承，并且需要保证在任何引用到某类的地方都可以改换成其子类，因此，里氏代换原则是依赖倒转原则的基础，依赖倒转原则是OOD的核心原则，设计模式的研究和应用都是用它作为指导原则的。

依赖倒转原则虽然强大，但是也很难实现。另外，依赖倒转原则是假定所有的具体类都会变化，这也不是全对，有些具体类就相当稳定。使用这个类的客户端就完全可以依赖这个具体类，而不用再弄一个抽象类。

接口隔离原则（Interface Segregation Principle）

使用多个隔离的接口，比使用单个接口好。也就是说，一个类对另外一个类的依赖性应当是建立在最小的接口上的。

在我们进行设计的时候，一个重要的工作就是恰当地划分角色和角色对应的接口。因此，这里的接口往往有两种不同的含义。

1．接口对应的角色

指一个类型所具有的方法特征的集合，仅仅是一种逻辑上的抽象，接口的划分就直接带来类型的划分。这里，我们可以把接口理解成角色，一个接口只是代表一个角色，每个角色都有它特定的一个接口，这里的这个原则可以叫做角色隔离原则。

例如，我们将电脑的所有功能角色集合为一起，构建了一个接口，如图10-3所示。

此时，我的电脑和你的电脑要实现该接口，就必须实现所有的接口函数，显然接口混乱，并不能够满足实际的需求：我的电脑可能是用来工作和学习的，你的电脑可能是用来看电影、上网和打游戏等娱乐活动的，那我们就可以将电脑的角色划分为两类，如图10-4所示。

2．角色对应的接口

指某种语言具体的接口定义，有严格的定义和结构。比如Java语言里面的Interface结构。对不同的客户端，同一个角色提供宽窄不同的接口，也就是定制服务，仅仅提供客户端需要的行为，客户端不需要的行为则隐藏起来。

对于图10-4中的接口定义，如果我的电脑除了工作和学习之外，还想上网，那就没办法了，必须实现娱乐电脑的接口，这样就必须实现它的所有接口函数了。此时我们需要将对应角色中的接口再进行划分，如图10-5所示。

 

这样，经过以上的划分，如果我的电脑想增加某一项功能，只需要继承不同的接口类即可。

由此可见，对接口角色的划分，是从大的类上进行划分的；对角色的接口进行的划分，是对类的接口函数的划分。它们两者由粗到细，实现了接口的完全分离。
合成/聚合复用原则（Composite Reuse Principle）

 

合成（Composition）和聚合（Aggregation）都是关联（Association）的特殊种类。聚合表示整体和部分的关系，表示"拥有"；合成则是一种更强的"拥有"，部分和整体的生命周期一样。合成的新的对象完全支配其组成部分，包括它们的创建和销毁等。一个合成关系的成分对象是不能与另一个合成关系共享的。

 

在面向对象设计中，有两种基本的办法可以实现复用：

 

第一种是通过合成/聚合，即合成复用原则，含义是指，尽量使用合成/聚合，而不是使用继承。

 

第二种就是通过继承。

 

要正确地选择合成/复用和继承的方法是，只有当以下的条件全部被满足时，才应当使用继承关系：

 

子类是超类的一个特殊种类，而不是超类的一个角色，也就是区分"Has-A"和"Is-A"。只有"Is-A"关系才符合继承关系，"Has-A"关系应当用聚合来描述。

 

永远不会出现需要将子类换成另外一个类的子类的情况。如果不能肯定将来是否会变成另外一个子类的话，就不要使用继承。

 

子类具有扩展超类的责任，而不是具有置换掉（override）或注销掉（Nullify）超类的责任。如果一个子类需要大量的置换掉超类的行为，那么这个类就不应该是这个超类的子类。

 

只有在分类学角度上有意义时，才可以使用继承。不要从工具类继承。

 

错误的使用继承而不是合成/聚合的一个常见原因是错误地把"Has-A"当成了"Is-A"。"Is-A"代表一个类是另外一个类的一种；"Has-A"代表一个类是另外一个类的一个角色，而不是另外一个类的特殊种类。

 

例如，我们需要办理一张银行卡，如果银行卡默认都拥有了存款、取款和透支的功能，那么我们办理的卡都将具有这个功能，此时使用了继承关系，如图10-7所示。

 

 

为了灵活地拥有各种功能，此时可以分别设立储蓄卡和信用卡两种，并有银行卡来对它们进行聚合使用。此时采用了合成复用原则，如图10-8所示。

 

最小知识原则（Demeter Principle）

一个软件实体应当尽可能少地与其他实体发生相互作用。

每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系-这在一定程度上增加了系统的复杂度。

例如，购房者要购买楼盘A、B、C中的楼，他不必直接到楼盘去买楼，而是可以通过一个售楼处去了解情况，这样就减少了购房者与楼盘之间的耦合，如图10-6所示。

 

 

为了遵循这些原则,就延伸出了设计模式.
其实本无所谓模式..只是有了原则,,为了遵守原则才有了设计模式.
很多模式你自己也能想出来.
为啥要遵循这些原则?答案是--为了应对变更.
如果没有变更的可能性,那么代码怎么写都行,越简单越好.

其实做框架也就那么点技术含量.也没啥..多改别人的烂代码.纠结了.就知道自己该怎么写更好. 要想快速进步就得看好的框架.人家怎么写的.

实际上也离不开那23种设计模式的范畴..

如果你想向项目经理发展,你就要彻底搞清楚,项目是如何从头到尾完成的.  通过那些方式保证软件的质量, 如何控制软件项目的进度, 如何控制软件项目的开发成本. 项目是如何报价的. 项目开发成本是如何估算的.如何才能估算的相对准确 项目风险如何控制和预防

项目文档和代码如何管理

项目开发用什么流程模式最合适...

项目团队如何调配.

更重要的是了解项目中谁的性格最适合放到项目中哪个位子上.才能发挥其最大的作用. 简言之就是会用人.

比如说有的人很技术很牛,善于挑战难题,解决问题能力很强. 我称之为牛人,你不能把他放到每天写增删查改的位子上去. 更不能放到测试上去..没啥效率.用不了几天就飞了.. 

牛人就应该放到技术攻关上.

 

有的人做事很认真仔细,但是技术不行我称之为普通人,这样的人也很好用.把他放到底层写代码的位子上他会很乐意,偶尔给点技术难度的让他挑战挑战.他就会很happy

给那些技术牛人当下手,做学徒. 他就会觉得很happy,.活干的挺好.还能学到东西..

牛人也会觉得很happy.有人给擦屁股了.自己也是师傅了,有个手下可以使唤.多爽..要再是个美女,happy翻了.一般技术牛人都有一个癖好----拉屎不擦屁股. 有上面这种人做配合就天衣无缝了.前提是两人脾气合得来.怕就怕技术也不行,态度还不认真的.属猪....该咋办你应该知道..技术行的,态度不好的人属狗,需要打.打一打压一压.给他点挑战就老实了.

最强的是技术行,态度好.做事认真负责.干活快.这样的真是人才.别放管理岗位上去.一定要当技术总监.当项目经理就浪费了.

一般的项目经理都是抗责任的.搞客户的,搞沟通的.但是项目经理最好能听技术总监的意见,别一意孤行..事情会做不好..也不能没主见.没主见还不如不要你.

俗话说人无完人,也别指望有非常完美的人.谁都有缺点的..项目出错了,首先想到的别老是批评手下,拿手下开刀..先反省下自己是不是没做到位..