怎样度过第一份编码工作的艰难时期？
极客时间编辑部
讲述：初明明大小：3.39M时长：03:43
你好，欢迎收听极客视点。
软件工程或是数据科学对于很多人来说，实在不是一件容易的事。特别在没有编码经验的情况下，如果第一份工作是在这两个领域，会让人士气低落。
最近，公众号“读芯术（ID：AI_Discovery）”翻译了全栈工程师克里斯的文章，克里斯总结了他在第一份软件工程工作中犯的错误。假如你和那时的克里斯一样，正在经历艰难的日子，这篇文章或许能够给你帮助。
1. 巧妙即可，无需可读
写好代码很难，理解错误的代码更难。刚开始时你很可能难以直观理解，有一个高级开发人员就以下问题提出了建议：
过度抽象
同一行上有多个嵌套的 if/else 语句
过度使用链式方法
从堆栈溢出复制或粘贴正则表达式，不带注释
将逻辑压缩到尽可能小的空间里，或许会让你自觉很聪明，但代码的可读性就消失了。根据克尼根定律：调试的难度是编写代码的两倍。因此，如果读者尽可能巧妙地编写代码，那么根据定义，就因为不够聪明而无法对其进行调试。
2. 提交审阅的代码合并了多个功能
不要在同一个请求中组合多个特性，这对于审查代码的人并不友好。超过几百行的代码，会让其他人很难在脑海中走一遍执行过程。
有时这是 Tickets 范围不佳的结果，所以如果你认为可以将 Ticket 进一步细分为子 Ticket，则应回推，越小越好。
3. 使用无上下文的变量名
想出好的变量名非常困难，但那时我很想要尽快完成它。所以我选择了脑海中浮现的第一个名字：
用户的姓氏是 uln
一组电子邮箱是 array
两者都不算好主意，并且使得任何人都很难理解所写内容，甚至包括我自己。
4. 读取特性 Ticket 后立即编写代码
花一周的时间在一个特性上，然后才意识到这一特性是错误的，这实在是太尴尬了。
放松心态，理解业务问题，并且围绕其规划代码，这对于工程师而言工作量很大。让新的开发人员详细规划一些 Tickets。这种微观规划水平有助于理清思路，制定更有效的解决方案。
5. 推送重复和未使用的代码
有些框架会自动生成许多不必要的文件。当开始使用一个应用程序时，也不知道所有的现有代码。避免这些问题的最佳方法是，在提交代码供审阅之前，一定要仔细阅读自己编写的代码。
6. 允许安全漏洞
我很感谢一位出色的高级开发人员，使我的代码免受黑客攻击。我做了以下所有操作：
允许 SQL 注入
允许通过 URL 跳转访问受限页面
仅用于前端验证
具有增量 ID 的命名空间 URL
建立一份有着最佳安全实践的心理检查清单花了很长时间，现在我查看其他开发人员代码时会使用该清单。
7. 编写低效的数据库查询
我在开始第一份工作时，对数据库一无所知，大概花了一年的时间才弄明白数据库索引。
那时我写了很多 N+1 queries，并且创建了 DB 表来存储大量没有索引的数据。这两者都是应用程序缓慢而让人烦闷的原因。
以上就是今天的内容。编写软件是一件困难但充满成就感的事，实践能让我们很快成长起来。正处于困难的时期的你，但行好事，莫问前程，结果会在你努力的过程中悄悄地来。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论