说说协同框架
这里思考的主要是php框架。
最近思考一个点，是什么才是一个好的协同框架？这里说的框架前面的定语加了一个协同，是因为我们这个框架使用，并不是给一个人使用的，而是定位在给超过5个人的范围，大家一起协同使用。我不同意一种说法，框架并无好坏，那是因为没有把框架放到特定场景上。这里说的特定场景，是指的是团队所在的开发环境。比如，现在是一个人在做外包，这个环境下，可以说所有框架都差不多。又比如，是在一个有2-3个服务端人员的初创团队，这里往往大家选择的是大家都比较熟悉容易上手的框架。如果再大一些的环境下，框架所承担的职责就更多了。
基本上，要在一个团队推广一个协同框架，是一种心里博弈的过程。什么应该是写业务的人管的？什么应该是写框架的人管的？@火丁笔记说过，他觉得sina所推行的框架是一个很好的框架架构，因为在那个大框架里面，写业务的人已经简化到只需要负责写增删改查的逻辑，其余的更加底层的都不需要管了。确实深有感触。
往往大一些的团队，会自己开发框架，或者使用基于现有的框架进行修改裁剪等。这个是有原因的。协同框架的作用是为了让“我们”这个团队更上手，那么必然就会根据“我们”的实际情况，对框架有一些偏向性。举个例子，“我们”现在这个团队可能没有线上操作的权限，那个操作权限可能是有公司的ops部门进行统一处理。那么比如像laravel框架中配置使用线上的.env的配置文件的情况，如果生搬硬套使用，那么“我们”就失去了线上配置文件管理的功能。或许把配置文件统一收口到一个项目，并且收口这个项目的查看和修改权限是更好的方法。
现有的php框架基本分为两种，一种是追求运行性能，一种是追求开发效率。追求性能的框架往往很简洁，可能包含的东西也很少，往往一个路由，一个MVC就完事了。甚至可能是C语言编写的。另外一种的是追求开发效率，会封装非常好，很多功能会让你惊叹，也会让你省很多事情。我个人觉得既然是选择使用php作为开发语言的话，开发快往往是项目的第一需求，所以我更倾向于使用第二种追求开发效率的框架。但是呢？这种框架往往有个大而全的倾向。提供了n种路由的方式，提供了n种数据库查询的方法，等等，所以，一般会需要进行修改裁剪才能适合我们自己的情况。
好的协同框架大致需要有几个性子：
1 冲突少
几个团队使用你的框架进行开发，如果你的框架架构上有一个文件覆盖范围非常广，广到不同团队的人都往里面写东西，那么大家最痛苦的就是，git push的时候发现各种需要merge的行为。更不用说有可能产生后面push代码的人把前面的人的代码覆盖的情况了。所以git的冲突次数可以作为一个好的协同框架的衡量标准。
2 掌控力
框架对业务需要有足够的掌控力。基本上，封装越多，掌控力越大。比如你要引入一个service层，那么你设计的时候其实是有两个选择的，你写一个service的抽象类，让业务所有service都继承你的类，或者，业务自己写的service不需要继承任何基类。这个就需要考虑，这个逻辑层是否有掌控的必要？再进一步思考，即使你抽象出来了，你提供的方法是否足够的能力能在以后业务出现大规模需要修改某个逻辑的时候，直接在底层搂住？基本上，掌控力就是代码博弈的心理问题了。
3 监控力
基本上，没人会寄希望业务代码中做请求时长的统计分析，都会希望这个是框架的事情。也一般希望在业务中抛出的异常，框架都会监控的到。并且给予足够的提醒。这个，就是监控力。监控所有的代码性能，异常处理等行为。甚至于，安全的事情，框架也应该有所保护。这个逻辑就是，既然我（业务方）已经答应加入你这个社团了，那么你总要对我的衣食住行进行保护和监控把。
4 引导性
这个是很重要的。团队每个人都会有自己的代码风格和写作习惯。当然，事先做一个规范是必不可少的。但是“堵不如疏”。在堵的同时，应该问问，框架提供了足够好的功能来替换他这个写法了么？在PHP里面，其实不管什么框架，如果一个人坚持自己的代码写法，完全可以跳出框架，再好的框架，一个exit，就能无视所有的框架约束。那么，完成一个功能有好几种方法，你如果推荐大家使用的是最简洁优美的方法，那么，我想，也没人会愿意坚持自己原先WTF的东西了。
5 可扩展性
扩展性分为两个方面，一个是性能扩展，基本要想到如果流量上来了之后，如何水平扩展部署，这个时候框架的改动应该是最小，甚至是没有的。另外一个是功能扩展，现在有个别人写好的或者使用第三方网站的代码，如果这个时候需要你修改autoload的函数，那么这种就是说明框架的扩展性是不够的。功能扩展就像是万能插槽，或许现在没有用上，但是一旦用上，直接插入就好。
6 第三方库的原生性
坚决反对使用了第三方库然后修改第三方库代码的情况。基本上，大家也都不会这么做，保持第三方库的原生性，一方面是为了以后的库升级或者文档说明能同步，另外一方面，则是为了不给以后接收你项目的人制造坑。
7 效率提升
在初期享受了框架带来的便捷之后，总是会遇到井喷期，在井喷期的时候，基本是会需要一次重构的，如果在前期，有事先留好效率提升的方法或者方案的话，那么，这次停止服务开发，重构的成本会大大减小，重构的预期时间也会大大往后推延的。
总结
基本上，协同框架是一个心理博弈的过程，每一个点的选择，都需要思考到“我们”团队的境况和业务的发展需求。拿来主义是错的，全搂主义也是不妥的。如何服务好业务，让业务有更多的空间，但是又不会越界，this is a question。
写完发现，这篇文章好水啊。。。嗯。。。