32

怎样度过第一份编码工作的艰难时期?

 3 years ago
source link: http://mp.weixin.qq.com/s?__biz=MzI2NjkyNDQ3Mw%3D%3D&%3Bmid=2247493635&%3Bidx=1&%3Bsn=8f83462ab12c46cc33efc3c4e94cbf56
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

EjyQZvZ.jpg!web

全文共 1726 字,预计学习时长 6 分钟

FjmAZbf.jpg!web

图源:pexels

软件工程或是数据科学对于很多人来说,实在不是一件容易的事。特别在没有编码经验的情况下,如果第一份工作是在这两个领域,会让人士气低落。

我常常收到“寻求改进方法”的留言或者私信。但事实上,你真正需要的是有人对你说“你能做到!”

本文总结了我在第一份软件工程工作中犯的错误。假如你和那时的我一样,正在经历艰难的日子,这篇文章应该能够给你帮助。

1.巧妙即可,无需可读

写好代码很难,理解错误的代码更难。刚开始时我们很可能难以直观理解,有一个高级开发人员就以下问题提出了建议:

·        过度抽象

·        同一行上有多个嵌套的if/else语句

·        过度使用链式方法

·        从堆栈溢出复制或粘贴正则表达式,不带注释

将逻辑压缩到尽可能小的空间里,使笔者自觉很聪明。但代码的可读性就消失了。 根据克尼根定律: 调试的难度是编写代码的两倍。 因此,如果读者尽可能巧妙地编写代码,那么根据定义,就因为不够聪明而无法对其进行调试。

2.提交审阅的代码合并了多个功能

笔者最先学到的事项之一,就是不要在同一个请求中组合多个特性。这对于审查代码的人并不友好。超过几百行的代码,会让其他人很难在脑海中走一遍执行过程。

有时这是tickets范围不佳的结果。所以笔者总是告诉新开发人员,如果他们认为可以将ticket进一步细分为子ticket,则应回推,越小越好。

3.使用无上下文的变量名

想出好的变量名非常困难,但那时我很想要尽快完成它。所以笔者选择了脑海中浮现的第一个名字。

·        用户的姓氏是uln。

·        一组电子邮箱是array。

两者都不算好主意,并且使得任何人都很难理解所写内容,甚至包括笔者自己。

4.读取特性Ticket后立即编写代码

jeYnaqZ.jpg!web

图源:pexels

花一周的时间在一个特性上,然后才意识到这一特性是错误的,这实在是太尴尬了,然而笔者不止一次犯过这个错误。

放松心态,理解业务问题,并且围绕其规划代码,这对于工程师而言工作量很大。从中吸取教训,在笔者自己的创业计划开始之前,让新的开发人员详细规划一些tickets。这种微观规划水平有助于理清思路,制定更有效的解决方案。

5.注释过多或过少

最初,笔者没有任何注释。

第二阶段时,笔者每一行都有注释。add_two_numbers的函数将会有着 # adds 2 numbers的注释。这就有点矫枉过正了。

回想一下,直到笔者阅读了其他开发人员编写的足够多的代码,并且注意到希望他们添加注释的地方,才明白了注释的真正用处和正确数量。

6.推送重复和未使用的代码

笔者做了如下所有工作:

·        已存在于应用程序中的书面功能

·        保留自动生成但未使用的文件(即:测试文件)     

·        添加了未使用的软件包

有些框架会自动生成许多不必要的文件。当开始使用一个应用程序时,也不知道所有的现有代码。笔者发现,避免这些问题的最佳方法是,在提交代码供审阅之前,一定要仔细阅读自己编写的代码。

JjMnqaE.jpg!web

图源: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时。偶尔出现这样的问题是可以的,但这不能是常态。

编写软件是一件困难但充满成就感的事,实践能让我们很快成长起来。正处于困难的时期的小伙伴们,但行好事,莫问前程,结果会在你努力的过程中悄悄地来。

VbeE7j3.jpg!web

推荐阅读专题

NBJ7vyI.jpg!web

bEniumQ.jpg!web

m6jER3M.jpg!web

iuUFJbn.jpg!web

Nbqmy26.jpg!web

留言点赞发个朋友圈

我们一起分享AI学习与发展的干货

编译组:王俊博、王小燕

相关链接:

https://towardsdatascience.com/coding-mistakes-i-made-as-a-junior-developer-e151dd3b3c7d

如转载,请后台留言,遵守转载规范

推荐文章阅读


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK