有言在先
一个团队的文化氛围往往决定了团队的作战方式，发展方向。对于技术团队工程师文化浓厚是非常容易吸引人的，当然更吸引人才。这是很多团队都想要的，但是文化的积累是非常困难的。首先技术团队都得做业务，业务往往会占住很多时间，精力会分散，容易疲惫。其次一些技术使用或者开发的内容往往被封锁在一个小圈子里，想学习的人接触不到，即使进行技术分享，也不能深入底层，往往草草了事，看似提高的技术的氛围，其实因时间久了，慢慢也就麻木了，容易丧失技术的引力。
关于如何建立工程师文化，可以谈一下我们的经验
我们会用很多的时间来开发业务，而业务也的确是我们工作的重点，完全不能抛开业务空谈技术进步，这种技术的意义其实就是纸上谈兵，最佳的方式是快速学习快速实践，允许试错，逐步优化，其实我们发现最好的点就是如何把业务和技术结合起来，通过技术降低业务的难度，从而提高学习的时间。分享技术，让代码和思想都能得到升华
工具化，框架化
我们团队内部会每天早上开站立会，除了每日说明下昨日和今日工作情况，另外还会讨论收集下目前工作中的难点和最耽误时间的工作部分。然后后面一部分工作的内容就是如何通过技术来简化这部分工作，通过团队讨论加自我驱动，不断思考如何创新，优化目前的业务，让开发变得更简单，让人员有更多的时间去深入技术底层。
每天我们消耗很大的精力来线上查看日志，来确定生产的问题，当初程序还很简单，只是两台服务器做了负载均衡，查看日志还算简单，几个linux命令一组合便可以轻松检索出日志，但是随着业务增长，服务器开始变多，项目也逐渐变成服务化，分布式化，请求不一定会分散的服务器变多，日志变多更难查找，排序等都是问题，我们现在迫不及待的需要一个日志工具，把日志各台机器上汇总到一台机器上，然后通过grep命令来查找我们想要的日志内容。
但是问题随之而来就是通过grep会越来越复杂，比如日志所在的文件夹过多，日志又经过压缩导致命令执行起来效率并不是很高，而且对于大段大段的有上下文的日志，不能很好的展示，所以我们就是建立一个索引，这样方便我们用web展示，另外经过我们的优化结合业务场景，日志的展示效果也得到突破，基本原来查日志需要半个小时到1个小时的时间，现在基本1分钟搞定。
另外基于这套日志系统，围绕日志内容，我们开辟出了报警系统，统计系统。日志系统研发过程中，需要学习和研究很多的技术细节，并持续优化和改进，现在发现我们的同步日志有时候会出现不稳定的情况，索引创建的也越来越大，需要将日志计划向比较成熟的ELK上靠拢，研究其长处，并结合我们的系统持续发挥日志系统的特长。
开发中会使用很多成熟的开源项目，我们会结合业务使用场景对其进行扩展优化，让框架适应我们，而不是我们去适应框架。针对一些比较复杂的业务也会自己开发框架，以便简化了业务开发流程。日志中记录业务id，是个很普通到不能再普通的需求，但是业务需要在所有日志每一行记录一下业务id，甚至异常堆栈的每一行都有业务id，我们扩展了logback，以便开发人员根本不在意打印的日志内容是不是带换行符，都可以在每一行的行首自动加入业务id。
针对一些流程模块比较复用的业务，我们开发了模块自动组合调度框架，可以将原本需要在业务中写死的调度关系，抽象到XML中，通过在XML中简单配置，就可以实现节点功能的组合，并提供循环，条件判断等简单逻辑。
这其中很多想法，都是团队成员在业务开发中逐步提出的，并充分利用工作间隙开发出来，目前看来这些工作反而提高工作效率，也降低了工作强度。
适时的重构
一个项目运行久了，经过业务需求的迭代，经过很多名开发人员的变更，总会产生一些让人不太满意的代码，要么来源于对某些业务理解的不太深，要么来源于对一些紧急变更的后遗症，我们在团队内部总是强调，尽量避免凑活，追求性能极致，追求简单美，往往遇到这种情况，我们会适时的引入重构，避免破窗效应，让一个项目越来越杂乱。
重构其实不仅可以重新梳理下我们的业务场景，梳理我们代码的逻辑，让其更贴合业务，更重要的是可以让开发人员有机会再次设计我们的系统，结合一些更好的开源项目和技术，提升团队的技术氛围。
每一次重构其实对于一个项目来说都是无比艰难的决定，上有新业务的需求，下有重构的使命，时间紧迫，希望得到很好的效果，压力都会比较大。但是就是这种环境很容易锻炼人，使人飞速成长，通力合作，团队也会得到很好的磨练。
1.首先我们考虑先要梳理项目的痛点，重构其实更重要是解决现在的实际问题。
日志混乱：记录的自定义格式千奇百怪，关键入参和返回结果打印不全，生产运维困难，不能很快的找到一个业务流程，需要在上下文中筛选。
缺少数据字典：导致每个名词的定义各有不同，但字面意思相近，变量千奇百怪，不方便维护。
新业务添加复杂：相近的业务代码，没有抽象，导致新增要通过复制粘贴，然后调整差异的地方，导致开发工作量大，bug频出。
工具类多：每个人都各自添加各自的，其他人不知如何使用。
废弃代码多：废弃代码不知道是否有用，方法写了，看不到引用的地方，不想删也不敢删。
代码由于业务的不断改进，逻辑已经不再那么清晰。
……
2.提出更高要求，例如提高项目承载能力，应对更大业务需求。
制定明确的开发规则，例如同层之间不允许互相调用，日志的打印细则。
明确接口，SQL的含义，避免模棱两可的情况出现，更能精确的优化。
频繁请求的热数据考虑加入缓存及更新机制。
合理的优化框架，让业务代码更加纯粹。
根据上面的总结汇总设计重构方案，并制定开发计划，白天开发，晚上review代码，总结调整方案。引入新的技术和新的理念。新技术对于程序员来说是有很大吸引力的，化被动学习为主动学习，技术气氛浓厚。新的理念的引入，化解了很多旧有问题，改变了旧有开发方式，让业务代码更简单。最重要的代码再次回到开发人员的掌控中。
强化的技术氛围
其实前面介绍的工具化，框架化和实时重构，本质上其实是简化了我们的运维成本，同时也提高了大家对技术的钻研兴趣，用学习的技术解决实际的生产问题。另外还有挺重要一点就是平时工作中多鼓励大家钻研技术，鼓励刨根问题，鼓励知识共享。鼓励思维创新，鼓励组建技术小组，攻克技术难点。开展黑客马拉松，强调竞争，合理奖赏。另外在工作之外，会组织一些游戏竞赛，一来放松心情缓解疲劳，一来团队合作增加彼此了解。
经验总结
其实工程师文化就是一种放松的，自我驱动的技术文化，在这种文化下，通过成员的自我创新，通过技术手段，降低工作强度，优化业务数据，将技术与生产的需要相结合，并做到极致，从而使人在这个环境中得到飞速成长，团队也飞速进步。工具化，框架化强调DRY原则，避免重复，提高工作效率。实时重构避免代码质量恶化，重新设计提升代码品质。技术氛围创造来良好的环境，促进工程师文化持久留存，人人受益，团队才会受益。