前些日子，跟一哥们儿谈及公司的发展时，谈到了一个很伤心的话题：作为一个软件公司，做了10年的软件开发，居然没有自己的核心框架，这确实也算是个奇葩！
其实这些年，我们一直在规划做公司的核心框架，因为大家都知道一个核心框架对一个软件公司是很重要的。年复一年我们的谈了很多，总是想等研发人员空闲的时候开始做，总是想等成立一个专门的项目团队来实施，总是说的多而没去落实。
我们是一个做项目型的公司，每一年要做很多专门针对各个行业的管理、监控、优化软件。公司有多个项目组，针对性的做了很多软件。每年都有十来个项目提交。因为每个项目组，甚至每个人都有自己的软件编码习惯，导致每个项目都带着自身的浓厚色彩。人员的流失、项目组人员的调整，都需要牺牲很多时间去熟悉别人的代码。维护组成了监控组，因为五花八门的系统让他们也目不暇接，他们只能发现问题，然后把问题转给以前这个模块或者系统的研发人员，由研发人员去修改。于是研发人员不仅要完成新的项目，还需要维护和修改以前的自己做的项目。这样就导致做的项目越多的研发人员越累。长此以往，辛苦不说，没有成绩，没有成就感，导致身心疲惫，最后只能离开公司。因为不熟悉，他一个人的工作需要两个人接手。于是，形成了一个软件界的江湖传说：他匆匆的离开，留下一堆历史遗留问题，任凭后人咒骂，抓狂。
作为主要负责技术这一块儿的小罗罗，我们当然可以过着“大王让我去巡山，巡了北山巡南山”按部就班的日子！各忙各的，一片和谐。回头又一起讨论我们的核心框架，年复一年的谈下去！我们也可以做一个想吃“唐僧肉”的妖怪，闹他个天翻地覆。当然，咱们也有可能被哪路神仙给收了。可不要怕，即使被收了，咱们不是也跟着神仙去了天庭吗！
怎么做？成了一个难题！因为谈及这个问题，我们又要回到现实中来。确实，目前对我们来讲，不可能抽一个专门的团队来花一年或者半年的时间来实施我们的核心框架，虽然大家都知道这个核心框架实施后，对我们有百利无一害。是不是我们就没办法实施了呢？有。目前我们每个项目组都有事，不可能抽人出来，但不是每个项目都忙的不能做点别的有意义的事！我们可以用那么几个爱好者，花点业余时间，做一个小的公共架构，比如组织架构、用户管理、权限管理、日志管理、数据传输等，封装一些公共方法，如导入导出等。然后让大家使用这套架构，每个项目组都使用！使用的过程中不断完善，加入新的公共模块。如此反复，滚雪球的方式，咱们的核心框架包含的功能就越来越多。这是借鉴开源的思想。具体实施步骤如下：
1、制定标准和规范；
2、建立系统基础框架；
3、推广框架，强行推广实施；
4、根据标准，纳入新的模块和方法；
这样做有啥好处呢？我跟一些开发人员谈过这个话题，有些人支持，有些人反对。有些人说，你提供的公共模块，比如统计分析模板，我去配置一个，说不定和我重新写一个花的时间一样。是的表面上看是这样，可是这是建立在自己的习惯基础上的。假设一个开发人员根据自身的习惯建立了一个系统，他肯定对这个系统的结构很熟悉，但如果有一天，他因为某些原因要出差，别人接手他工作的时候，就非常困难。如果还要在他的系统中增加新的功能，那就更难了。如果要交给维护人员去维护，因为每一个系统都带有个人习惯和特色，维护人员需要熟悉每一个系统。他们无法掌握，就不能维护，只能监控。所以，如果咱们能够把这个实施了，至少有以下好处：第一，能够节省时间；第二，使代码可读性强；第三，使系统可交维，可维护。
当然实施并不是上面说的那么简单，需要政策和制度的支持，比如奖励机制。如果能有一个正好也想吃“唐僧肉”的大王支持，说不定就逮住“唐僧”，从此咱们这些巡山的小罗罗，说不定也能“长生不老”。