文章更新于 01 Nov 2024

有幸读到了 ‘Candost’ 的博客：on-good-software-engineers，并且产生了很多感悟。

我在最近(2024)的一段职业生涯中躺了很多坑，其中一些经验教训，我把它们写出来，每年我会尝试 Review 并且 Ref 到这篇文章，看看我是否有长进。

影响他人 & 被他人影响

2023 年我在旷视的时候遇到一位同事，他看似脾气不是很好，但是他会非常耐心的一遍又一遍的 Review 我代码中的错误，他的耐心感染了我，面对铺面而来的几十个 comments 我一开始感到沮丧，我一边修改一边看到他一遍一遍的 review 并再次纠正我代码中一些因为粗心导致的错误，我觉得自己很糟糕，做的不好而且很不认真，从那以后我发誓我在写代码的时候将更加认真。

他并没有“教”我要认真，仅仅是一遍又一遍的找出一些低级的错误，就震撼了我，从那之后，我做事情变得更加认真。做设计的时候考虑更加仔细、写代码的时候更加谨慎小心，帮别人 Review 的时候我也会非常认真仔细的看……

我举这个例子，不只是为了说明 Review 代码以及认真的重要性，而是说当处在一个团队当中时，你的行为会潜移默化的影响到其他人。你如果想将你的某个习惯、价值观介绍给别人，你只需要通过默默的这样做，就可以一定程度的给他人带来正面的影响。

同时，不管 Title 是怎样的，大家都是相互值得学习的，当你领略到别人在某个方面有很不错的素质时，也可以虚心请教、大胆学习，得到这种良好的素质。

工程设计 > 工程开发

2024 年我因为自己判断错误（以为项目生命周期短、上线时间紧）导致误将一个相对复杂的实例管理服务当作一个简单的业务来开发了，没有提前做好模块的分层设计。

这导致了很多问题：

• 新增一个功能将修改大量的代码，并且同时产生大量的 bug
• 没有按照模块分层抽象，导致同样的操作不同人来写，写出来的代码各有不同
• 我们系统要对接一个外部的系统，但是我们过早的对接，导致被外部系统影响了我们内部的实现，进一步导致被外部系统牵着鼻子走

Good engineers understand the processes they are operating in while taking a project from an idea to a solution – Be selected from [on-good-software-engineers]

无论是重新写一个东西，还是重构一个东西，看似简单的事情如果没有提前进行模块拆分，开发进行到中后期则有可能会进入我之前躺过那片浑水。

沟通也很重要

我之前的问题就是没有适应字节这边的这种环境，你需要去 Push 其他人配合你的工作，也许其他人有大量的工作要做，但是作为这个项目的 Owner 你必须足够 strong，保证你的项目按时落地，不要尝试 delay 自己宽限他人，如果你是一个很 “nice” 的人，在这件事上不够坚定，就容易吃亏。

在开始做一件事之前，如果没有 kickoff 或者约定多久回归 & 对齐一次的话，你自己要默默设置好里程碑，每周自己审视，自己有没有在对应的时间内完成里程碑上的事项，如果没有则必须警觉，拉相关的人重新修改计划，并且 review 之前没完成的 gap 到底在哪里，否则这些milestone 就会向 TODOList 里的 item 一样，成为一堆烂泥，最后公司或者其他人要为这堆烂泥买单。

如果你身处在一个压力很大的环境中，其他人都有很多其他的自己的任务，这些事情的人力安排可能早就超过了 1 个人本身的人力（这样的安排本身是毫无意义的）。但是如果和你合作的人无法按时达成你和TA设置的某个条件，你需要去和TA soical，看看能不能为你项目多争取一些 TA 的投入。如果还是不行，则你需要尽快把事情往上反馈，push 你的负责人去联系他的负责人，尽快把你解决不了的问题抛出来。

坚持第一性原则

如果你需要做一件事，例如：对接一个系统、开发一个模块、开发一个系统、重构一个系统等，你都要去了解这件事背后推动它发生的第一个原因。

如果你不了解这件事的背景，这件事很有可能无疾而终，千万不要觉：“得你只是个小兵，无需了解更加细节的内容。” 一旦让你负责去做的事情，一定要弄清楚原因，否则是一定会踩坑的。

为什么要弄清楚原因呢？因为也许你看到的要做的事情只是一个表象，例如：老板让你去重构一个系统，你可能假设一个前提就是重构是一定要做，然后去做。这时候你要仔细想想为什么要重构这个系统？第一原因是什么？原来的系统有什么缺陷、问题等等。

如果你没有弄清楚原始的原因，仅仅听从命令去盲目的重构一个系统，很有可能等你重构完了，你不会看到它比过去的版本有什么进步，甚至比之前还要差劲。

我在去年就犯了这个错误，接受到重构系统的任务之后，告诉我这个系统很简单，原来的系统很难维护了（代码质量很差）让我以最快的速度实现了新版的系统，我没有花时间去思考这个问题。

很快，“报应”就来了，开发进入一定阶段之后，我开始思考重构的原因，发现一定程度上是为了重构而重构，重构的新版本并没有显著优于原始版本。大量没有考虑到的点开始出现，对接的其他框架开始重构，我们不得不在开发完成之前就二次重构以对接新的框架……

总之句这个例子除了说我笨之外，还是要回归小标题，开始做事之前一定要弄清楚原因！

环境在变化，策略方法不是一成不变

我说一个情况经常发生在新入职的时候，某某同事刚刚入职。如果是从大公司大小公司，那么就会发现流程不规范，基础实施建设不全等问题；如果是从小公司到大公司，就会发现繁文缛节多，基础设施过于臃肿，开发简单的功能就要对接大量的基础设施；甚至从一个大公司到另一个大公司，会发现所谓的字节风变成了阿里味啥的。

我们像变色龙一样，在不同的环境下，有着不同的策略。例如当遇到流程不规范、不清晰时，如果想要提出一个新的流程，要遵守“第一性原则”——如无必要，勿增实体。先想好提出流程要解决什么问题，这个问题是否可以用别的更简单的方式解决。由俭入奢易，由奢入俭难，目的是规范清晰简单。

在大团队里的一些形式照搬到小团队里不一定能起作用；小团队里紧凑的运作方式，在更大的团队里也不一定能work。

总结

在过去的一年里工作有些许痛苦，我终于理解到进步源于痛苦。过去的一年里，在技术上，我并没有任何进步，但是技术之外我成长了不少。

我会把上面说的事情做成一个 Check List，每年用来 Check 自己是否在往一个好的工程师方向发展。

共勉