360的开源软件使用以及开源文化构建经验

后面有几个开发的同事觉得要跳出这个糟糕的循环，于是就在新模块的开发中引入了OpenResty和Yii，并和自研的组件并存。这样带来 的明显好处是效率的提升，开发有精力来完成了前后端分离，QA也从完全的黑盒测试中脱身，搭建了服务端的自动化测试和性能测试。这些改变为后面重构打下了 坚实的基础。

在第三个阶段，我们重构了产品，并统一了服务端的技术架构，同时相关的功能组件全部换用成熟的开源软件搭建。比如我们使用 OpenResty来搭建整个服务端，周边工具用Python和Go来完成，报表和数据分析采用ElasticSearch。这样开发就可以更专注于产品 功能实现和开源软件的深入学习，而不用担心基础组件的稳定性。

温铭：很多时候，『造轮子』的原因是开发人员没有找到合适的开源软件，或者在技术方面自视过高。盲目的自己从头开发组件，时间成本、稳定性以及后续的维护 都是问题。我认为『造轮子』的前提是，现有的成熟开源软件不满足你的需求。比如360云查杀对性能要求非常高，而当时没有开源软件符合需求，所以我们就在 LevelDB的基础上面开发自己的Key-Value数据库。而对于大部分的服务端开发来说，开源软件足以应付相关需求。

温铭：360企业安全服务端有一个特殊的产品需求，是其它产品的服务端开发不会遇到的，就是需要支持Windows平台。因为很多企业还是希望软件运行在 Windows上面。所以我们会对一些开源软件进行修改，以增加对Windows平台的支持。我们刚开始的做法是下载源代码，然后修改，但造成的问题是没 法快速跟进开源软件版本的更新，也没法把修改的代码回馈到社区。现在我们会fork，然后把改动pull request向社区来回馈代码，同时要有完善的测试案例和文档，代码要符合软件本身的编码风格。

温铭：360在GitHub上面开源了多个自己开发的软件，公司内部有技术评级以及定期的技术嘉年华，鼓励工程师主动分享技术并参与到开源软件中去。在技 术团队中，透明和平等的文化，最适合各种技术的成长。我们团队有一个不成文的规定：AKA（all know all）。比如在技术选型上，我们会出一个大概的架构，然后发给所有开发讨论，由于我们是一个大杂烩的技术团队，有人说“PHP是最好的语言”，有人是 Python的粉丝，还有人推崇Go，还有人坚守Windows平台，所以各种讨（chao）论（jia）后才确定最后的选型。

温铭：即使不去修改开源软件的代码，团队成员也需要对这些软件的内部实现有深入的了解，才能用到适合的场合以及做参数的调整。我们每周会有定期的技术分享和code review，来保证团队每个人都知道团队使用了哪些技术，如何更好使用这些技术。

温铭：最重要的是要团队成员有主动性和热情参与其中。并不是贡献了patch才算参与到开源软件中，在实际的开发中解决了问题，总结分享出来，也是一种方 式。我们团队正在GitBook上面写关于OpenResty和ElasticSearch的书，分享我们的一些实践。这也是一种参与开源的方式。