敏捷开发日常术语_面向新程序员的敏捷软件开发人员术语

敏捷开发日常术语

这是一个面向年轻，经验不足或年老的新开发人员的职位，他们正在接受信息技术的再培训。

最近，在伦敦众多用户团体之夜中的一个晚上，我与许多工程师进行了讨论，讨论有太多新内容要向编程新手们解释。 一个人不得不指导一名研究生开发人员编写单元测试。 另一个人必须解释为什么依赖注入比依赖查找更好的原因。 我可以回忆起类似的内容，能够温和而简洁地解释为什么我们应该在代码中进行单元测试，以及为什么需要它们。

这是我当前的术语矩阵：

术语	描述
亚尼	您并不需要它-问题在于，编写的代码远远多于解决或交付应用程序功能所需的代码。经典症状：向Java EE中的会话bean添加了未使用的finder方法
干燥	不要重复自己–编写在方法，类，包和包对象之间重复很多的代码。经典症状：单元测试中的复制和粘贴编码以及实体和前端中的重复元数据
吻	保持简单傻[或愚蠢] –描述仅编写代码以解决功能问题而不是编写不太复杂的代码的口头禅。另请参阅Occam的Razor。 类症状：软件应用程序中的抽象层太多
湿	每次编写– DRY的对立面，故意编写代码，在不同的类，包和函数中重复大量的时间。症状：决定以自己的方式做事，而不是与其他开发人员合作并找到一些共同点地面。 经典解毒剂：干燥，单元测试和重新处理
威特	写下万万万物-WET夸张的口语版本
R3	三分法则–这不是同名的专有操作系统，也不是经典的1980年的街机游戏，也不是大众化的皮条客游戏的描述。 但是，只要有一个方法，函数或类中有三个重复的代码部分，就可以将重复的重构为单个方法了。与DRY和WET有关 类症状：由于时间紧迫而忽略了代码重复，或者SCRUM主机拒绝，在此sprint中不要这样做。
DBC	按合同设计–首先从合同构建服务的想法。 在Java中，您尽可能简单地编写接口，然后再担心实现类。接口更易于重构，并且因为您可以将不同的实现插入接口中，因此具有更高的内聚性和更低的耦合性。 1.0。 有很多针对不同关系数据库的实现，包括MySQL，Postgres，H2，Derby等。每个Java程序员都知道如何针对JDBC进行编码，因为它们不必与其他实现争执，因为DBC暗示了这种实现大多数时候都会做正确的事。 还与应用程序编程接口的标准化有关。
BDUF或BUDF	大型前期设计–许多大型公司机构的问题，有时在没有任何软件构造可以通过之前，需要满足100至1000页完整的业务要求的文档。一些贫穷的架构师或业务分析师将花费数周的时间与企业进行调查和讨论。要求，仅供开发团队说该文档实际上毫无价值。 解毒剂：获得技术领导，以及一些关键的开发人员与企业，分析师和客户进行交流。 构想会议大家！ 症状：瀑布方法和投资银行IT文化的各个方面 解毒剂：未知，许多人尝试将具有大A和小A的“敏捷”带入许多此类机构，并取得了一些成功和失败。
粉书	Ron Hendries等人用《 极端编程》的粉红色封面描述了这本书，除非有参考资料，否则不建议新手使用，因为粉红色的书现在已经很旧了，2000年，还有其他一些较新的敏捷开发书籍和课程可以帮助您新的Java开发人员。
YOLO	您只加载一次[如果有的话] –这与您希望在应用程序系统中拥有单一真相的事实有关。 这是架构错误的问题，那里有人没有通过足够的类来考虑功能需求示例：购物车服务EJB –您只想要应用程序中支付点的一种实现，尽管您将有许多支付点提供者（信用卡和借记卡第三方和PayPal）If-Ever部分是YOLO和YAGNI加在一起。 您不确定系统的另一部分是否已加载数据，因此决定保留该组件。 （您可能希望在YOLOIF上放置一个日志记录客户端，以便在没有人使用12或18个月的时间使用该功能时，可以有效地决定夹持该组件。） 题外话：如果您发现需要不断上传的数据来满足Web请求，则可能确实需要缓存，而不是YOLO。
穗	快速浏览SCRUM方法中的Sprint编码。 在Spike中，您可能正在寻找一个新的API，例如云服务或JavaFX等类似的用户界面API，并且基本上，您将探索该功能是否可以在新API中相对较好地实现。 简而言之，您在尝试将自己和其他资源投入新领域之前就对新区域建立了信心.SS钉通常包含在其中并受其保护，免受关键路径的影响并限制在一定的时间长度内。 请参阅SMART目标。 经典示例：采用构建系统-从Apache Ant迁移到Maven； 从Subversion迁移到Git； 采用新的开源库
TDD	测试驱动的开发–通常因为没有按照学科和思想的变化而没有得到充分解释而发生冲突。“您只能做以下四件事之一：编写单元测试，编写生产代码，重构单元测试和重构生产代码。 并且永远不会同时做这些事情。”
TFD	测试优先开发–基于TDD的思想，然后将学科扩展到在任何生产代码之前编写单元测试代码。 完全编写了全新的单元测试后，请确保新的单元测试实际上失败了，以便切换到编写生产代码，以确保新的测试通过。 完成后，您可以重构测试。 对所有绿色条运行所有测试。 重构生产代码并运行所有绿色条的测试。重复：回到开始； 向其中写入一个新单元，以检查该应用程序下一个功能的有效操作。 重复上述相同的公式。
速度	SCRUM软件开发的投资回报率是一项非常基本的衡量标准，与财务预算和报告完全无关。速度是每个团队每次迭代完成的故事点数。 对于经验丰富的SCRUM：速度等于在汇总时间间隔内完成的汇总工作单位，这意味着您需要在两个或多个冲刺中测量任务的每个进度。
故事点	对于sprint或任务中的每个用户故事，请使用参考单位预测实现的难度。 故事点通常用斐波纳契数表示：0、1、1、3、5、8、13、21、34、55、89、144世界上每个敏捷团队都有一个用户故事单元点的定义。 团队决定积压项目，以得出预测，而每个团队成员都要根据这些联合预测来决定对下一个冲刺应该应用什么。
DTSTTCPW	做可能可行的最简单的事情–在许多方面与Spike和KISS有关。 如果您时间紧迫，而投资银行的某些交易系统开发人员正在工作，那么这就是您的工作。DTSTTCPW当然会邀请团队合作以及其他开发人员和团队成员的有效支持，否则您会遇到麻烦。
语音	客户之声–这是SCRUM方法学中的一个术语，但是我对此不确定约20％； 我相信80％的时间是为真正的客户，是了解业务需求和客户意愿的人的代理人，占位符。 由于由于权限，文化或组织甚至地理位置的原因而无法使用真正的用户，因此有人将这种简称称为`` 理性之声''，这很有趣，尤其是当他们不喜欢直接与客户合作时。
单元测试	在Java编程中，单元测试是Java JUnit框架测试类或TestNG框架测试类，专门用于验证和验证应用程序中的单个工作功能单元测试需要一个目标，该目标可以是Java类，服务Bean，托管对象。 Bean或其他实现了上述功能的工具。单元测试通常被视为低级别的快速有效测试
功能测试	功能测试是一个较大的测试，也可以是单元测试，旨在测试整个应用程序基础结构的类或子部分的包。 功能测试可验证应用程序是否满足客户对性能，结果和效率的外部要求之一。症状：功能测试不一定是单元测试，并非所有功能测试都是验收测试。
验收测试	验收测试仅与名称上的功能测试相同。 接受测试是客户希望看到验证通过以进行实施的那些测试。症状：如果在演示时客户对应用程序不满意，则至少一项接受测试被破坏。 在下一个Sprint中添加一个。
固体	五个原则的集合：单一职责，开放-封闭，Liskov替换，接口隔离和依赖倒置。
单一责任原则	对象类，服务Bean，Web服务，函数或过程应该只承担一个责任症状：很难为复杂对象编写单元测试，因为它要进行WETTT
开闭原则	打开以进行扩展，关闭以进行修改这意味着您可以对对象进行子类化，但是通过不允许外部对象有损更改内部结构来封装对象。症状：对象实现中的泄漏，硬代码依赖性以及无法与Java接口一起使用（或类似于构造的界面，例如Scala特性和混入）
里斯科夫替代原则	交换能力的概念，并表示为按合同设计（DBC）。如果该对象是T的类型并且整个应用程序都能正常工作，则可以交换另一个对象X，它是T的实现。 这是模拟对象，模拟实现框架的基础； 一般测试； 代理远程对象，具有持久性的对象； 应用服务器和生命周期监视情况； 即插即用和可重新启动的应用程序。 我可以继续，但不会。
接口隔离原理	仅执行单个特定功能的服务接口要好于执行多个不同功能的服务接口。症状：无法遵守KISS原则。 在过去的日子里，非标准的C ++字符串库使每个人都想将可能要编写的任何操作的方法放入厨房的水槽中，以操纵C / C ++字符串（char *）
依赖倒置原则	不硬性地将与依赖关系的直接关系固定到对象中的想法。在Java EE世界中，您将使用诸如CDI之类的依赖关系注入容器将不同的托管Bean注入服务Bean中。管理服务组件和bean的生命周期。 生命周期由应用程序容器，云提供商或您正在使用的任何设备管理。 换一种说法：如今，无论是操作系统，虚拟机，Web容器还是移动平台（iOS和Android），每个应用程序都受到管理。 这是前进的道路。
设计模式	Erich Gamma等人撰写的有关设计模式的经典书籍。请您当地的技术主管将您的书籍副本借给您； 如果他们没有副本，那真的很糟糕。 告诉他们给一个培训预算，然后自己买书！

参考： Peter Pilgrim的博客博客中的JCG合作伙伴 Peter Pilgrim提供的针对新程序员的敏捷软件开发人员术语 。

翻译自: https://www.javacodegeeks.com/2012/12/agile-software-developer-terminology-for-new-programmers.html

敏捷开发日常术语