软件工程资料汇编

软件工程师的工作不是编写代码，而是解决问题；我们可通过生成代码解决了大部分问题。但是最终，生成代码也很困难，我们需要帮助。这就是为什么 GitHub 的Copilot

哲学和软件工程之间的区别在于：哲学家们可以无休止地争论某个标识identity的本质，软件工程师必须选择一个该死的定义来实现，而且需要忍受他们设计决策带来的不可避免的Bug后果。

每个软件工程师和 IT 人员都应该从事咨询工作。我不是在谈论成为那些被他们的公司称为“顾问”但实际上只是连续雇用的承包商之一。我指的是真正的顾问角色，您可以通过提供专业知识、提供建议和推动技术变革而获得报酬。有几种不同的方式可以进入这样的角色： 以独立顾问的身

Linter 最好被描述为静态代码分析器，因为它们甚至在您的代码运行之前检查您的代码。如果您想确保代码的长期可维护性，您应该遵循最佳编码实践和风格指南规则。实现这一目标的最佳方法之一是使用 linter，同时也可能发现代码中的错误和其他问题。它们可以在您的 IDE 中工作，作为构建过

海仑定律（Hyrum's Law）是软件工程中一种观察经验：

当前项目组合：EventStorming BP/PL（领域探索）+用户故事映射（故事发现、确定优先级、划分为更小的故事）+ BDD（规范）+ EventStorming DL（设计）+ BDD/TDD/DDDtactical（DDD战术设计、实施）。势不可挡！ 

这篇文章的灵感来自于 HackerNews 上的一条评论，我再也找不到了。它的要点是“虽然架构经常被过度设计，但代码本身却经常被设计不足”。如果有人认出作者，我会很乐意归于他们。作为免责声明，本文描述了我在过去 10 年担任顾问的经历。可能有一些框架和方法可以解决我将要描述的问题，但它们要么

这是敏捷教练THIERRY DE PAUW分享他建议基于Git主干分支开发的思路和经验教训：2012 年，我开始了一项技术指导任务，以提升一个新手团队的软件工程技能。从工程的角度来看是新手，而不是从工作经验的角度来看。他们的工作经验从 5 年到 20 年不等。一开始，我们遇到

现在相信的事情： 当您和不同经验水平的团队合作时，使用类型语言会更好（不是动态语言） 敏捷的站立会议实际上对于新手很有用。 Sprint 刺有自己的存在价值，前提是只要他们是实际路线修正（即“神圣的狗屎，那又不好！”），而不是一些神可怕的“敏捷”

今年敏捷宣言刚满20年，有两个事实似乎不言自明的：敏捷，作为一个标签，赢了；没有人想被称为非敏捷。敏捷在实践中远远低于其创始人的革命性思想。我们是如何走到这一步的？每个人都说他们在做敏捷，但几乎没有人是敏捷的。 

如果您想从经典 CI/CD 环境切换到 GitOps，那么您可以从大量可用工具中进行选择。术语 GitOps 是源代码管理系统 Git 的名称和操作中的缩写 Ops 的组合。将这个附加工具添加到 DevOps 工具箱的想法来自 Kubernetes 环境，它承诺将 IT 自动化提升到

本文介绍了一组用于管理应用程序依赖项的最佳实践，包括漏洞监控、工件验证以及减少依赖项足迹并使其可重现的步骤。这些实践中的每一个的具体情况可能会因您的语言生态系统和您使用的工具的具体情况而异，但一般原则适用。 版本锁定简而言之，

在涉及大量工作的软件过程中，有一种普遍的管理人员的方法，以确保每个人都能获得适合其才能、知识、技能和经验的任务。对于软件产品的给定功能或修改，高级技术人员将制定出可能成功并适合业务架构的设计。然后，这位大师将工作划分为需要由个人完成的任务。通常，优秀的技术大师会考虑他们团队的

本文介绍了fail-fast 原理、它的优点、如何应用它以及我的个人经验。尽管看起来违反直觉，但快速失败会使您的应用程序更加健壮。使用快速失败原则，错误和故障会更快出现，这使得它们更容易修复。如果本文启发您在代码库中应用快速失败原则，您可以立即开始使用它。即使您将该原则应用于单个文件

代码质量是软件工程最重要的方面之一。SonaQube 是代码保证工具，它通过收集您的源代码并对其进行分析来确保项目的代码质量。您可以根据此工具的结果将 CI/CD 管道配置为部署或不部署。例如，如果单元测试覆盖率低于 85%，则构建管道可能会失败。在这篇文章中，我们将看到如何在本地机

Marco Faella 是那不勒斯费德里科二世大学的副教授，也是《Seriously Good Software》一书的作者。在这一集中，Marco 解释了他所说的真正好的软件是什么意思，从多个不同的角度看待软件质量。然后，我们深入研究了这些软件质量中的一些，并提供了一些实用技巧，介绍了软