楼主所有的部门，前任leader在考虑做服务化时，把本部门的基础代码拆分为了三分部：其中vendor存放在一个git项目中，里面通过composer管理依赖，主要是YII2框架和Phpoffice,jpgraph等等组件。project是每个项目一个单独的git，存放的是项目自己的业务逻辑代码。最后上线的脚本是从三个git拉代码合并。后面你发现companyLibrary里面的某个方法实现不够好，或者存在隐藏的BUG，你却不敢修复了。
代码内联方式?不管你用什么语言，在开发中大家总会抽出公用代码库，做为公司中各项目公共使用的内容，并且可能在大家的业绩表现中会主动提到自己抽取了什么公共代码之类的可是当抽取不合理，或者架构不合理时，你会遇到本文描述的问题：小小的公用代码，大大的耦合，我来为大家科普一下关于代码内联方式?以下内容希望对你有帮助!
代码内联方式
不管你用什么语言，在开发中大家总会抽出公用代码库，做为公司中各项目公共使用的内容，并且可能在大家的业绩表现中会主动提到自己抽取了什么公共代码之类的。可是当抽取不合理，或者架构不合理时，你会遇到本文描述的问题：小小的公用代码，大大的耦合！
楼主所有的部门，前任leader在考虑做服务化时，把本部门的基础代码拆分为了三分部：
其中vendor存放在一个git项目中，里面通过composer管理依赖，主要是YII2框架和Phpoffice,jpgraph等等组件。
companyLibrary是另外一个git项目，里面存放的是公用的助手类（文件处理、日志处理、图像处理、邮件等），公司其他服务项目请求类（比如我在A事业部，我们有10个项目，可能都会去调用B事业部的xxx服务，那么会把这个调用逻辑放在公用代码库里面），各种基类（控制器，Action, Service, Model）。
project是每个项目一个单独的git，存放的是项目自己的业务逻辑代码。
最后上线的脚本是从三个git拉代码合并。一开始只有两三个项目公用companyLibrary,vendor还好，当项目变成五个，十个的时候，这个时候有一天，我们在vendor里面添加了一个新的第三方库，顺便执行了下composer update,Yii2升级了一个版本，就这样，谁也没想到一个小小的版本升级，从2.0.12升级到2.0.13而已，最后却导致了线上事故。原因是YII2为了兼容PHP7.2，废弃了Object类，改名 BaseObject,并且增加了抽象方法。
后面你发现companyLibrary里面的某个方法实现不够好，或者存在隐藏的BUG，你却不敢修复了。
不合理的代码抽象和公用导致了灾难。要公用的代码一定是基础的助手类等，并且公用代码的复用应该是每个项目单独一个拷贝，可以单独改变和独立发展。
