如何理解工程师文化

近期公司技术中心在内部发起了工程师文化调研，旨在创造一流的工程师文化氛围，提高团队金融科技能力的强大战斗力文化，随心写了对工程师文化的见解。

一、什么是工程师文化

什么是工程师文化，以下有几个选项

**a.一切以解决问题为导向的工作文化

b.以自我学习驱动，能学习到更多技术与进行技术实践的工作文化

c.以业务为基准，解决业务需求为导向的工作文化**

a这个选项明显优于其他两个选项，b，c具有一定的偏颇，b太强调自我驱动，少了业务应用的场景，如果业务应用与自我驱动相冲突，那就放弃实际业务场景，运用全新的技术？这样会徒增风险与成本。c太偏重业务，我们工程师固然需要为实际的业务需求方制作出优良的技术产品，但我们的工匠精神不能丢弃，不然后面坑的还是自己，不能为了开发而开发。

二、怎么落地这项工程师文化？

a）code review ， 团队内部一定要code review

为了赶工期，或者需求不断变化，而写出来的代码，多数情况下是“惨不忍睹”的，即使已经准备了Framework，做了规范和范例，也很难彻底避免。因为大量的问题，不是“不好用”（因为可以通过测试），而是“有隐患”，包括性能/可维护性，乃至于潜藏的BUG（比如最近鼎鼎有名的Heartbleed？）。而这个时候，通过同行评审、代码review，这些问题可以被指出来。甚至通过讨论，可以直接得出更高效的代码编写方法，这对于参与review的普通成员来说，是一个非常好的学习机会。

以下是在无code review环境下工作的一些亲身体会：

1、更容易写出功能正常但结构混乱、可读性差的代码

2、随着人员的流动，这些代码迅速衰变为“遗留代码”

3、由于没有code review，除作者外了解同一段代码的人不多，有能力维护遗留代码的人员稀缺

4、由于结构混乱、可读性差，新人不愿意维护遗留代码

5、相较于维护遗留代码，新人更乐于中国式重构——推翻重写重构（xie）后的代码或许比原有遗留代码质量更好，但在缺乏code review的情况下仍然迅速衰变为结构混乱、可读性差的代码

6、如果推翻重写的欲望得不到满足，不得不维护遗留系统，则工作乐趣降低，加速人员流失

7、Code review原本是整个流程中不可或缺且较为耗时的一个质量保证环节，省略之后给合作方造成单位时间生产效率更高的假象，提升需求提出速度、压低任务完成时限

b）内部干货分享

我们公司将内部分享的安排直接下放下去，这周什么时间什么部门分享，然后直接上，公司技术人员400多人，基本就是1年一次，直接分派到部门，也是行之有效的。

形式：一定要有网络直播形式

网络直播才能让足够多的人受益这份分享的干货知识，这也是互联网时代的优秀分享形式啊。不然会议室只能有十几个人听到分享，分享的效果就大大降低了呀。