开场白
作为一个技术团队的Leader，你是如何保证成员的开发环境达到公司的标准，或者是你定制的最低要求的？
如果你的回答是：差不多就行了，有问题再说，那么，你已经在给自己挖坑了。
同事A的开发环境中用的是PHP 7.1，所以他在代码里写了这么一个函数：
function getName(?int $id): string {
return 'name';
}好的，?int 的意思是你的参数必须是数字，但是可以填一个数字以外的特殊类型，那就是null。
同事B用的是PHP 7.0，那么抱歉，他得这么改：
function getName(int $id = null): string {
return 'name';
}?int需要被改成int，因为那是7.1的Nullable语法
同事C用的是 PHP 5.6，好的，继续改吧：
function getName($id = null) {
return 'name';
}所有的类型定于都得移除，沮丧吗？
好的，你作为Leader？怎么选择用哪个同事的代码作为最终输出？可想而知，选择哪个都不合适。
选择 7.1
同事C 在抱怨，要那么高的版本真的好吗？我没用过新特性，也不感兴趣。
选择 7.0
同事A 在抱怨了，新语法多简洁啊，一个 ?int 就搞定了。
选择 5.6
同事A/B 在抱怨，为什么不用强类型，写代码太没乐趣了。
为什么
问题出在Leader，给了成员太多的选择。会有什么后果？
| 优点 | 缺点 |
|---|---|
| 无 | 部分成员的利益受损 |
| 内部意见不统一，产生隔阂 | |
| 可能出现被动学习新知识，生产力下降 | |
| 你的领导能力受到质疑 |
在诱惑面前，人们往往会选择最有利于自己的方式。不要试图去挑战人性，作为Leader的你，必须比任何一个成员都先做出选择。
正题
Docker
我不想讲docker是什么，因为其他人的博客里已经写烂了。
你需要知道的是，你可以把开发环境扔进docker，然后让每个成员忘记自己电脑里的开发环境。至于用了什么版本的php、mysql、linux、nginx、nodeJs，已经固定在docker里了。
你再也不用担心你的成员会用其他版本的环境去写代码了，因为你已经制定了你的规矩。
| 优点 | 缺点 |
|---|---|
| 成员没得选，只能用同一个版本的环境 | Leader需要写Docker配置 |
| 技术方面的交流障碍减少 | |
| 代码符合项目的基本需求，生产力提升 | |
| Leader可以花更多精力在其它事情了 |
Dockerfile
也许你已经写完了所有的Dockerfile配置，并把这些文件放进了项目的根目录dockers/，同时为你的成员写好了一个构建脚本build.sh，接着加入版本控制（git,svn），最后推到git服务器等待成员拉取最新的开发环境。好的，成员们开始构建你定制的开发环境了。
# 构建镜像sh build.sh# 查看构建的镜像docker images# 根据镜像生成容器，仅供参考。本文不讲述docker具体用法docker run -it -d php:7.1 /bin/bash docker run -it -d nginx:1.14.0 /bin/bash docker run -it -d mysql:5.7 /bin/bash
犀利的你可能把生成容器的操作写成一个脚本quick-start.sh，而且用的风声水起。笔者拍拍你的肩膀，同学，为什么不用docker-dompose呢？
Docker Compose
可以这么说吧，这个东西就像是同时启动了多个你想要启动的镜像，而且你还可以同时结束生成的容器。
# 同时启动docker-compose up# 同时结束docker-compose down
是的，很任性，你只需要配置一下你需要启动哪些镜像，然后把配置放到根目录docker-dompose.yml中即可。
结语
可能不算是一篇技术文章，只是抛砖引玉，引导新的Leader怎么带领团队走向正规化的道路。若是真要写那么细，可能10篇都不够写了。有什么技术方面的问题可以在下方留言。