作为软件工程师你永远不应该做的事情

英文原文地址：https://favtutor.com/articles/donts-for-software-engineer/

我已经做了 5 年多的软件工程师。这并不能让我成为专家，但我很确定我犯了足够多的错误来和你分享。以下是作为软件工程师你永远不应该做的 10 件事。

1. 成为完美主义者

没有什么是完美的，我相信也没有“完美的代码”。

软件开发是一个迭代过程。你编写代码、测试它、获得反馈、重构，然后重复。今天有效的东西明天可能不起作用。因此，软件应该灵活且易于更改（这就是为什么它被称为软件）。

我不是说你应该放弃对完美的追求。我只是说你应该在写过于 “死板” 或 “复杂” 的代码时有所察觉。（这一般是发生了过度设计）

专业与完美主义者有很大的不同 —— 对专业更贴近的解释是：大部分时间都处于最佳状态。

2. “请给我一些时间重构！”

代码重构是在不改变其外部行为的情况下重组现有代码的过程。
没有重构的代码将开始 “发臭”，这意味着它将很难被其他开发人员理解或利用。

我们开发人员都知道我们应该在实现功能后经常性的进行重构。
问题是非技术成员不关心这些细节。他们会经常问你 “我们是一家快速增长的公司，所以我希望你先专注于添加功能。”
但是很快代码变得无法维护，你会乞求 “请给我们一些时间重构！”。

不要乞求额外的时间或几天来进行重构。使重构成为功能实现的一部分。

3. 误解“遗留代码（legacy project）”的含义

Web 开发生态系统以快速变化而闻名。
我记得我以前的一个 Web 项目使用 Next. js 版本10。当我开始编写它时，Next.js 版本 11 已经发布，其中包含了新功能和改进。突然间，我的版本 10 项目感觉就像一个“遗留项目”。

很多人将 “遗留代码” 误解为 “旧代码”，但事实并非如此。
根据《Working Effectively with Legacy Code》的作者 Michael Feathers 的说法，遗留代码是没有测试的代码。

如果你不能测试你的代码，你就不能重构它。
如果你不能重构它，你就不能维护它。

“旧的” Next. js 项目实际上有不错的测试覆盖率，一切都运行良好。它是“维护良好的代码”，而不是“遗留代码”。
请不要浪费时间在老项目上更新版本、追逐最新工具，仅仅因为它们是 “新的” 和 “闪亮的”。请记住，Github 仍然在已有 17 年历史的 Ruby on Rails 上运行。

4. “函数式编程是最好的！”

是的，函数式编程是一件新事物——所厉害的人都在用它。但这并不意味着你应该在任何地方使用它。

例如，如果您正在从事 Flutter 项目，在 UI 层中使用函数式编程可能不是一个好主意。
通常，在 UI 层中使用过多的“纯功能”代码会导致性能问题，因为不必要的重新渲染。
Flutter 被设计为以面向对象的编程风格使用，因此您应该以这种方式使用它。

这并不意味着你应该避免函数式编程 —— 或者任何其他很酷的东西。
从同一个例子中，你可以在业务逻辑层使用函数式编程，这更合适。
你需要意识到你正在工作的任务类型和背景，并为这项工作选择正确的工具。

5. 盲目遵循“最佳实践”

干净的架构、SOLID原则、DRY、KISS、YAGNI、TDD、BDD、CI/CD 等。
软件开发中有很多最佳实践。这些都是出于好意发明的，但你不应该盲目地遵循它们。

例如，TDD（测试驱动开发）是确保您的代码按预期工作的好方法。但是，如果您使用 Clojure 或 Python 等对 REPL 友好的语言，您可能不需要对所有事情都执行 TDD。

TDD 的唯一目的是尽快获得代码编写和修改的反馈信息。如果您可以在不编写测试的情况下获得反馈，那么您就不需要进行 TDD（尽管，您应该编写测试！）。

6. 独自为战

我见过很多初级开发人员急于展示自己所谓的 “解决问题的能力”，他们往往在解决一个别人已经解决的问题时很挣扎

请不要成为独自为战的人，不要重新发明轮子。

世界上最伟大的头脑是站在巨人肩膀上的人。

当你开始在团队中工作时，你会意识到你可以从比你更有经验的队友那里学到很多东西。他们是你的“巨人”。跳到他们的肩膀上，不要再浪费时间跳到地上。你现在的目标是瞄准更高的巨人。

7. 陷入无意识的 “心流”

你体验过 “心流” 吗？这是一种你完全沉浸在任务中的心态，感觉精力充沛，注意力集中。
作为一名程序员，陷入“心流” 感觉就像代码在自己编写自己，你只是一个媒介。
如果你体验过这种感受，那就已经进入了心流。

But be careful – you might end up writing “too much” code. I often find myself over-engineering stuff when I am in the “flow”. Not only me, but Robert C. Martin – the author of “Clean Code” – also has experienced counter-productivity while in flow.
但是要小心——你可能最终会编写 “太多” 的代码。
当我处于 “心流” 中时，我经常发现自己过度设计了一些东西。
不仅是我，《Clean Code》的作者 Robert C. Martin 也在心流中经历了 “逆生产率（counter-productivity）” 现象。

为了有意识地打破心流，我建议使用 “番茄工作法”。
这是一种时间管理方法，你工作25分钟，休息5分钟。
它帮助你保持专注，避免倦怠。

8. 忘记工作时运动

做软件工程师并不容易。你会坐在电脑前几个小时，在键盘上打字，盯着屏幕。
当你在 “心流” 中时，很容易忘记你的健康。
但是记住，你的健康是最重要的。
如果你的身体不能正常工作，你的大脑就没有用了。

试着每 30 分钟动一动你的身体（如果你使用番茄工作法，或者25分钟）。
站起来，伸展身体，四处走走，喝点水。
这将有助于你保持专注，避免倦怠。

9. 忘记作为程序员的乐趣

当我第一次开始编码时，我对此非常兴奋。我每天都在建造东西，解决问题，学习新事物。

但是随着时间的推移，我开始忘记编码是多么有趣。
我太专注于编写“干净的代码”、遵循“最佳实践”和解决“难题”。
更多的时候，我不能真正编写 “自己的代码”，因为我太忙于遵循别人和公司的代码。

我的创造力去哪里了？

我知道这很难，但是试着找时间做你自己的项目，学习新事物，建立一些很酷的东西。
试着和志同道合的人交流令人兴奋的新技术，即使你没有在你的项目中使用它们。它将帮助你保持动力和灵感。

10. 退化为 “编码员”，而不是软件工程师

There’s a difference between being a “coder” and a “software engineer”. A coder is someone who writes code, while a software engineer is someone who solves problems using code. I’ve got 2 strong reasons why you shouldn’t be a coder:
“编码员”和“软件工程师”是有区别的。

编码员是编写代码的人，而软件工程师是使用代码解决问题的人。

我有两个强烈的理由说明你不应该成为编码员：

• 所谓的 “编码员” 在未来将被人工智能取代（实际上，他们已经被取代了）。我知道这说起来有些争议，但可悲的是，这是真的。
• 没有人关心你的代码，他们在意的是你解决问题的能力。

做一个使用代码作为工具的 “问题解决者”。
了解问题，找到最佳解决方案，并使用代码实现它。
这就是软件工程师所做的。