微软、谷歌、阿里等大厂是如何应用软件工程的
我们无论是否在大厂工作，都有很多途径了解到大厂是如何应用软件工程的，网上已经有很多分享，我们可能更像知道：从大厂应用软件工程的实践中，我们能学习到什么，又该如何学习借鉴。
每个公司都有自己的历史和文化，他们的文化又影响了各自的软件开发模式。
例如谷歌，谷歌崇尚工程师文化，招聘来的工程师都是万一挑一的，开发也没有太大的进度压力，所以google的工程师做项目不紧不慢，质量优先，有统一的代码规范，严格的代码审查和严谨的自动化测试，还会频繁地重写系统，每过几年，就把系统重构一遍。
再比如Facebook，Facebook有一种黑客精神，创始人马克.扎克伯格有句名言：“Move Fast and Break Things”，也就是说快速做出产品，不要怕犯错，所以Facebook的工程师做软件开发的时候不会想太多，先实现再说，做出来就发布，哪怕有bug，后续根据用户的反馈不断完善，真的弄坏了线上功能，再打补丁去修复。
但是这些带有各自文化特色的部分，却是我们很难学习借鉴的，因为这样的文化只适合各自的公司。假设让微软去学习Facebook的黑客精神，发布带有很多Bug的Windows，那么用户是不能忍受的；而让普通公司去学Google的工程师文化，项目没有严格的Dead Line，系统隔个几年就重写一遍，那公司恐怕也都撑不住。
所以，要学习大厂，你要多去关注大厂们对软件工程实践共通的地方，可以应用在你自己项目的地方，另外还要去看大厂对软件工程实践的变化趋势，在朝什么方向发展。通常这些大厂的很多实践都是业界的风向标，一旦一些实践大厂都在应用，那么很多中小厂就会跟风，最终变成行业标准。
软件项目开发团队组成
软件项目开发最终是落实到“人”上面，大厂在招人方面一向舍得投入，不仅花很多人力财力在招聘上，同样对于员工待遇也是很大方，只为找到最优秀的人才。
对于普通公司和团队而言，很难像大厂那样有一群行业内顶尖的人才，但是它在软件团队的一些管理和实践方面，还是有一些共通的地方，有值得普通公司学习借鉴之处。
- 软件开发团队在组成
网上曾有一张流传甚广的关于各大公司的组织结构图
这张图形象生动的描述了各大公司的组织结构，各具特色。然而这些大厂的组织结构具体细分到软件项目开发团队时，是惊人相似的：那就是一个软件项目开发团队都不会太大，一般不会超过10个人，如果超过就会拆分，最著名的就是亚马逊的“两个披萨原则”，也就是团队的人数不应该多到让两个披萨不够吃。
其实大厂的软件项目都采用小团队的原因很好理解，那就是团队规模越大，交流就越复杂，成本也越高！要想沟通更搞笑，那么就要求团队的规模必须足够小。
组织架构的小型化也会对软件架构有影响，通过架构的隔离，让各个不同的团队可以在一起高效地协作，如果你所在团队规模大沟通效率不高，那么可以考虑向大厂学习，分拆成小团队，可以有效提高沟通协作的效率。
- 没有专职测试
现在像微软、谷歌、Facebook、阿里这些大厂，都没有专职的测试人员。
没有专职测试人员不代表他们不重视质量，只是他们用更高效的方式来代替人工“点点点”的手工测试，Facebook能做到没有专职测试人员，是因为他们有大量的自动化测试；另外Facebook在功能发布之前，现在内部使用，上线之后能做到有效监控，出现问题能及时回滚或者打补丁。
大厂替代专职测试的这些手段，对于普通公司来说，可能现阶段去实施是有难度的，但是随着这些发布、监控工具的不断普及，自动化测试的普及，开发团队不设置专职测试会逐步变成一种趋势，现在的手工测试将来也许会逐步淘汰。
- DevOps文化
DevOps本质上就是一种紧密协作的工作方式，让运维人员和开发人员协作更加紧密，有效提高编码效率、质量和产量。如果你的团队也存在不同工种之间协作的矛盾和冲突，不放借鉴一下大厂对DevOps的实践。
开发工具的使用
大厂钟爱自己造轮子，对开发工具也是如此，都有一个专门的部门去做内部工具的开发和维护。
如果你有幸在一个大厂工作，你会很幸福，基本上开发过程中，各种像编译、部署、持续集成等等都有好用的工具可以帮助你自动化，提升效率，你只要专注于写代码就可以了，然而一旦离开大厂，你会发现这些日常工具都需要自己去搭建，甚至得自己去写。
还好大厂用的这些主要工具，你在网上几乎都可以找到开源的或商业的替代品，只是没有那么好用而已。所以我们可以看得出：这些大厂舍得在工具上投入，应用工具，也确实可以有效地提升效率，改进软件项目质量。