针对新(或老)开发人员的 6 个生产力实践
人类是复杂的生物,完成工作的动机多种多样。作为开发者,我们的动机并非纯粹的外在或经济利益——有时,我们追求的是交付代码的乐趣。
你可能是一位“交付者”,喜欢快速交付代码,以获得成就感,并能抽出时间陪伴家人。这类开发者会联系Yagni,以交付有价值的东西。
然而,在两个城镇之外的家中工作的同事可能是一名规划师,他重视创造正确的抽象概念并真正完成设计的内在回报。
你们两人可能有不同的“方式”,但你们都渴望同一个结果——高效。我的几位前任经理可能不同意我的观点,但我相信大多数人都渴望高效,无论动机如何。所以,无论你是发货员还是计划员,以下六种技巧都能帮助你最大限度地提高效率,加快交付速度。
1. 使用适合工作的语言
我曾经有个室友把我的钳子当锤子用。他成功地挂上了他的画,但我的钳子却坏了。用钉锤会更快。同样,为团队的应用程序使用正确的编程语言,可以极大地提高工作效率和速度。
例如,Python根植于科学计算,非常适合数据科学。重视稳定性和一致解决问题方法的开发人员会喜欢 Python。相比之下,Ruby非常适合用于网站表达能力强的代码,而且 Ruby 社区也容忍同一问题采用多种方法。
PHP是构建快速服务器端应用程序的绝佳选择,几乎可以部署在任何地方。目前有大量 PHP 开发人员可供您的项目使用,而且该语言和生态系统已经发展成熟。Node.js允许Web 开发人员在服务器端和客户端使用相同的语言,但会增加一些复杂性。如果您追求高度交互的客户端体验,您可以选择针对 Node.js 进行优化。
无论如何,尽量不要让最新的潮流影响你的语言选择。选择最适合你独特项目的语言和方法。十年前,我们开始使用一些 JavaScript 修饰在服务器端渲染页面。大约在十年中期,我们开始使用 REST 或 GraphQL API 在客户端渲染数据。2020 年初,我们开始对使用一些 TypeScript 修饰在服务器端渲染的简单应用程序产生强烈反对。
2. 不要自行实现身份验证
我曾参与过几个项目,团队在应用程序中实现了自定义身份验证,包括将加盐的密码哈希值保存到数据库中。我们不需要这样做。当时,我们拥有将身份验证委托给 Active Directory 的基础架构,以便用户可以使用与 Windows 登录相同的密码。然而,康威定律和自负的心态阻碍了这种可能性:开发经理不喜欢基础架构经理,导致开发工作在无法访问公司网络的地方进行。
既然Auth0和类似产品已经问世,您真的愿意承担实施身份验证的麻烦和风险吗?将身份验证委托给 Auth0 无疑是一种更好的工程权衡,这样您就可以先推出一个 MVP,然后在扩展时再考虑出于成本原因进行改造。您还能获得许多附加功能,并为您的应用程序提供更佳的安全性。
很多人造船,但很少有人自己动手造舷外发动机。既然可以买一台雅马哈发动机回家,何必被困在海上呢?
3. 首先编写单元测试
我们明白。编写单元测试就像刷牙一样。然而,刷牙总比蛀牙好。有时你只想直接开始实现代码,测试却碍事了。这种感觉很正常。
不通过测试驱动设计,直接进入实现阶段,虽然感觉效率很高,但最终可能会写出难闻的代码——冗长的方法和参数列表只是开始。最终,你的代码会更难测试和维护。当然,有时你需要探索某个想法,然后彻底改掉它。但一定要确保重新进行git reset
单元测试,并再次实现。最终你会得到一个更好的设计。
事后单元测试很容易被发现。它们通常非常粗糙,因为它们需要实例化大型类并断言它们能够正常工作。这种方法并不能体现单元测试的真正价值。编写良好的单元测试将帮助您梳理关注点,并存根或模拟出在现实世界中实现功能的依赖项。测试具有现实世界关注点的代码可能很困难。如果您已经完成了关注点分离的工作,测试就会容易得多。
如果这还不足以说服你,那么在你让未经测试的代码运行起来(并通过QA)之后,要求更多时间添加测试,这会让你的项目经理很生气。甚至不要提“重构”这个词。
为了成功进行单元测试,将功能分解为“红色、绿色、重构”的微小循环。
- 红色——首先编写一个失败的单元测试。删除实际活动,以便随时运行单元测试。
- 绿色——编写使该单元测试通过的代码。
- 重构——如果您需要清理代码,现在是重构并再次运行该单元测试的时候了。
然后重复。
使用这种模式,您将对您的代码更加有信心,并且当您将功能勾选为已完成时,您可以对项目经理微笑。
4. 利用 SaaS、IaaS 和 PaaS
当系统管理员穿着军靴,眉头紧锁,把服务器装上机架时,他们的工作显然与开发人员不同。如今,角色不再那么明确。团队的人员配置也不再像以前那样;我们被期望拥有比以往更多的技能,能够在任何需要的时候随时投入工作。开发人员经常花费太多时间在非代码任务上,例如基础设施、DevOps、集成等等。没错,这些任务很重要,但它们并不能使软件正常运行。
像AWS这样的基础设施即服务 (IaaS) 提供商,只需花费大量精力运行基础设施,即可让其变得“隐形”。您只需简单地执行git push 命令,即可部署应用程序的新版本。无需进行子网计算、设计网络架构,也无需与数据库管理员争论;IaaS 供应商会为您处理好这些。
情况正在好转。数百家供应商将原本只是项目琐事的工作变成了软件即服务 (SaaS)。
例如,您无需配置 Logstash 和 ElasticSearch 的复制功能。至少有六家公司会提取您应用程序的所有日志,允许您搜索,并在 90 天后删除,这样您将来就不会收到GDPR 罚款。许多公司还会仅凭存档的信用卡信息和 API 客户端即可发送电子邮件和短信。二十年前,那些脾气暴躁的系统管理员会同时配置 Sendmail、阅读日志、喝咖啡和咒骂。
当然,没有灵丹妙药。你需要找到更可靠、更谨慎的服务提供商。市场可能很嘈杂。此外,为所有这些供应商付款本身就很麻烦。理想情况下,你不应该把经理的信用卡存入每个应用程序,让她每月费力地获取报销发票。
最后,像Heroku这样的平台即服务 (PaaS) 提供商在过去十年中一直在研究如何将应用程序托管和插件市场外包。他们通过预先配置的各种技术栈来管理基础设施和平台。您可以对第三方供应商进行初步测试,在短短几个小时内将创意推向市场,并通过一张账单轻松支付服务费用。
5. 聆听你的 IDE
在希腊神话中,卡桑德拉是阿波罗的女祭司。卡桑德拉被诅咒,会说出一些永远无法相信的预言。你的 IDE 就像卡桑德拉一样,会做出各种预言——你的圈复杂度太高,或者你的 case 语句块没有最终的 default 子句。如果你不听从 IDE 的指令,你可能会在调试上花费大量时间。
除了 IDE 或编辑器的内置功能外,还有庞大的 Linter 生态系统。SonarLint值得特别一提,因为它支持大多数主流 IDE( Eclipse、IntelliJ、Visual Studio、VS Code),并针对安全问题、细微错误迹象和代码异味提供一流的建议。如果您的团队使用SonarQube来衡量代码质量,那么 SonarLint 就非常实用。在 IDE 中遵循这些建议意味着您提交的代码将更加安全且易于维护。
让你的 IDE 成为像Athenais一样值得信赖的预言家。这些建议可以降低代码的风险和复杂性。
6. 制定构建流程并使其快速
优秀的构建工具就像一列隐形列车,引领您的代码驶向生产环境。作为一名独立开发者,您可以选择在 IDE 的本地开发环境中运行测试和部署。这很棒,因为您可能会获得快速的反馈循环。这让您可以整天进行代码实验。
然而,当您开始与他人合作时,您会希望代码能够在CI/CD 流水线中运行,而这些流水线历来与桌面开发工具配合不佳。Makefile 、build.gradle或其他适合您的语言和运行时环境的构建工具将能够完美适配,并确保您的代码和测试在计算机之外也能顺利运行。此外,您还将获得一个可以自动化一些部署问题的地方,例如数据库迁移、打包、分发等等。
此外,精心设计的构建工具和实现将减少已完成任务所花费的时间。你可能希望一直运行单元测试,但是当所有依赖项都没有改变时,重新编译或检查代码有什么意义呢?
就我个人而言,我在任何新项目中都会遇到一个痛点:我已经对代码进行了一些基础探索,需要开始投入生产。然后,我会把注意力从编写代码转移到探索代码与外界的交互上。这时,我就可以实现构建流程,然后配置 IDE 来运行它。
更轻松、更快捷的配送
将功能齐全的软件交付给欣赏它的用户是一件非常有成就感的事情。有很多因素可能会影响你的生产力和交付时间。然而,无论你喜欢快速交付还是缓慢交付,你都可以采取一些切实可行的措施,让交付过程更轻松、更快捷。我希望本文中提到的六种效率技巧能让你的工作和生活更轻松一些。祝你一路顺风!
文章来源:https://dev.to/heroku/6-productivity-practices-for-new-or-old-developers-gea