敏捷工程方法

建立软件架构的松耦合的同时，也要建立团队组织架构的松耦合，这两种双解耦才是构建高性能软件组织的关键。通常按功能划分大型团队通常很诱人，我们拥有一个架构师团队，一个开发团队，一个DBA团队，一个测试团队，一个部署团队和一个运营团队，但这不能解决任何扩展问题，没有扩展就没有客户响应，这是团队响应

Symmathesy是“一起学习”的意思，把希腊语前缀Syn / Sym（一起）+ Mathesi，（学习）= Symmathesy。软件不是一个工艺。 这也不是一门艺术。 它也不是工程, 也不是建筑, 也不是我们以前的任何东西。 我现在有了关于软件开发本质定义: Symmathes

Martin Thompson (@mjpt777) 于 6:30 下午 on 周一, 10月 01, 2018:Assuming REST and HTTP are required for microservices greatly restricts agility. Couplin

是因为我们无意识崇拜复杂吗？ 本文来自艾伯哈德沃尔夫： 软件开发并不是真正的编程。任

开明的尝试和错误优于完美且智慧的计划。 Programming Wisdom (@CodeWisdom) 于 0:00 上午 on 周二, 10月 02, 2018:“Enlightened trial and error outperforms

这是一位使用DDD已经五年的经验分享：我最近一直在谈论领域驱动设计（DDD），无论是在聚会还是与客户，所以我想我会写下我的想法，看看它是否有帮助。现在，很多人都从技术角度撰写了有关DDD的文章，这是其他人的DDD，所以我不打算这样做，而是从非技术角度讨论DDD。

在测试代​​码时，仅为每种方法编写一个或两个单元测试是不够的。编写单元测试时，目标不

作者: Kate Matsudaira你有没有这样的经验: 坐在电脑前开始一个项目，打开你的编辑器，然后只是盯着屏幕？这种情况一直发生在我身上，所以我理解你的内心挣扎。 即使你很热爱自己的工作，也并不总是每天都充满热情。有很多因素影响你的热情的工作

从Google趋势来看UML没有增长，是否意味着已经死亡，UML（以及RUP，AOSD和Essence）的创建者之一Ivar Jacobson回答了这个问题：

几年来，DevSecOps一直是技术对话中的热门话题。这个想法并不新鲜。但改变的是DevSecOps在软件交付中扮演的角色。当DevSecOps成为一个概念时，它被视为一种使安全性更好的方法，但不一定是健康

顶顶大名的Redis作者谈如何在Redis这样系统软件上进行代码文档注释，以下是九种注释类型的大意说明： 很长一段时间以来，我一直想在YouTube上发布一段“如何对系统软件文档注释”的新视频，讨论如何进行代码注释，然而，经过一番思考后，我意识到这个主题更

DDD原则是开发软件需要从业务需求开始。通常倾向于关注技术细节，但通过这种模式，设计基于核心业务目的和逻辑，同时可考虑到公司的战略方向。企业应用程序可能非常复杂，因此我们的团队使用了一种将用户（领域专家）连接到需求定义的开发技术，目的是构建可转换为解决业务需求的软件。在本文中，我想分

Kent Beck在Facebook七年期间，目睹Facebook团队从700人扩展到5000多人，如果100,000名工程师如何在同一系统上工作？Facebook的软件工程工作流程相当传统： 1.创建差异。2.获得审核和批准。3.

没有一个尺寸的裤子适合所有人穿，没有银弹，没有一个解决方案适合所有场景。本文概述了各种软件方法学。为什么软件方法学都不同？软件方法论主要是为了对付风险而生，因此方法学规定了特定的日常流程或一系列行动，因此他们还规定了管理软件项目风险的特定方法。

最近，我浏览了公司的代码库，发现它有三个版本的仪表板，都是用于分析页面，我很确定客户不需要那样做。这引发了我幼稚脑中的一些事情，我开始在互联网上寻找相关的想法。就在那时，我发现了这篇古老的论文：

很多时候，客户对他们想要解决的问题提出的是一个“假的确定性”需求。他们可能没有定义真正的问题需求，而是经常定义解决方案。风险在于如果将其误以为需求我们可能构建错误的系统。软件团队希望能够探索问题的不确定性，以便创建一个出色的解决方案。当产品所有者与客户合作定义问题时，然后再与团队合作