用框架开发完整项目，团队高效协同开发，移交他人与代码维护方便，要求框架设计要尽可能符合大家的思维习惯。
如何把握，这里从四个方面给大家阐述。

01把项目框架设计与管理划分为三个层最符合大家的共识。

中国人凡事喜欢讲究“三”，像昨天，今天，明天一样，很多事都要成“三”。

一般做项目的框架设计与管理，我也是分为三层次：

A 基础框架工具层

基础框架工具层。这个包含完成特定功能的库，第三方库，SDK，比如 netty, mina，条码识别库, http, WebSocket，json，protobuf 等。
这些库都是完成特定功能，内部也是一个小框架，但是提供功能接口给外部使用。
这部分能解决很多基础功能的问题，这样做对外提供的接口很简单，外部使用很简单，将这部分功能的复杂度封装起来了。
替换也很简单，只要重新基于接口来重新实现库，或重新封装库包成之前的接口。
这部分的代码由于他提供具体模块和算法，可重用性高。

B 框架机制层
这个是针对特定的项目提供特定的机制，让用户使用机制来高效开发业务逻辑。
比如:事件订阅与发布机制、组件化开发机制、ECS开发机制、微服务开发机制等。
这层的代码量并不大，但是核心机制决定了业务逻辑代码如何写。
这部分不同项目改动比较大，这个层次的代码建议可以根据不同随时修改，而不用太在意可重用性。
代码本身不多,一旦不满足要求，果断舍弃即可。

C业务逻辑代码
这个层基于机制来开发业务逻辑代码。
业务逻辑代码主要是业务逻辑尽量独立，不用考虑重用性，可扩展性，基于机制独立地完成特定功能即可。
业务代码随时可能会修改与重写，所以业务逻辑层要尽可能的分小，好加功能，同时也好从项目中移除。

微服务就是一个很典型的例子：写什么功能注册一个微服务，实现逻辑即可，如果要移除，直接移除就可以了。

这三层分完以后，初级，中级，高级不同水平的程序员可以安排到不同的层次。初级程序能完成业务逻辑功能，而不会引发框架稳定性动摇根本；中高级程序员方便维护项目与框架。

02 尽量少造概念和机制,减少大家学习成本。

我们每造一个概念和机制，就会增加学习成本和难度。
机制越多，同一个问题，就会出现很多种不同的代码写法。
不同的组织方式会加大代码维护难度。
我本身并不太喜欢语言特性很丰富的编程语言，比如C++。
计算两个对象相加，可以写函数实现，也可以重载操作符实现，可以用模板 omgd。
机制多了,每个人的代码写法就不同，维护起来就会麻烦，所以项目里面处理一类问题尽量使用一个机制，能复用机制尽量复用机制，而不造一个新机制，新的概念。
Linux内核要对接那么多千奇百怪的硬件设备，它也就只有一个机制，一切皆文件，使用文件机制，能控制和管理扩展无数的硬件设备与驱动，这个就是NB的模式。
少写类，每多写一个类就多一个概念；每多一个数据类型就多一个概念，多一分维护成本，多一分学习成本。

03 提供子框架，来解决特定复杂问题，把复杂封装起来。

我们解决复杂逻辑问题的时候，把一些工具性质的问题封成对应的模块，给整体项目提供支持，就像第三方库一样。

这样既能解决复杂问题，复杂业务逻辑，开发人员又只需要学会简单使用就可以，而不用管具体实现的复杂概念和算法设计。

如果库性能不好，可以重写替换，不用担心影响整个项目，替换时测试也方便。

把庞大的项目分成了一个一个的工具块，将复杂分割后，模块化,合并到上文提到的基础框架工具层,提供基础服务支持。

04 框架设计要能保证5分钟可移除相应代码。

上面三层结构，把问题分成了几个层次，方便定位问题和维护。
“基础框架工具层”的库不能用，或有第三方更好的库替换，重写库，重新封装接口到项目即可。如Mina换成netty。
“框架机制层”随时可以放弃，或提供新机制，机制的重写本身，成本不高。
不同项目可能会不同机制，这一部分代码无需过多考虑扩展性和重用性。
“业务逻辑层”主要实现业务功能。
机制层提供业务功能的开发方式，比如组件开发，微服务，这样能很方便能移除一个业务逻辑代码或重写一个业务逻辑代码。
业务逻辑代码基本不用考虑重用性和扩展性，简单，稳定。
你能承受多少东西，取决你能轻易放掉多少东西。
框架设计也是如此，等你哪天离职了，你的后继能轻松移除你写的代码，而不用重写整个项目。
后继也是如此，能很好的传承给他的后继，那你也就功成身退了。

总结一下
框架设计分成三个层次，符合绝大部分程序员的共识，和程序员的水平情况；
能让团队都能得到提高，并能稳定的出产品而不用太在意框架本身（没有什么不可修改的）。
初级程序员，编写业务逻辑，练习稳定的开发代码和逻辑功能；
中级程序员学会框架设计，与机制流程；
高级程序员负责系统分析和整合，选好最好的技术，整体把控。
大家也非常方便的能基于你这个框架来提升，不会迷茫。
而高级程序员也可以攻成身退，专心做其他的大事，团队的战斗力也会越来越强。