发布于 2026-01-06 13 阅读
0

一位“高级开发人员”的想法 DEV 的全球展示挑战赛,由 Mux 呈现:展示你的项目!

一位“资深开发人员”的思考

由 Mux 主办的 DEV 全球展示挑战赛:展示你的项目!

想法

在我的工作单位,我被认为是资深开发人员。最近,我一直在思考“资深软件开发人员”这个职位究竟意味着什么。

我原以为这可能意味着我编写的代码更好,这或许是真的(几个月后我会重新审视我的代码并告诉你结果),但我见过编写出色代码的初级开发人员,也见过编写难以维护代码的高级开发人员。

我原以为这意味着我了解最新最好的东西,但这却是一项永无止境的任务。

我原以为这意味着我完成任务的速度会快很多,但我觉得并非如此。

我原以为这意味着我编写的代码没有错误——但我们都知道所有代码都有错误,这是我们作为人类编写代码并在不可预测的环境中运行的必然结果。

最近我一直在和一些初级开发人员一起工作,他们还在努力寻找自己在团队中的位置。很明显,和初级开发人员一起工作时,他们中的大多数人(就像我们所有人一样)都在寻求肯定和鼓励。这时我突然意识到,高级开发人员的职责是为初级开发人员营造一个支持性的工作环境,让他们可以毫无顾虑地提出任何问题,不必担心被评判;让他们可以坦诚地讨论错误,即使不懂也没关系。

不当行为(我确实有这种行为)

  1. 每当我们遇到不熟悉的、不喜欢的代码或代码风格时,我们都会想(甚至可能会说)类似“这坨屎是谁写的……”之类的话。

  2. git blame(我讨厌“blame”这个名字)使用得太多了——git blame 是一个危险的工具——它可能会将半真半假的信息归咎于现有情况。

  3. 在进行代码审查时——“告诉人们该修改什么”

改变我的行为

  1. 我需要改变一下思路——如果一段代码有测试,那么它就是很棒的代码,可能需要重构!(如果没有测试,嗯……)

  2. 关闭自动 Git blame 功能。我并非一直需要它,只有当我想就那行代码向编写该代码的人提问时才需要用到。

  3. 写评价时,一定要写至少一件有意义的事——哪怕这件事看起来微不足道或毫无意义。对方或许比你想象的更需要它。

  4. 在给出修改意见时,我会尝试通过提问而不是提供解决方案来鼓励大家讨论我认为需要改进的地方。

  5. 我希望能够让下一位开发人员能够更好地处理我编写的代码,比我最初编写时更好一些。

  6. 最重要的是——当有人问我问题时,我希望让他们觉得这个问题值得一提。

最后想说的

在我看来,高级开发人员并非是编写出最好代码的人(这当然有帮助),而是那些不会妄下评判、愿意耐心解答问题,并且最重要的是,能够体会“卡住”或“迷茫”感受的开发人员。

文章来源:https://dev.to/orrgottlieb/thoughts-of-a-senior-developer-3ja7