关于程序员:猫头鹰的深夜翻译开发者最常踩到的六个低效陷阱

40次阅读

共计 2664 个字符,预计需要花费 7 分钟才能阅读完成。

高效的工夫治理是大部分胜利的软件工程师具备的能力。它可能帮忙你在职业生涯上疾速提高,而不是每个麻利迭代末疯狂加班。

每个企业都试图通过自动化流水线,升级版 IDE 和 DevOps 来降低成本进步效力。而通过防止以下六种低效陷阱能够让你的当先一步,播种高效的一天。

1. 适度开发

你是否已经将需要复杂化,思考哪些奇奇怪怪的可能会呈现的场景。比方设计的这个 API 是否能够无缝的接入其它平台?或者控制面板是否可能主动发送报告?

管制住这些想法,不要适度设计!你不应该话大量工夫在一些过于超前的性能上。而且,代码越多意味着更多的 bug 和不必要的脚本将会加到本已臃肿的程序中,从而导致代码可读性扩展性的升高。

要想防止这一点,要常常反诘本人这段代码是否在解决以后的需要。你只须要思考用例和边界场景,不要花大量的工夫在一个短期内不会用到的性能上。

如果你不确定是否要新增一个性能用于解决一个潜在的极其场景,在下一次的麻利会议上提出来并和大家探讨。这能帮忙你节俭大量工夫,并且促成团队单干精力。

2. 一次又一次的编写同样脚本

作为一个工程师,你该当尽可能的遵循不要反复开发准则(DRY-Don’t Repeat Yourself)来提效。有两种办法能够贯彻这一准则:缩小冗余代码或是流水线开发流程。

代码冗余

搭建一个服务或者是虚拟环境往往意味着须要写同样的脚本并且重复执行。如果你须要搭建一个蕴含四层的分层架构服务,并且适配到开发,测试,预发和生产环境上,它们所须要的代码和执行的步骤根本是类似的。除此以外,根底服务的依赖正在变得日益简单。上述的工作不仅反复而乏味,人工执行还可能会导致误操作带来故障。

低代码平台提供了开箱即用的工具,包含可复用的组件和图形化的界面拖拽生成器。当然,你不能为每个场景找到完满适配的计划,然而它能够实现最根底的反复的工作。自动化流水线能够帮忙你构建,复制和部署代码到很多的环境上。

反复流程

具体的列出开发过程中的所有步骤并且思考你是否能够去掉其中几步,将它们自动化吧。

除此以外,额定关注执行超过两次以上的步骤。如果能够在须要做这些工作时通过一键触发自动化流程实现,你将极大提高效率。

在开始自动化之前,你还须要评估一下自动化的性价比。倡议问一下本人:自动化真的比手动操作更节省时间吗?我是否在前面几周频繁的做这个操作?

如果答案是必定的,开始写自动化脚本吧。它能极大缩小浪费时间(和头痛)。

从 0 搭建零碎

如果一个开发者每次搭建一个 Web 服务都须要写 JDBC 数据库链接的定制化代码,它将永远没法实现我的项目的开发。

开发可保护的并且平安的软件是咱们的最高优先级。然而,这并不意味着要从 0 搭建零碎。咱们不须要反复造轮子,并且开发一些曾经有现成实现的性能。

公司须要的是高效的工作,而从 0 搭建零碎所破费的工夫在大多数状况下都是不必要的。所以应用现成的二方包或框架并对其做一些定制化的解决来满足客户的需要。

你还能够查看公司的代码仓库,如果有些性能和你须要实现的类型,你齐全能够调研一下是否通过一个办法调用就能够拿到你想要的数据,

然而,在解决一些敏感数据如金融或衰弱类的数据时,从 0 搭建性能来保障安全性就很有必要了(毕竟你不晓得引入的框架是否存在平安问题)。然而,在大多数场景下,线程框架、开源库或是付费插件齐全够用了。

蹩脚的测试用例

在自动化和手动测试之间技术选型时,必须留神一个奥妙的均衡。因而,让咱们理解如何应用它来制订无效的测试策略。

编写一个小的手动测试来确保您增加的新性能失常工作很容易。然而当你扩大时,运行这些手动测试须要更多的工夫,尤其是当你试图找到那个一直毁坏你的代码的厌恶的谬误时。

如果你的应用程序或网站有许多组件,那么正确地运行特定测试的可能性也会减少。自动化测试甚至更无效地运行测试的零碎有助于防止这种状况。

你可能须要花些许工夫来设置自动化测试。然而,一旦它们被编写好,无论进行任何代码更改,它们就能够被重用和触发。因而,你不用因为增加了新性能而手动从新测试以前的性能。

相同,抉择正确的工作进行自动化同样重要。可怜的是,这是 QA 自动化测试中最常见的谬误之一。很容易陷入适度自动化的陷阱并最终一一脚本地复制测试。这是一个重大的工夫节约,因为弄清楚为什么这些简单的自动化生效了依然是一项人工操作 -——这正是你想要防止的事件。

不要让它变得比它预期的更简单。相同,应专一于简略的测试用例,而疏忽具备许多依赖项的低频的或简单的工作。在开始编写任何单元测试用例之前优化和打算你的测试策略,将帮忙节俭大量工夫。

5. 不正确的代码优化

这是一种相当常见的工夫节约,通常很难从一开始就发现。你破费大量工夫为低优先级甚至可能不须要的用例优化代码。

你惟一的关注点应该是让性能失常运行,而后再思考优化。然而,不要设定不切实际的优化指标。优化决策通常是不同场景定制的。

如果性能优化只须要几分钟,那就去做吧。然而,在大多数业务场景中,皮毛级的优化通常对我的项目来说并不重要。进行优化是坏事吗?是的。然而,如果您须要破费数小时能力取得 1% 的性能晋升,最好先与应用方进行探讨。

举个例子,假如您正在为外部团队开发网页。如果网站在 1 秒内胜利加载,你实际上不须要优化到在 0.5 秒内加载该网站, 因为这不会显着改善业务经营。然而,如果它是一个电子商务商店,让它在一秒内而不是两秒内加载将是一个强烈的诉求。

解决这种工夫节约的最佳办法是定期从用户那里取得反馈。依据他们的具体用例进行优化,而不是构建本人的用例。

6. 有效沟通

有效的沟通是软件开发中工夫节约的间接起因,有时是间接原因。

软件开发蕴含许多步骤——各个团队成员致力于不同的产品性能,而后交到 QA 团队进行测试,最初成为用户的产品。

沟通至关重要,尤其是在开发和测试阶段。假如开发人员误会了需要的商业用途。产生的误差会使解决方案过于简单,从而导致技术计划谬误并减少异样或返工的机会。

因为沟通是软件开发中最人为染指的方面,因而无奈齐全打消这种工夫节约。然而,有了适当的项目管理工具和合作环境,它齐全能够升高。

在集体层面上,在散会或开发性能时,始终思考大局。学会聆听和无效合作。养成将会议探讨的内容写下来或发送摘要的习惯,以对齐单方的冀望。

除此以外,尽早沟通。不要猜想需要,并在可能的状况下,在正式投入整个我的项目之前做一个 demo 演示。

总结

本文要害是养成防止这些浪费时间行为的习惯。短期生产力“提醒和技巧”只能带您到此为止。然而良好的编码实际和自我意识将帮忙您提高效率。留神你的工夫花在什么中央,试着缩小它,你就能够成为一名胜利的软件工程师了!

正文完
 0