敏捷工程方法

描述系统一个系统需要三个方面：系统是什么样的。系统中的计算以及所需的数据。系统的行为基于其内部状态，以及系统内部和外部的系统交互。 传统工具<

该文比较了软件工程中敏捷和瀑布两个方法，主要是分析了敏捷方法，指出敏捷方法的致命问题：我们们在系统开始时使用敏捷确实节省了分析和定义整个数据模型的时间，但经过一段时间、一年或更长时间后，我们将花费相同或更多的时间来处理糟糕的数据模型或大数据重构。如果我们在实现需求之前再添加一个阶段，

2018年6月26日，我很幸运地被DDD巴黎团队邀请与一些DDD明星同台演讲，如Mathias Verraes，

开发人员在任何软件项目过程中都会做出数百个微观和宏观决策。有些似乎相对无害，但对下游会有一个很大的影响。几位Cantina工程师聚在一起，回顾了我们在学习了一些艰苦的经理后需要特别考虑的关键点。 1. 利益相关者要求

2014年之前，SpareBank 1是在一个单体的Weblogic门户上运行其整个网络银行应用程序，每个开发人员都使用相同的代码库，发布是艰巨的过程，开发人员将他们的代码提交到整体存储库中。必须将检入代码部署到各种环境以进行集成和验收测试，还需要交付批准，同时文档必须更新。在许多情况下，审

有时你能做的最好的事情就是不编写代码！请记住，您的价值是能解决问题，而不是编写代码。编写代码也是具有价值，但需要成本、需要部署、维护和升级，它有bug，需要开发人员进行更改，它也有机会成本：自己编写代码来完成任务A意味着您没有时间完成任务B，而后者可能更紧急，更重要或两者兼而有之。有

许多人认为“敏捷”这个词已被腐化到应该完全放弃的程度。我最近看到了“IT中最大的谎言”（我找不到链接），其中许多答案都是“敏捷”。这个词已被歪曲，意味着对团队施加了一个无效且僵化的过程，而团队则有充分的理由对此表示厌恶。越来越多的强制性流程定义似乎占主导地位，数百万美元的认证机构放大

50多年来，全世界都在开发软件。软件几乎改变了我们生活的方方面面，所以我们离不开它。因此，软件业一直非常成功。我们可以选择快乐并继续做我们正在做的事情。然而，表面上一切都不是那么美好：太多失败的努力，所有领域的质量一般都太低，成本太高，速度太低等等。显然，我们需要有更好的工作方式，或

敏捷和DevOps可能看起来像是不同的行为，但如果你看看他们的目标，你会发现它们非常相似。看看Agile和DevOps提供的价值。也就是说，看看DevOps的“为什么”；再看看敏捷的“为什么”。当您仔细观察时，您会发现两者的目标是更快地为客户创造价值并更快地改变市场需求。DevOps采用Ag

这是成功的现代软件开发策略的四个基本部分。无可挑剔，可靠，自动化的构建和部署系统有效，低摩擦的协作不断学习和提高技能可更换的一次性软件的设计无可挑剔，可靠，自动化的构建和部署系统

软件开发很难，真的很难，实际上，它不止一门学科，涉及工程，团队合作，设计，复杂的问题解决，领域专业知识等等。要成为一名优秀的软件开发人员，您需要许多技能，其中一些技能只能通过经验来磨练。您需要不断学习并在工作中应用这些新课程，逐步迭代并尝试更好地通过自己和团队共同创建软件。软

几天前，我读完Melissa Perri的Escaping Build Trap，并且像往常一样，我想与社区分享一篇评论。我拿起这本书是因为作者是爱尔兰一个活动的发言

如果您正在使用测试驱动开发，请不要衡量单元测试的代码覆盖率，这比无用的统计更糟糕; 它会积极地引导你误入歧途。你应该怎么做？这取决于你想要完成什么。 改进代码和测试实践如果您正在尝试改进团队的编码和

1. 程序员测试应该很快测试反馈不应该扰乱编程流程。 2.程序员测试应该是确定性的。 3. 程序员测试应该是预测性的。程序员测试应该对行为变化敏感，但对结构变化不敏感。如果程序的行为从观察

今年冬天的时尚：脚踝围巾，它将成为米兰时装周的焦点。

“英雄”项目是20％的开发者提供80％或更多贡献的项目。很多项目被放弃，因为这些项目失败源于沟通的瓶颈，但是，关于这个问题的实证证据很少，此外，最近的研究表明，这样的英雄项目非常普遍。因此，本文从代码质量的角度探讨了英雄在项目中的作用，在1100多个开源GitHub项目中确定了英雄开发者社区