本文转载自公众号“读芯术”(ID：AI_Discovery)
软件工程或是数据科学对于很多人来说，实在不是一件容易的事。特别在没有编码经验的情况下，如果第一份工作是在这两个领域，会让人士气低落。
我常常收到“寻求改进方法”的留言或者私信。但事实上，你真正需要的是有人对你说“你能做到!”
本文总结了我在第一份软件工程工作中犯的错误。假如你和那时的我一样，正在经历艰难的日子，这篇文章应该能够给你帮助。
1. 巧妙即可，无需可读
写好代码很难，理解错误的代码更难。刚开始时我们很可能难以直观理解，有一个高级开发人员就以下问题提出了建议：
- 过度抽象
- 同一行上有多个嵌套的if/else语句
- 过度使用链式方法
- 从堆栈溢出复制或粘贴正则表达式，不带注释
将逻辑压缩到尽可能小的空间里，使笔者自觉很聪明。但代码的可读性就消失了。根据克尼根定律：调试的难度是编写代码的两倍。因此，如果读者尽可能巧妙地编写代码，那么根据定义，就因为不够聪明而无法对其进行调试。
2. 提交审阅的代码合并了多个功能
笔者最先学到的事项之一，就是不要在同一个请求中组合多个特性。这对于审查代码的人并不友好。超过几百行的代码，会让其他人很难在脑海中走一遍执行过程。
有时这是tickets范围不佳的结果。所以笔者总是告诉新开发人员，如果他们认为可以将ticket进一步细分为子ticket，则应回推，越小越好。
3. 使用无上下文的变量名
想出好的变量名非常困难，但那时我很想要尽快完成它。所以笔者选择了脑海中浮现的第一个名字。
- 用户的姓氏是uln。
- 一组电子邮箱是array。
两者都不算好主意，并且使得任何人都很难理解所写内容，甚至包括笔者自己。
4. 读取特性Ticket后立即编写代码
图源：pexels
花一周的时间在一个特性上，然后才意识到这一特性是错误的，这实在是太尴尬了，然而笔者不止一次犯过这个错误。
放松心态，理解业务问题，并且围绕其规划代码，这对于工程师而言工作量很大。从中吸取教训，在笔者自己的创业计划开始之前，让新的开发人员详细规划一些tickets。这种微观规划水平有助于理清思路，制定更有效的解决方案。
5. 注释过多或过少
最初，笔者没有任何注释。
第二阶段时，笔者每一行都有注释。add_two_numbers的函数将会有着 # adds 2 numbers的注释。这就有点矫枉过正了。
回想一下，直到笔者阅读了其他开发人员编写的足够多的代码，并且注意到希望他们添加注释的地方，才明白了注释的真正用处和正确数量。
6. 推送重复和未使用的代码
笔者做了如下所有工作：
- 已存在于应用程序中的书面功能
- 保留自动生成但未使用的文件(即：测试文件)
- 添加了未使用的软件包
有些框架会自动生成许多不必要的文件。当开始使用一个应用程序时，也不知道所有的现有代码。笔者发现，避免这些问题的最佳方法是，在提交代码供审阅之前，一定要仔细阅读自己编写的代码。
图源：unsplash
7. 允许安全漏洞
笔者很感谢一位出色的高级开发人员，使笔者的代码免受黑客攻击。我做了下述所有操作：
- 允许SQL注入
- 允许通过URL跳转访问受限页面
- 仅用于前端验证
- 具有增量ID的命名空间URL
建立一份有着最佳安全实践的心理检查清单花了很长时间，现在笔者查看其他开发人员代码时会使用该清单。
8. 编写低效的数据库查询
笔者在开始第一份工作时，对数据库一无所知。大概花了一年的时间才弄明白数据库索引。
那时我写了很多N+1 queries，并且创建了db表来存储大量没有索引的数据。这两者都是应用程序缓慢而让人烦闷的原因。
9. 使用基于错误的条件逻辑
条件语句if/else是软件的核心部分。在伪代码中，它们通常是这样的：
- if x is true
- do this
- else
- do that
但是笔者在编写自己的第一个投门砖软件时，就充满了如下的逻辑：
- do this
- if this fails
- do that
有时需要挽救一个错误，比如当碰到一个不可靠的API时。偶尔出现这样的问题是可以的，但这不能是常态。
编写软件是一件困难但充满成就感的事，实践能让我们很快成长起来。正处于困难的时期的小伙伴们，但行好事，莫问前程，结果会在你努力的过程中悄悄地来。
