我作为软件工程师学到的 4 个关键习惯

我从事软件工程快三年了。说实话，我觉得自己还不够精通（也不知道以后能不能达到精通的程度）。但有时候，我真希望自己能早点掌握某些知识。我想，不如就这些问题进行一番反思，并尽我所能地在这篇文章里和大家分享一下。所以，以下就是我作为一名软件工程师总结出的四个关键习惯。

1. 编写简洁的代码（这还用说吗！）

请稍等片刻。

所以，我并不是团队里代码写得最好的程序员。在编写代码的过程中，我总是很恼火别人看不懂我写的东西。说实话，我甚至都看不懂自己一个月前写的东西。

我当时想：“嘿，为什么不尝试写得更简洁一些呢？”。嗯，有时候代码更简洁并不意味着别人一眼就能看懂。因为还有其他因素在起作用，比如业务流程等等。但 我想，这肯定会有帮助。

不要重复自己（DRY）

说实话，最让我恼火的莫过于我自己。每次看到有多个副本的旧代码，我都会感到非常沮丧，简直无法形容。

试图理解文档中不同位置出现的同一行代码的多份副本真的令人困惑。

所以自从我意识到这一点后，我就开始尝试为那些我会经常重用的代码编写函数。这真是省去了很多麻烦。

如果你不这样做，你可能不得不修改多个文档，而这些文档的代码明明只有一行，比如说，仅仅是为了在 if-else 语句中添加一个新的条件。相信我，有时候你会忘记，然后就会出现 bug。所以，请务必将你可以在函数中重复使用的代码编写出来。

说到功能……

编写有意义的函数

我所说的“目的明确”是指，你必须编写只有一个明确用途的函数。例如，我想对密码进行哈希处理，那么我显然会专门编写一个函数来对密码进行哈希处理。

这将使你的代码更具可读性，并且在你需要更改哈希算法或其他任何内容时，可以为你省去很多麻烦。

但不要过度设计，如果你觉得没必要在 C# 中为 ` .ToString()`方法编写函数，那就不要写。它已经足够易读了。不要过度设计。

2. 学习设计模式

好像编写简洁的代码还不够似的！坦白说，确实不够。在我担任软件工程师的三年里，我尝试维护和开发了很多软件，有时我会说，默认的设计模式对我一点帮助都没有。

这就是为什么我有时最喜欢像 Flask 这样的微型 Web 框架。我可以完全按照自己的意愿来设计项目，无论是使用仓库模式还是其他方式。

找到最适合你的方案，尝试利用这里的材料来提升自己。

3. 自动化任务

如果可能，你应该尽可能实现一切自动化。自动化可能是我职业生涯中做过的最棒的事情。我曾经写过一个应用程序来帮我编写 API，这样我就不用再写代码了。

公平地说，虽然它是模板化的，但如果应用不是简单的CRUD应用，我仍然需要编写代码，但这确实是一个好的开始。这个“代码生成器”与学习设计模式的第二个要点不谋而合。如果我没有实现一个让我感到舒适的设计模式，我不可能完成这个项目。

另一个想法是，如果你的办公室有某种工单系统，那么将这些工单自动添加到敏捷看板中可能是一个好主意。当然，这取决于具体情况，但这是可行的。

你可能还想自动化一些琐碎的任务，比如服务器监控和应用程序部署。

4. 对写作要像对编程一样充满热情

让我解释一下，你作为软件工程师的工作可能并不总是需要编写代码。有时也需要撰写文档。

或许有些公司会为在 Medium 上的工程博客上发表文章设定 KPI。但通常情况下，你所撰写的文章都与文档相关。

它和编程有点关系，但不是编写代码，而是撰写关于代码的文档。就我个人经验而言，我会在有限的时间内尽力编写出最好的文档。这在我需要将项目移交给其他团队时起到了极大的帮助。

对我来说，我为自己编写优秀的文档，因为我不想被其他人打扰。

良好的文档意味着更少的人需要你帮忙理解你的代码，从而让你有更多的时间去做其他事情。

下次老板让你写代码文档时，请记住这一点。

结论

简而言之，编写简洁的代码，尽量遵循“不要重复自己”（DRY）原则。编写易于阅读且功能明确的函数。学习设计模式，找到你个人喜欢的模式。如果可能，尽量实现任务自动化。最后，永远不要偷懒编写文档。它能为你节省的时间比你想象的要多得多。

最后，我们每个人都会从中汲取各种各样的经验教训。这四点只是我个人的感悟。我写这篇文章并非为了说服你，而是想与你分享我的个人观点。无论如何，祝你今天过得愉快！