您在软件工程或数据科学领域的第一份工作可能会使人士气低落。 特别是如果您没有后台编写代码。
我经常收到人们的信息，要求他们提出改进建议。 但是他们真正需要的是有人告诉他们-"您可以做到!"
以下是我在第一份软件工程工作中亲自犯的错误。 如果您遇到困难，这应该会让您感觉更好。
1.编写比可读代码更聪明的代码
编写好的代码很难。 了解错误的代码更加困难。 但这刚开始时并不直观。
值得庆幸的是，我有一个高级开发人员，他不止一次地就以下几点提出了建议。
- 同一行上有多个嵌套的if / else语句
- 过多使用链式方法
- 正则表达式从堆栈溢出复制/粘贴而没有评论
- 过度抽象
将逻辑压缩到尽可能小的空间，让我感到很聪明。 但这也使我的代码不可读。 现在，我总是尝试在可读性方面犯错误。
调试的难度是一开始编写代码的两倍。 因此，如果您尽可能聪明地编写代码，就定义而言，您就不够聪明，无法对其进行调试。-克尼根定律
2.使用没有上下文的变量名
想出好的变量名非常困难，我想尽快完成票证。
因此，我选择突然出现的名字。
- 用户的姓氏变为uln。
- 一系列电子邮件变成了阵列。
两者都是不好的主意，这使任何人都很难理解我写的内容(包括我自己)。
3.允许安全漏洞
在另一种情况下，我要感谢一位出色的高级开发人员，他将我的代码免于遭到黑客攻击。
我已完成以下所有操作：
- 允许SQL注入
- 允许通过URL跳转访问受限页面
- 仅使用前端验证
- 具有增量ID的命名空间URL
建立了一份关于优秀安全实践的心理检查清单花了很长时间，我现在在检查其他开发人员的代码时会使用该清单。
4.阅读功能票后立即编写代码
花一个星期花在某个功能上，然后意识到它的错误功能令人尴尬。 我已经完成了不止一次。
屏住呼吸，了解业务问题，并为之计划代码对工程师来说是一个巨大的乘数。
从中学到的东西，我让我自己的启动中的新开发人员在开始之前详细计划票。 此级别的微型计划有助于理清思路并开发更有效的解决方案。
5.评论太多或太少
一开始我什么也没评论。
然后，我经历了一个阶段，对每一行进行评论。 一个名为add_two_numbers的方法将被注释为#，将两个数字相加。 这太多了。
回想起来，直到我阅读了其他开发人员编写的足够的代码并注意到我希望他们添加注释的位置后，才单击正确的注释数量。
6.推送重复和未使用的代码
我已完成以下所有操作：
- 应用程式中已存在的书面功能
- 左自动生成但未使用的文件(即：测试文件)
- 添加了未使用的软件包
一些框架会自动生成许多不必要的文件。 当您开始使用应用程序时，您也不知道所有现有代码。
有趣的是，我发现避免这些问题的优秀方法是先仔细阅读您详细编写的代码，然后再提交进行审核。
7.编写低效的数据库查询
当我开始第一份工作时，我对数据库一无所知。 我大概花了一年时间才弄清楚数据库索引。
那时，我编写了很多N + 1查询，并创建了db表来存储大量没有索引的数据。
两者都是令人讨厌的缓慢应用程序的配方。
8.使用基于错误的条件逻辑
条件if / else语句是软件的核心部分。
在伪代码中，它们通常看起来像这样。
if x is true do this
else do that
但是我为自己的投资组合编写的第一个应用程序充满了这样的逻辑。
do this
if this fails do that
有时我们需要挽救错误，例如遇到不可靠的API时。 但这应该是例外，而不是常规。
9.提交包含多个功能的代码以供审核
我学到的第一件事是不在同一个请求请求中合并多个功能。 审核代码的人不好。
超过几百行可能会使其他人很难在精神上走过不同的执行路径。
有时，这是票证范围不佳的结果。 因此，我总是告诉新开发人员，如果他们认为可以将票证进一步细分为子票证，则应推迟。 越小越好。
结论
学习编写软件非常困难。 您只能通过做中学到一百个动人的作品。
我希望阅读有关我的摸索的文章能使您在挣扎中感到更好。
对我比较大的帮助是让一位高级开发人员对我提交的每段代码都提供了详细的反馈。 找到可以得到的公司/团队。 这是比较快的改进方式。
