---
title: 过去三年：成为更专业的工程师
category: 项目经验
---

<summary>TBD.</summary> 

过去三年，我一直在一个投行下面做项目，有一年的时间一个人在深圳与香港的开发团队远程工作。说来有趣，一开始到这个项目上来，是因为我觉得我在上一个银行2B的项目上待了太长的时间（10个月），有点进入了舒适区，但没想到来到这边一待就是三年。在这些个项目上，我与很多优秀的人合作，养成了很多好的习惯，相比于技术本身，我养成了更多如何成为一个更专业工程师所必须的素养。

### 专业性

我现在觉得，专业是对一个工程师最好的赞赏。专业就代表着可靠，该你完成的事情别人就一定可以信任你。如果每个人都可以在自己的工作范围内做到足够的专业，别人就不需要担心你关键时刻掉链子，团队之间的协作就会更顺畅。那么，所谓的“专业”，指的是什么呢？

我觉得“专业”指的就是**细节**。在所有的细节上考虑周到，这里头不仅包括技术上的细节，也包括非技术上的细节。比如，我举一些例子，其中有些事情因为跟技术没有关系，往往很容易被技术人员所忽略：

* 当你要请假的时候，你应该做什么事情？
* 当你找别人聊天/发IM的时候，你应该如何开头？
* 当你表达观点的时候（尤其通过邮件），如何让别人更容易接受/更无法拒绝？
* 当你处理生产问题（production support）的时候（比如有用户发邮件抱怨无法登录系统），简单地解决掉出现的问题就算完事了吗？
* 手头上的工作不断涌现（比如还是production support），你应该按什么策略处理呢（比如先进先出还是后进先出）？
* 用英文沟通的时候，如何保证自己的用词没有歧义、不会降低沟通效率呢？
* 站会的时候没提供什么有用的信息（比如说昨天在做重构，今天继续重构。听者就会一堆问题：什么时候能重构完？听着工作量很大，这还是重构吗？为什么要进行这次重构？是必要的吗？重构到什么地方为止？）
* Kickoff一个故事卡的时候，除了考虑代码实现上的问题外，还应该考虑什么东西？
* 写React的时候，状态如何决定放在什么地方（state/context/redux/hooks）？是参考前人代码时他放什么地方你就不假思索也放那里吗？
* 结对的时候，IDE界面放一堆状态条，要找某个文件滑动鼠标慢悠悠地滚着找，透漏着一股不专业的气息（纯键盘、DFM了解下）
* 结对的时候，应该从测试开始还是从实现开始写？
* 解决某个问题时（可以是一个故事卡或一个大epic），一堆方案摆在面前，你应该通过什么方法来确定优先级顺序？
* 这个列表还可以有很长……

总结起来，工程师容易犯的几个不专业的错误，一个是**想当然**，凭仅有的一点线索就自动脑补觉得“应该是这样”，而没有更深入地搜集信息并验证，一深问就发现逻辑链条串不起来；一个是**得过且过**，潜意识里总觉得能跑起来就可以交差了、挺好了；还有一个是沟通时**抓不住重点**，没有第一时间用对方能理解的术语回答对方真正关心的问题，扯一堆技术的术语或是解释原因。

上面这些问题。

### 解决的问题

* code review工具开发
* 前端重构方案
* 性能优化方案实现与数据搜集
* 微服务拆分平滑重构方案
* 应用合并

## 目录

* [](#目录)
* [](#目录)

[Example]: https://www.jianshu.com/p/fdb8c8a604b1