在开发产品时，你是否考虑过关注功能性需求与非功能性需求的工作量？如果没有，那么你可能应该关注下了，本文将告诉你为什么。
作者 | Chris Horsnell
译者 | 梁蕊
责编 | 仲培艺
什么是功能性需求?
简单说来，就是特性。
这是你的 App、程序、系统、项目、产品等的核心——功能/特性使其得以工作，确保其实现了预期的目的。
可以说，这些功能会让你的用户想要使用它，而没有功能，你的产品就不复存在了。
尽管这是真的，并且非常重要，但是我经常看到非功能性的需求被完全忽略，这是非常危险的！
什么是非功能性需求？
1. 文档、评论、编码规范、自动化测试、构建自动化等。
2. 使你的产品更易读、更具有弹性和可持续性。
作为一名开发人员或一个团队，这是你对代码库所做的所有与产品/项目不直接相关的事情。在这一点上，向那些了解到功能需求实际上可能只是总工作负载的一部分的读者致敬。
对于那些说“好吧，还有什么？”的人来说，根据我的经验，这是一个相当普遍的反应，所以不要感到难过。也不是每个关注非功能性需求的人都会做得很好。如果某件事值得做，就值得把它做好，对吧？
基本上，你对产品所做的任何与功能无关的事情都是重要的。想花更少的时间构建？自动化。想要确保提交的代码质量？进行同行审查。想要确保审查你代码的人能够阅读它？添加注释，而且不仅仅是添加一些注释，你需要考虑它是做什么的，它是如何做的，它为什么这样做，等等。
这样的例子不胜枚举，实际上听起来工作量很大是吗？但选择这样做当然有其原因。
为什么非功能性需求很重要？
如果没有它们，你的产品基本上就是一个纸牌屋，随时可能被“微风”击倒。
没有它们，你就会产生短期或长期的技术债务。
我们都有过这样的经历，把自己关在家里几天或几周，进行一场编码风暴，直到最后，才意识到自己创造了一个怪物。现在，在个人/业余项目中，这可能不是世界末日，但如果你是为客户而建，他们给的报酬也很可观，或者你是为你自己的业务而建，那么这可能就会是一个大问题。
企业可能希望在 2 到 10 年之间合理地使用此代码，他们也可能想要添加东西，修复错误，将它部署到不同的地方。他们甚至可能不喜欢你的脸，想让别人/另一家公司来接管。
当上述情况之一发生时，最好的情况是你必须亲自动手去做这些改变，或者最坏的情况是向某人解释原因。
为什么被忽视？
“我们没有时间。”
我听到的第一个借口是团队/开发人员没有时间。这是目光短浅且危险的，将直接影响到产品的可持续性和可维护性。如果不提前投入这些时间，总有一天会因此陷入麻烦——新员工会挣扎，现有的开发人员会忘记他们头脑中曾经新鲜的东西，你会失去几天或几周的时间来做那些可以自动化的事情，并且你现在正在浪费时间和金钱，而这本来是可以通过你的洞察力来避免的。
一般来说，这是缺乏技术领导的结果。面对现实吧，开发人员想要编写代码并解决问题，文档化、注释、确保代码覆盖等，与客户刚刚要求的新功能相比，这些并不是很吸引人。对于经验不足的开发人员来说尤其如此，他们还没有经历过忽视可持续发展意味着什么。
高级开发人员、技术总监、CTO、Scrum Master、产品所有者、顾问都应该意识到忽视非功能需求的危险。当团队和产品理解这些非功能性需求的必要性时，所有这些角色都为他们提供了更多的价值。
如果没有这些决策者的战略规划或至少施加压力，很难吸引技术人才。如果不拿出丰厚的奖金，任何有经验的开发人员都不会愿意接近你。这意味着你只能得到那些没有经验的人，然后不断重蹈覆辙。
为什么软件项目需要可持续和可维护？
软件是一种资产，它需要具备业务可行性。
有所期望是相当合理的。如果你构建了什么，就相当于在为一项资产投入时间和精力。它需要有修改的潜力，迭代反馈，修复 bug，确保在没有不合理开销的情况下进行修改。
同样在软件团队中，人们来来去去，但是知识必须留存下来。只把产品的大部分工作知识掌握在某些关键人物的头脑中是没用的，如果他们离开/遭逢意外/中了彩票，你需要确保信息可以被存储和访问。此外，这些信息还需要清晰、简洁，且没什么隐藏内涵。如果谁有疑问，就像对五岁孩子一样为其解释。
如果不经历这些，你将每 1 - 2 年重建一次产品，或者每当你的开发人员更换时就意味着你不再有足够的理解力来有效设计你的产品。
如果不重建，走着走着就容易掉进死胡同，项目关闭，而自己也被炒了鱿鱼。
这也会影响你的声誉，尤其是当你与外部开发团队一起工作的时候，这些开发团队必须使用你蹩脚的 API，或者你发现自己经常收到阻碍，因为系统没有按照设计的那样工作，或者每次部署的时候都会崩溃。
这一切都影响到未来发展的成本。忽略所有这些意味着最终一切都会慢慢停止。即使是最小的改变也会让你付出巨大的代价。但是通过将一些注意力转移到非功能性需求上，您可以持续降低开发成本。这通常是最大的卖点，因为客户可以直接将其与他们所了解的东西——金钱——联系起来。“如果我们忽略这一点，现在可能节省 £20000，但未来两年里可能会因此最终赔上 £100000”。
战略决策
所有软件项目都需要具备可持续性和可维护性。
以下列表都是常识。如果你没有这些，你的项目就会失败。
它可能不会崩溃乃至导致整个公司关门，但软件项目的成功依赖于这些细节，需要允许迭代新特性/修复，并及时这样做。另外，如果你的整个开发团队明天就离开了，你也能借以确保连续性。
文档（代码、部署、平台、架构、约定等）
评论 （文档评论、内容、方式、原因等）
定期在团队/知识库中分享知识
利用正确的编程语言/框架来完成工作
架构/结构/设计模式
坚持风格指南（也许通过 linting 强制）
自动化测试（单元、E2E 等）
安全性和性能测试
自动构建，CI/CD
同行代码审查
版本控制（使用某种 Git Flow 分支策略）
更改日志和语义版本控制
关注点分离
API 规范（如果适用）
移情 UX
现在对于一些人来说，这似乎都是显而易见的，但是以我的经验来看，没有这些基本原则的软件团队/工程师的数量是相当可怕的。
显然没有人是完美的，并非所有项目都有时间或预算来处理所有这些事情（特别是如果你从头开始做）。在这些情况下，解释一下忽视这些事情会对最终产品及其投资回报产生什么影响——将关键涉众的决策结果告知他们。
如果你将这些概念添加到你的流程中，提高你的标准，并追求卓越，就会有好事发生。
原文：https://medium.com/@chrishorsnell/the-problem-with-developers-only-focusing-on-functional-requirements-bbef26d3a4b1
1.2019年第1期《单片机与嵌入式系统应用》电子刊新鲜出炉！
免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。