工程师硬通货系列一：让自己职业化

职场硬通货来帮你寻找答案！职场硬通货系列旨在帮助在职的工程师们明确行业边界，了解自己应该学习哪些技能，如何掌握这些技能；不断提升核心竞争力，让职业发展的道路越走越宽，从而成就更好的自己！

源起于序言中的故事，我正在砌一堵墙、盖房子、造家园。同样的搬砖，可以有不同的心态；不同的心态，指引我们对自己不同的要求。

我们每天在做什么？这个 if/else 怎么写，那个 sql 应该怎么拼。把墙砌的完是一个很简单的工作，可以用一条 sql 完成整个功能，可以用一个 for 循环遍历所有接口，可以肆意的 CRUD：为了目的，可以不择手段。停留在一个码农，我们只要有一定语言知识，不多编码经验足以。以此，明天我们继续砌墙……

如果把它当成一个房子。你的代码，恰是在修缮你每天睡觉的屋子。我们还可以做点什么？是不是应该换个软垫子睡觉更舒服（想这个函数怎么写的性能更好），东西放进橱子会更加利索（模块调整下封装会更加严谨），来个欧式风格更浪漫（学点“设计模式” 来依样画葫芦）。这些做法可以让我们的代码闪动那么几丝灵动，可是往往全局观不足。而全局意识，恰恰应该是一个最重要的工程师素养。

反思我们的工作，我只要写代码把 PM 让的实现。就行了吗？

• 我们有多少个上线之后没有任何效果的需求

• 我们有多少次焦头烂额的应对事故

• 我有多少次上线中的紧急回滚

• 用心看过几个 CodeReview？几个 CodeReview 被打回？但有多少次对着代码 TDM ！

• ……

这一切都是你的债务！一个有素养的工程师，不会容忍他的工程被如此的亵渎。为什么要拥有全局意识？不是交差就行，这是我们的房子，这是我们的家园。

做一个有素养的工程师：时刻体现你的专业、全局、靠谱。

首先，对接需求，要明确为什么要这样，预期的价值是什么。我们有义务帮助产品找到最恰当的解决方案，然后用合理的方式把方案嵌入到代码中。

其次，代码可视化设计。应该先考虑怎么去做监控。不能迷迷糊糊地在线上跑着，“它应该是对的吧”……  越实时的反馈，越可以早得发现问题，越可以早止损。是对工作的负责，更是对自己汗水的负责：谁也不想自己辛勤写出来的代码，直到下线那天才发现一直没有运行“对过”。

• 哪些指标，证明功能是 ok 的

• 哪些报警，证明这是个 bug，那里肯定挂了

• 哪些指标，证明这个需求是有价值的

第三，确保新的代码没把架构变矬。完成前两步，就可以着手设计我们的功能框架。不是写个 function 把逻辑写完就行。所谓的架构，就是为了完成一套完整的功能，合理组合的多个模块。

依旧是全局意识，要让你的代码更好的被后人看懂，要在恰当的地方完成业务监控，要用恰当的逻辑为应急提供方便。“逻辑”谁都能写完，但是要让别人觉得，这块代码本来就应该在这里。衡量代码质量的唯一有效标准：WTF/min —— 《Clean Code》。我们应该努力拽着自己的项目，让它离“屎”远一点。

第四，何时提交 CodeReview，学会 CodeReview。合理的 CodeReview 应该分成四步。

1. 按需求调整代码架构，尽量早的提交框架 diff。评审者主要关注：改动是否污染了架构，是否增加了学习成本

2. 填充架构细节，“优雅”地实现各模块逻辑。评审者主要关注：功能拆分是否清晰，类是否抽象合理、是否符合语法习惯

3. 确认各模块逻辑无异常、无 bad case。评审者主要关注：功能是否完全覆盖单元测试、是否已经完成了联调、是否进行了完善的功能测试

4. 确保代码细节。评审者主要关注：是否合理的捕捉了第三方工具的异常，是否有合理的功能降级、模块降级，循环是否合理(严防死循环)，变量命名是否表义、变量作用域是否过大……

合理有 code review 应该把握大框，逐步细化，渐入佳境。尤其是新接手的项目，不要盲目的快速写代码（遇到过太多 bad case，咣咣写完了，新代码与架构不合打回重写）。

第五，确认好依赖，让改动平滑上线

除非你在写 print "hello world"，否则，你的功能与各种上下游服务势必会有千丝万缕的联系。我们必须在上线前，确认好所有的依赖不会 block 我们。

首先，要检查自身是否有先验逻辑未就绪：你新加的 feature 上游是否适配。

其次，要检查下游逻辑是否已经就绪：下游服务功能是否正常上线，是否能承担我们的请求压力

代码编写其实没有难度。哪怕是个小白，在培训班学呆半个月，就可以实现个小功能，而工程师素养，才是衡量我们能不能在这个行业走深走远的关键。

时刻体现你的专业、全局、靠谱，这也是升职加薪的秘诀。