偶然看到一篇觉得写得不错的文章。想分享给 V 友们,也欢迎大家多多交流自己的看法~
原创链接: https://www.zentao.net/redirect-index-25197.html
前几天,和我同事闲谈,聊到我在来禅道之前参与过的一个项目。当时,小团队对代码规范不够重视,结果合并代码时出现大量格式冲突,解决问题费时费力,最终项目的完成时间远远超过我们对项目预估的工时。
“无规矩不成方圆”,来了禅道以后才发现,其实小公司也应该有自己的代码规范。大家如果对禅道的代码规范感兴趣的话,我先赠送大家一份 [禅道资料] 和大家分享禅道的代码规范,下篇文章将会详细介绍。
那么,今天的文章先和大家讲讲规范优先原则,希望大家重新认识规范优先原则。
在《国富论》开篇写道:“一个好的经济制度,就是鼓励每个人去创造更多的财富。”这句话放在规范优先原则中也同样使用,“规范优先原则,就是鼓励每一个程序员去写更优秀的代码。”
规范优先是一种软件开发方法,其原则是产品需求规范应在实际编码阶段开始之前制定和批准。这意味着开发团队首先定义应用程序界面的外观、哪些端点(方法)可用、应该传输哪些数据以及以何种方式传输,从而促进更结构化和可预测的开发过程。
规范优先方法发挥着重要作用:
规范优先使团队在开始编码之前就能清楚地了解他们需要创建什么,这减少了客户期望和实际结果之间产生误解和差异的可能性。
创建 API 规范可鼓励开发人员、客户和其他利益相关者讨论和完善需求。这有助于更好地理解项目并加速开发过程。这种方法有助于避免客户和开发人员之间的误解,并最大限度地降低开发后期需求变更的风险。
规范优先原则的主要优势之一是能够在代码准备就绪之前轻松开始集成和测试。有了 API 规范,就可以设置模拟服务,并创建自动化测试,从而加快开发过程并确保更高的代码质量。
由于 API 规范是在开发开始之前创建的,因此 AQA 部门可以根据规范中已经描述的方法提前开始编写测试。这大大减少了开发测试套件所需的时间,并提高了其完整性和准确性。例如,有了明确的规范,AQA 部门甚至可以在规划阶段开始开发测试场景,从而优化测试流程并减少将来花费的时间。
根据预定义规范进行测试可简化流程并提高 AQA 部门的工作效率。规范中概述了清晰简洁的需求,测试专家可以专注于验证特定的功能能力和需求,而不必花时间识别界面中的差异或需求中的模糊之处。例如,拥有详细的规范可以帮助 AQA 工程师快速确定要进行哪些测试来验证特定功能,从而大大减少测试场景开发和执行所花费的时间。
由于几个重要原因,在软件开发中制定规范对于与其他团队的有效整合至关重要。原因如下:
规范从一开始就明确了项目目标和参数。这确保所有参与的团队对需要开发的内容以及不同组件如何交互有统一的理解。共享规范使团队能够更有效地协调他们的努力以实现共同目标。
规范有助于避免团队、客户和利益相关者之间的误解。通过提前全面记录需求,集成阶段出现误解或沟通不畅的风险显著降低。这可使团队之间的协作和集成更加顺畅。
当团队按照明确定义的规范工作时,集成过程中出现的任何问题或疑问都可以更快、更果断地得到解决。该规范可作为解决问题、确定根本原因和有效实施解决方案的参考点。
有了规范,集成任务甚至可以在整个系统完全开发之前开始。团队可以根据文档中指定的约定接口和行为开始集成其组件。这种并行工作简化了开发流程并加快了整个项目的时间表。
规范有助于更轻松、更全面地进行测试。可以根据规范中定义的预期行为开发测试场景,让质量保证团队能够尽早验证功能。这样可以减少缺陷和问题,提高软件质量。
采用规范驱动的方法通常会产生更好的结果,与利益相关者的期望紧密相关。通过遵守记录的要求,开发团队可以提供满足或超出客户需求的产品,从而提高满意度。
在开发团队中实施规范优先原则是提高软件开发流程效率的关键一步。这种方法可以促进更加结构化和透明的开发流程,提高质量并加快上市时间。
为了成功过渡到规范优先,我们可以先采用这些步骤:
选择用于创建和存储 API 规范的工具起着重要作用。选择会影响使用 API 的难易程度以及整个团队的规范的可访问性和清晰度。
最好逐步实施新方法,从单个项目或模块开始。这样团队就可以熟悉新的方法和工具,学习最佳实践,并优化流程。
API 规范还可能包括有关身份验证方法、授权和其他安全方面的信息。这从一开始就确保了所开发应用程序的安全性,并有助于避免将来出现问题。
过渡到新方法需要整个团队的理解和支持。培训团队成员了解规范优先的基础知识、其优势和实施方法是成功采用的第一步。
一旦团队在一个项目中成功采用了 规范优先原则,就可以将这种方法扩展到所有后续项目和团队。随着时间的推移,规范优先将成为企业文化的一部分,并成为组织内软件开发的标准方法。过渡到规范优先可以优化团队内部的流程,并有助于实现更高的质量标准和客户满意度。
希望我的分享可以帮助到你,也欢迎给我留言和我讨论。
1
c330 OP 我感觉写得还是有些有用的。不过现实是,兵熊熊一个,将熊熊一窝,如果项目构建者没有这个意识,或者底层架构就没有搭好,后面的开发,各自写各自的,重复造轮子,重复打补丁,各自封装底层比比皆是,搅成了一坨屎,加上很多人都是只管完成需求,缺乏对规范和质量的追求,团队很难提升开发效率和软件质量。
|
2
mrgeneral 48 天前
大兄弟,分享是好事,但是这也太标题党了啊,并且这个内容只是讲了一些正确但是不管落地的话。
建议后续分享可以给一些自己的 insight ,然后附上链接就好。 |
3
RightHand 48 天前 via Android
限制越多上限越低
|
4
tool2dx 48 天前
以前有编程分层论的说法,设计 API 的和调用 API 的,是两批完全不同的人,代码不可能重合的,也不存在造轮子。
|