最近在项目组里面遇到了三件小事，让我重新审视了一下，到底什么是工程思维，工程思维在工作中是怎么发挥作用的。

先说说这三件小事，第一件是一位小伙伴在域名迁移的时候，需要更改服务请求的path。理应来说，如果有调用方在请求这些接口，如果需要进行域名迁移的话，当然是先要对老的路径进行兼容的，但是这位小伙伴觉得既然都在测试阶段就可以直接迁移了，而且服务上线也可以同步改动，不用先兼容后删除。先不说这种想法是不是正确的，单论不做兼容而言，这就很不工程思维，没有站在业务方调用的角度来看这件事。

第二件事是另外一位小伙伴给我们介绍他们的系统，其中登陆模块是他们自己做的，这当然有着产品和技术上面的权衡，本身没有什么毛病。但是在登陆模块中，账户名和密码居然是明文传输和明文存储的，这就不禁让人感觉到十分地疑惑了，我们需要为了时间做到这么极致的简单吗？这个临时方案确实是十分临时了。在这里我看到的是他虽然可以在很短的时间内做出一个完成PM需求的系统，但是后续的安全性和可维护性可能在工程上都很难评估。

第三件事是还有一位前端的小伙伴，在测试的时候，QA同学指出了其中有一些地方跟设计稿不同，或者交互上面不合理的地方。这位小伙伴直接把错误甩给了UI同学，并且在PM指出UI同学没有错误之后，仍会有其他辩解的地方。并且后续在测试途中，还有许多其他的BUG。

可以看出来，这三位小伙伴其实基本能力都不差，并且老实说还挺好的，也不存在很笨，理解不了的情况。但是在合作者的眼里看来，总是欠缺了一点思维，会让别人觉得合作起来比较费劲，在这里，我总结了几点工程思维中需要达到的：

1. 保持对线上的敬畏之心。上线前请检查自己的代码，先通过自己的测试之后再上线。

2. 保持对合作者的同理心。合作者同样也是人，有时候需要多一点换位思考的能力，想想自己所做的东西在合作方的看法，怎么样更加顺畅地合作。

3. 保持对同事的谦虚之心。兼听则明。

4. 保持对技术的进取之心。好好打磨自己的专业能力。

最近在项目组里面遇到了三件小事，让我重新审视了一下，到底什么是工程思维，工程思维在工作中是怎么发挥作用的。

先说说这三件小事，第一件是一位小伙伴在域名迁移的时候，需要更改服务请求的path。理应来说，如果有调用方在请求这些接口，如果需要进行域名迁移的话，当然是先要对老的路径进行兼容的，但是这位小伙伴觉得既然都在测试阶段就可以直接迁移了，而且服务上线也可以同步改动，不用先兼容后删除。先不说这种想法是不是正确的，单论不做兼容而言，这就很不工程思维，没有站在业务方调用的角度来看这件事。

第二件事是另外一位小伙伴给我们介绍他们的系统，其中登陆模块是他们自己做的，这当然有着产品和技术上面的权衡，本身没有什么毛病。但是在登陆模块中，账户名和密码居然是明文传输和明文存储的，这就不禁让人感觉到十分地疑惑了，我们需要为了时间做到这么极致的简单吗？这个临时方案确实是十分临时了。在这里我看到的是他虽然可以在很短的时间内做出一个完成PM需求的系统，但是后续的安全性和可维护性可能在工程上都很难评估。

第三件事是还有一位前端的小伙伴，在测试的时候，QA同学指出了其中有一些地方跟设计稿不同，或者交互上面不合理的地方。这位小伙伴直接把错误甩给了UI同学，并且在PM指出UI同学没有错误之后，仍会有其他辩解的地方。并且后续在测试途中，还有许多其他的BUG。

可以看出来，这三位小伙伴其实基本能力都不差，并且老实说还挺好的，也不存在很笨，理解不了的情况。但是在合作者的眼里看来，总是欠缺了一点思维，会让别人觉得合作起来比较费劲，在这里，我总结了几点工程思维中需要达到的：

1. 保持对线上的敬畏之心。上线前请检查自己的代码，先通过自己的测试之后再上线。

2. 保持对合作者的同理心。合作者同样也是人，有时候需要多一点换位思考的能力，想想自己所做的东西在合作方的看法，怎么样更加顺畅地合作。

3. 保持对同事的谦虚之心。兼听则明。

4. 保持对技术的进取之心。好好打磨自己的专业能力。