我决定以正确的方式编写一些框架，按部就班的选择一种语言（和版本…），选择正确的范例，进行 TDD，创建在提交PR后自动触发的 CI/CD 流水线，同时也可以在本地运行（当然还有设置 github/azdo/bitbucket/其他），选择一个license，并进行更多没有意识到的操作。 唯一不关心的就是代码覆盖率。这一切都是在编写一行代码之前完成的。
然后我编写了以下完全无关的脚本$ vim ~/bin/aur
#!/bin/bash
git pull
makepkg -i
并一直在想这是多么优雅和可读，如果我是按正确的方式做的，怎么可能会把它搞砸呢。
我们为什么要做这一切？
老实说，软件工程它很容易让每个人都认为他们可以做到，继而认为知道的比别人更多。 以至于从未写过一行代码的人指点开发人员如何完成他们的工作。 这可能是我们为什么要设置如此复杂的工具、实践和流程迷宫的第一个暗示。
问责制
如果出现问题，那是开发人员的错，不是产品负责人写了一个半途而废的功能，也不是质量检查人员没有测试他/她没有时间的百万分之一的场景，也不是老板不想在面包和黄油上花更多钱的错。
是的，没错，如今软件就是 USP！ 在竞争中拥有优势的唯一方法是拥有正确的工具，如果这些工具不存在，就需要创建它们。你可以拥有世界上最好的产品/服务，但如果没有软件支持，竞争对手将在某个时刻超越你。 也就是说，如果我们能做得更便宜不是更好吗？ 或者至少更聪明，因为竞争对手也可以。
无论如何，我们都对创建的软件负有责任，但我们也需要能够对其负得起责任。 那如何才能对不断发展且如此复杂以至于甚至无法开始了解可能出现问题的事物负责呢？
多年来，我们想出了一大堆东西（ASD、CI/CD、DDD、FP、XP 等等）来尝试解决面临的问题。 但这些问题到底是什么？ 为什么这些解决方案也会产生同样数量的新问题？ 为什么需要理解这么多废话才能编写 1 行代码？
流动性
人们通常容易忽视的最大问题可能是软件的流动性。 当建造一栋房子时，它一旦建成就几乎是固定的。 你不会在第二天就决定在顶楼加建一个游泳池，如果这么做了，至少会有 20 个人告诉你，虽然这很棒，但这是一个愚蠢的想法。 然而，在软件中，建造游泳池的后果并不是它会倒塌并杀死建筑物中的每个人。 它会稍微削弱基础，但是另一点技术债务是什么？
其中一个基本部分是软件不断发展的本质。 它永远不会完成，也永远不会被扔进垃圾箱。 一旦提交了一行代码，它很可能会在未来 10 年里一直保留在那里。 问题是你没有考虑那个大泳池会如何影响它，因为没有人告诉你关于这个泳池的事，甚至没有考虑过它。 事实上，一行代码可能会启发某人提出，如果我们能做到这一点，我们也可以建立一个池，对吧？ 我们创造的东西往往是下一件事情的灵感，有可能将其带向一个全新的方向。 但基础足够强大吗？
还有一个问题是我们随身携带的所有遗留垃圾。 如何确保它继续按预期工作？ 因为即使想在上面安装新的闪亮的东西，也不能失去那些旧的（以前闪亮的）东西。 过去，编码更像是建造一座房子，我们会建一次，一年后会建造它的改进版本，有足够的时间来验证旧的东西，现在不再是了。
弹性
虽然与架构意义上的流动性相关，但软件的弹性也与它的运行情况有关。 我们期望软件始终能够工作，但在尽可能狭窄的条件下开发它，“它可以在我的机器上工作”。 这就是为什么开发人员总是说它应该有效的部分原因。 它是如此复杂，以至于将完全相同的代码放到另一台机器上通常会失败！
那么我们是如何创造出如此复杂的东西，以至于甚至无法预测它是否会起作用，更不用说效果如何了。 这令人印象深刻，因为我们所做的一切归根结底都是一个非常二元的选择。 但为什么不能实现无论条件如何它总是有效的期望呢？
需要确保完全满足所有先决条件，否则它根本无法工作。 像 Docker 这样的工具可以解决这个问题，但仍然有无数的变量是无法控制的，甚至是无法想像到的。 混沌工程是一种使事物更具弹性的方法，但这需要相当大的投资。 它还假设软件可以工作，但这到底意味着什么？ 在正确的情况下，它可以在机器/产品集群上运行吗？ 如果在新的测试集群上运行它怎么办？ 在开始向它投入使用之前，需要设置多少东西？
规模
如果编写一个快速的小 bash 脚本，例如简介中的 AUR 构建示例，就可以放弃所有最佳实践。 至少可以相对安全地假设它不会在其他地方或由其他任何人扩展或使用。 但赌注越大，这些因素就越重要。 假设想要提供一个 AUR 构建 SAAS 平台，顶部的那段代码可能会在某个地方，但可能还想考虑微服务架构以及 20000 个其他东西。
这取决于最终目标是什么，代码应该写得多“好”。 可怕的事实是，我们有一半的时间都在寻找最终目标。 那么如何正确判断代码需要有多可靠呢？ 尤其是当产品负责人盯上你的时候，他希望尽快推出这个功能，然后两周后抱怨下一个功能花了太长时间，因为你还需要清理第一个功能的混乱。 那么怎样才能编写出足够好的代码，而不必在两周后重写呢？ 或者应该编写一次性代码？ 如果是这样，是否有一种架构能够真正促进这一点？ 企业会接受吗？ 归根结底这是我们的目标，对吗？
安全
需要如此复杂的工程的另一个重要（并且被严重低估的）原因是安全性。 在门上加锁，以防止未经身份验证和/或未经授权的人员进入，此外，还创建安全公文包，以将重要信息从 A 处传送到 B 处，并弄清楚如何处理开锁者并持续监控工程是否仍然符合（字面意思）当今的标准。
那么如何编写安全的代码呢？ 如何确保依赖项是安全的？ 总而言之，你不能或者最多可以编写出破解付出的比破解后的收益更多的软件。换句话说，软件保护的金罐越大需要的安全性越高。
但有一半的时间人们甚至不知道他们正在编写的代码充满了漏洞。 你不能真的责怪他们，因为这是一个如此庞大和复杂的话题，完全理解几乎是不可能的。 那么如何创建安全的代码呢？ 在不了解每一个最佳实践或实施代码扫描仪（以及理解和处理结果）的情况下，或许应该根据规模来处理它？ 也就是说，最初的第一桶金非常小，因此也就没有人关注？ 但如果默认情况下它是安全的，那就太好了。
