多解决些问题，少谈些框架和流程

大概我刚刚毕业那会，是经常喜欢在群里和网友谈论框架的，尤为是游戏服务器的框架设计，好比网关啦，逻辑服务器啦，地图服务器啦，登录服务器啦等等，巴拉巴拉一大堆；我那会大概是刚刚接触游戏开发，刚刚明白了一条消息是如何从客户端，经历不一样的进程传递到服务器的，亦或是刚刚听一个或者两我的分享了关于游戏开发框架的介绍；因此便开始在群里夸夸其谈了。

也是趁着热乎劲，在博客园上分享了两三篇关于游戏服务器的文章(如今再看真是漏洞百出，拈轻怕重)，获得不少人的点赞和评论，开始觉得本身是游戏服务器开发届的大拿了！

这大概是年轻的我，在那个时候，一些不成熟的想法和作法了。

在工做几年以后，犯了不少错误，补了不少坑以后，渐渐发现研究解决问题是极困难的；高谈框架流程是极容易的事。谈论框架是阿猫阿狗都能作的，好比刚毕业时候的我也能够谈论游戏服务器框架，然而那个时候的我却解决不了好比断线重连的问题，好比多负载的问题等等。

由于一些缘由，我短暂离开过公司一段时间；期间公司老板招聘了一个技术经理接替个人位置，固然没有过多久便离开了，带着一顿抱怨(私下里和同事抱怨公司的各类问题)和谦虚自责(和离职申请上说本身没法胜任工做)离开了。

我后来重回公司，原本对这位和我并无交集的技术经理没有什么意见。可是当我从新接手他的工做的时候，发现他并无解决哪怕一个问题，却留下了一堆对公司流程和代码框架的吐槽和无用的文档。我想，这是否是有点拈轻怕重，是否是懒，是否是靠着吐槽或者对框架和公司的不屑一顾，来掩饰本身解决不了问题的能力。

框架和流程，通常是那个时候的项目经理技术经理，根据那个时候的技术人员的配备，公司积攒的项目，和当时的业务需求，所作的解决问题的思路体现。固然随着公司的发展，业务需求的变化，人员的升级，框架和流程也会跟着作微调，可是不多作大的变更，一时人力和工期的紧张，而是作大的调整须要投入太多的资源，这个恐怕是普通公司所没法承担的。

突然来一个新的技术经理，接手了这些业务，不去试着解决如今的问题，也不去深刻代码和数据库设计；便先来吐槽框架设计的不够时髦，文档更新的不及时，公司的开发流程不完善等等。这不是懒，不是能力差，又是什么呢？

固然框架也是他们庇护伞。你好比，

某个bug解决不了，那必定是框架设计问题，致使这个问题没有办法解决；想要完全解决这个bug，框架推翻，代码重写，项目历来！
总之全部的问题都是框架引发的，和他们绝无想干的，想要他来解决问题，得按照他们的意思，把项目或者产品推翻重新来过才行。

固然也毫不是说不谈论框架和流程，良好的框架设计和流程对于项目或者产品的发展绝对是有好处的。框架设计和流程也不是一成不变的，也会随着业务变化，可是通常不会是巨变，好比推翻重来的那种变化；而是在兼容以前的业务基础上，渐渐变化，让产品项目有个适应过程，也让围绕这个框架的开发人员有个适应过程。