一个团队的文化氛围往往决定了团队的作战方式，发展方向。对于技术团队工程师文化浓厚是非常容易吸引人的，当然更吸引人才。这是很多团队都想要的，但是文化的积累是非常困难的。首先技术团队都得做业务，业务往往会占住很多时间，精力会分散，容易疲惫。其次一些技术使用或者开发的内容往往被封锁在一个小圈子里，想学习的人接触不到，j2直播，即使进行技术分享，也不能深入底层，往往草草了事，看似提高的技术的氛围，其实因时间久了，慢慢也就麻木了，容易丧失技术的引力。

关于如何建立工程师文化，可以谈一下我们付钱拉团队的经验。

我们会用很多的时间来开发业务，而业务也的确是我们工作的重点，完全不能抛开业务空谈技术进步，这种技术的意义其实就是纸上谈兵，最佳的方式是快速学习快速实践，允许试错，逐步优化，其实我们发现最好的点就是如何把业务和技术结合起来，通过技术降低业务的难度，从而提高学习的时间。分享技术，让代码和思想都能得到升华

　　工具化，框架化

我们团队内部会每天早上开站立会，除了每日说明下昨日和今日工作情况，另外还会讨论收集下目前工作中的难点和最耽误时间的工作部分。然后后面一部分工作的内容就是如何通过技术来简化这部分工作，通过团队讨论加自我驱动，不断思考如何创新，优化目前的业务，让开发变得更简单，让人员有更多的时间去深入技术底层。

每天我们消耗很大的精力来线上查看日志，来确定生产的问题，当初程序还很简单，只是两台服务器做了负载均衡，查看日志还算简单，几个linux命令一组合便可以轻松检索出日志，但是随着业务增长，服务器开始变多，项目也逐渐变成服务化，分布式化，请求不一定会分散的服务器变多，日志变多更难查找，排序等都是问题，我们现在迫不及待的需要一个日志工具，把日志各台机器上汇总到一台机器上，然后通过grep命令来查找我们想要的日志内容。

但是问题随之而来就是通过grep会越来越复杂，比如日志所在的文件夹过多，日志又经过压缩导致命令执行起来效率并不是很高，而且对于大段大段的有上下文的日志，不能很好的展示，所以我们就是建立一个索引，这样方便我们用web展示，另外经过我们的优化结合业务场景，日志的展示效果也得到突破，基本原来查日志需要半个小时到1个小时的时间，现在基本1分钟搞定。

另外基于这套日志系统，围绕日志内容，我们开辟出了报警系统，统计系统。日志系统研发过程中，需要学习和研究很多的技术细节，并持续优化和改进，现在发现我们的同步日志有时候会出现不稳定的情况，索引创建的也越来越大，需要将日志计划向比较成熟的ELK上靠拢，研究其长处，并结合我们的系统持续发挥日志系统的特长。

开发中会使用很多成熟的开源项目，我们会结合业务使用场景对其进行扩展优化，让框架适应我们，而不是我们去适应框架。针对一些比较复杂的业务也会自己开发框架，以便简化了业务开发流程。日志中记录业务id，是个很普通到不能再普通的需求，但是业务需要在所有日志每一行记录一下业务id，甚至异常堆栈的每一行都有业务id，我们扩展了logback，以便开发人员根本不在意打印的日志内容是不是带换行符，都可以在每一行的行首自动加入业务id。

针对一些流程模块比较复用的业务，我们开发了模块自动组合调度框架，可以将原本需要在业务中写死的调度关系，抽象到XML中，通过在XML中简单配置，就可以实现节点功能的组合，并提供循环，条件判断等简单逻辑。

这其中很多想法，都是团队成员在业务开发中逐步提出的，并充分利用工作间隙开发出来，目前看来这些工作反而提高工作效率，也降低了工作强度。

　　适时的重构

一个项目运行久了，经过业务需求的迭代，经过很多名开发人员的变更，总会产生一些让人不太满意的代码，要么来源于对某些业务理解的不太深，要么来源于对一些紧急变更的后遗症，我们在团队内部总是强调，尽量避免凑活，追求性能极致，追求简单美，往往遇到这种情况，我们会适时的引入重构，避免破窗效应，让一个项目越来越杂乱。

重构其实不仅可以重新梳理下我们的业务场景，梳理我们代码的逻辑，让其更贴合业务，更重要的是可以让开发人员有机会再次设计我们的系统，结合一些更好的开源项目和技术，提升团队的技术氛围。