加入收藏 | 设为首页 | 会员中心 | 我要投稿 湖南网 (https://www.hunanwang.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 移动互联 > 正文

我从高级软件工程师身上学到的那些经验与教训

发布时间:2019-10-09 13:02:10 所属栏目:移动互联 来源:核子可乐译
导读:一年之前,我开始在彭博接受全职事变。从当时起,我就在构想这篇文章。我想象本身可以或许在机缘成熟时,把本身的设法都倾吐于纸端。但方才已往一个月,我就意识到这并非易事:跟着事变的推进,我遗忘了许多本身方才学到的对象。这些对象快速内化,使我的大脑

代码检察是进修中的重要构成部门。检察的进程,就是从编写代码、到相识怎样更好地编写代码的反馈轮回。我们本身的编码思绪,跟其他人的编码思绪有何差异?我在每一次代码检察时城市问本身:“他们为什么要这样做?”假如其实找不到公道的谜底,我就会跟他们对面聊聊。在第一个月的过渡期竣事之后,我开始猖獗地从同事的代码傍边查找错误(虽然,他们也不会放过我)。真的很猖獗,这也让评审事变酿成一项风趣的调度——可能说像是一种游戏,可以或许改进我们编码程度的小游戏。

我的心得:在领略代码浸染之前,不要轻下断言。

我从高级软件工程师身上学到的那些经验与教训

测  试

我出格喜好测试这项事变,究竟上假如不加测试,我基础就不肯意直接在代码库中编写代码。

假如您的整个应用措施只必要执行一项使命(我在学校里的尝试性项目就是这样),那么手动测试即可办理题目,我早年也一向风俗于这种方法。可是,当应用措施傍边包括上百种成果,环境又会怎样?我不想拿出大量时刻挨个测试,并且我也知道本身必定会遗忘某些必要测试的部门。这绝对会是一场恶梦。

这时辰,我们就该请出测试自动化方案了。

在我看来,测试跟记录文档差不多。测试的进程,就是记录我对付代码的假设是否正确的进程。测试会汇报我,我本身(可能是当初写下代码的开拓)其时但愿代码怎样运行,以及以为那边有也许出题目。

因此,此刻再编写测试时,我会紧记以下两点:

  1. 演示怎样行使我正在测试的类 / 函数 / 体系。
  2. 展示我以为也许出题目的部门。

第一条信托许多伴侣都能领略,事实在大大都环境下,我们必要测试的着实是举动,而非实现。但我小我私人总会忽略第 2 条,即 bug 也许呈此刻那边。

因此,每当我发明 bug 时,我城市确保代码修复措施在响应的测试(也就是回归测试)傍边记录下其余有也许激发错误的方法。

虽然,编写这类测试自己并不能提供代码质量,只有真正编写代码才会真正影响质量。不外我从阅读测试功效傍边得到的看法,确实可以或许辅佐本身编写出更好的代码。

这就是测试的宏观意义。

除此之外,测试还负担着另一项重要义务:确定陈设情形。

各人也许拥有美满的单位测试,但假如没有举办体系测试,就有也许产生以下环境:

我从高级软件工程师身上学到的那些履历与教导

锁到底是好的,照旧坏的?

对付颠末精采测试的代码也是云云:假如您的呆板上没有其必要的库,代码就会瓦解。

  • 您开拓地址的呆板情形。(「统统都能在我的呆板上正常运行!」)
  • 您测试地址的呆板情形。(也许就是您开拓所行使的那台呆板。)
  • 最后,您陈设地址的呆板情形。(请必然换一台此外呆板。)

假如测试与陈设呆板间的情形不匹配,那一样平常城市出点题目。而这,正是陈设情形的意义地址。我们在本身的呆板上行使 docker 构建当地开拓情形。

在这套开拓情形傍边安装有一组库(及开拓器材),我们则以此为基本安装已经编写完成的代码。全部与其余依靠体系相干的测试,都在这里完成。

然后是 beta 测试 / 分段情形,其与出产情形完全同等。

最后是出产情形,也就是认真运行代码并为现实客户提供处事的呆板。

我们的根基思绪是全力捕获那些不会在单位与体系测试中呈现的错误。譬喻,哀求与相应体系之间的 API 不匹配题目。

我猜小我私人项目可能小型企业的环境也许有所差异,事实并不是每小我私人都有资源来配置本身的一套基本办法。可是,假如各人乐意行使 AWS 以及 Azure 等云处事,这里提到的要领如故得当列位。各人可觉得开拓以及出产情形配置单独的集群。AWS ECS 操作 docker 镜像举办陈设,因此各情形之间相对同等。较量棘手的部门,就是假如与其余 AWS 处事顺遂整合。譬喻,我们是否从正确的情形中挪用了正确的端点?

各人乃至可以更进一步:为其余 AWS 处事下载备用容器镜像,并操作 docker-compose 呼吁配置完备的当地情形。这样可以或许加快反馈轮回。

云云一来,当我的附带项目启动并开始运行之后,我就能蕴蓄到更多履历心得。

消除风险

所谓消除风险,就是在陈设代码的进程中尽也许低落风险程度的一种艺术。

那么,我们可以采纳哪些法子来消除劫难性效果?

假如我们但愿推出的一项打破性的改观,那么一旦呈现题目,假如确保营业尽也许不受严峻影响?

“我们不必要对全部的新变革举办全体系陈设!”哦,是吗……歉仄,我没想到。

设   计

许多伴侣也许会问,我为什么要把计划放在编写代码与完成测试之后?好吧,计划在现实流程中也许较量靠前,但假如没有在当前情形中举办编码与测试,我小我私人很难计划出一套可以或许与特定情形美满适配的体系。在计划体系时,我们必要思量许多题目,包罗:

资源行使量是几多?

存在几多用户?估量用户会以奈何的速率增添?(这将直接抉择将来存在几多数据库行)

将来也许呈现的陷阱是什么?

我必要把这些转化成一份名为“要求汇总”的清单。今朝我还没有蕴蓄到充实的相干履历,按照打算,来岁我的事变内容就是出力办理这方面题目。

这个进程有点违反火速原则——在开始实验之前,我们可以或许做出几多计划判定?这是个衡量题目,我们必要选择在奈何的时刻点上做什么。我们什么时辰该深入分解,又该在什么时辰退后一步举办筹划?

(编辑:湖南网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读