江苏龙网

  1. 首页 > 资讯 > 科技 > >

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


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

|怎样度过第一份编码工作的艰难时期？
本文插图

图源：pexels
软件工程或是数据科学对于很多人来说 ， 实在不是一件容易的事 。 特别在没有编码经验的情况下 ， 如果第一份工作是在这两个领域 ， 会让人士气低落 。
我常常收到“寻求改进方法”的留言或者私信 。 但事实上 ， 你真正需要的是有人对你说“你能做到！”
本文总结了我在第一份软件工程工作中犯的错误 。 假如你和那时的我一样 ， 正在经历艰难的日子 ， 这篇文章应该能够给你帮助 。
1.巧妙即可 ， 无需可读
写好代码很难 ， 理解错误的代码更难 。 刚开始时我们很可能难以直观理解 ， 有一个高级开发人员就以下问题提出了建议：
· 过度抽象
· 同一行上有多个嵌套的if/else语句
· 过度使用链式方法
· 从堆栈溢出复制或粘贴正则表达式 ， 不带注释
将逻辑压缩到尽可能小的空间里 ， 使笔者自觉很聪明 。 但代码的可读性就消失了 。 根据克尼根定律：调试的难度是编写代码的两倍 。 因此 ， 如果读者尽可能巧妙地编写代码 ， 那么根据定义 ， 就因为不够聪明而无法对其进行调试 。
2.提交审阅的代码合并了多个功能
笔者最先学到的事项之一 ， 就是不要在同一个请求中组合多个特性 。 这对于审查代码的人并不友好 。 超过几百行的代码 ， 会让其他人很难在脑海中走一遍执行过程 。
有时这是tickets范围不佳的结果 。 所以笔者总是告诉新开发人员 ， 如果他们认为可以将ticket进一步细分为子ticket ， 则应回推 ， 越小越好 。
3.使用无上下文的变量名
想出好的变量名非常困难 ， 但那时我很想要尽快完成它 。 所以笔者选择了脑海中浮现的第一个名字 。
· 用户的姓氏是uln 。
· 一组电子邮箱是array 。
两者都不算好主意 ， 并且使得任何人都很难理解所写内容 ， 甚至包括笔者自己 。
4.读取特性Ticket后立即编写代码

|怎样度过第一份编码工作的艰难时期？
本文插图

图源：pexels
花一周的时间在一个特性上 ， 然后才意识到这一特性是错误的 ， 这实在是太尴尬了 ， 然而笔者不止一次犯过这个错误 。
放松心态 ， 理解业务问题 ， 并且围绕其规划代码 ， 这对于工程师而言工作量很大 。 从中吸取教训 ， 在笔者自己的创业计划开始之前 ， 让新的开发人员详细规划一些tickets 。 这种微观规划水平有助于理清思路 ， 制定更有效的解决方案 。
5.注释过多或过少
最初 ， 笔者没有任何注释 。
第二阶段时 ， 笔者每一行都有注释 。 add_two_numbers的函数将会有着 # adds 2 numbers的注释 。 这就有点矫枉过正了 。
回想一下 ， 直到笔者阅读了其他开发人员编写的足够多的代码 ， 并且注意到希望他们添加注释的地方 ， 才明白了注释的真正用处和正确数量 。
6.推送重复和未使用的代码
笔者做了如下所有工作：
· 已存在于应用程序中的书面功能
· 保留自动生成但未使用的文件（即：测试文件）
· 添加了未使用的软件包
有些框架会自动生成许多不必要的文件 。 当开始使用一个应用程序时 ， 也不知道所有的现有代码 。 笔者发现 ， 避免这些问题的最佳方法是 ， 在提交代码供审阅之前 ， 一定要仔细阅读自己编写的代码 。

|怎样度过第一份编码工作的艰难时期？
本文插图

图源：unsplash
7.允许安全漏洞
笔者很感谢一位出色的高级开发人员 ， 使笔者的代码免受黑客攻击 。 我做了下述所有操作：


推荐阅读


上一篇：3DMGAME|自媒体吹涨150亿 中兴CEO徐子阳：5nm芯片明年问世 委托伙伴生产

下一篇：云计算|Service Mesh：调度千军万马微服务，2.0妥妥的