个Ruby On Rail 创始人讨论软件开发( 三 ) 如果您要总结软件开发的整个

我们在网络上所做的许多事情都使用了25年的基础知识。发生的核心创新更多地是在识别应该强调的重点，重要的方面和推动的方面。例如，对于Web行业而言，前端开发应通过JSON（服务器端仅负责生成API ，然后API返回JSON）的做法是绕道而走。我们应该回到拥抱HTML的角度。将HTML放在我们的工作中心，通过网络发送HTML ，以便我们在第一次加载时就返回完整的Web文档，然后再通过HTML进行后续水化或更新。
我想回到微服务。我之前与之交谈的一位工程师谈到了它们，这是对整体软件变得过于复杂以至于无法维护的一种回应。微服务对您有什么帮助？让我们从前提开始。单片软件变得如此复杂……这是什么"成为"？这只是发生在我们身上吗？我们是完全无辜的旁观者吗？复杂性只是笼罩着我们，我们无能为力吗？那是胡扯的假设，我们需要反驳。完全废话。您不必让复杂性翻滚。您选择。一旦您选择了复杂性，那么自然的反应就是尝试将这种复杂性推到更多不同的盒子中，因为您无法一次全部处理好吧？错误！首先处理该死的事情。为什么事情如此复杂？他们必须这么复杂吗？他们可以不那么复杂吗？我认为答案是：是的，它们不必这么复杂。是的，我们可以做些什么。不，这并不意味着我们只需要提交即可。
我想在这里解决根本原因。大规模的Web开发应该比以往更简单。我们在压缩过去非常复杂且人们需要非常仔细考虑的众多领域的概念性开销方面迈出了巨大的一步。人们仍然以某种方式最终导致整体应用不堪重负，这是他们自己创造的野兽。与其尝试去思考我们该怎么做，不如说："我们可以把复杂性放到哪里？"我们将讨论的重点放在为什么我们首先具有复杂性上吗？
开发人员谈论意外的和固有的复杂性。实施过程是偶然的复杂性，固有的复杂性是我们工作所在领域的复杂性。大多数Web应用程序固有的复杂性与以往一样。我们退步的地方是引入大量的意外复杂性。如果您无法控制单一应用程序的复杂性，那么到底是什么让您认为有能力在一系列服务中分配这种复杂性，这些服务现在必须进行交互并处理网络的不可靠性，重试，两阶段提交和在处理方法调用，参数以及运行单个进程的基础知识时，所有这些其他复杂性根本就不存在。在复杂性级别上，与分发应用程序相比，对应用程序造成的危害几乎没有。您甚至可以解决最小的问题，一旦分发，问题的复杂性就会增加一个数量级。
其他行业，甚至政治家都将技术视为创新的来源。同时，我听到开发人员越来越多地说整个领域从根本上被破坏了……不不不。这是由于误解，认为大多数软件开发都是工程学。我不相信。是的，当您通过工程师的眼光看待软件开发时，事情看起来很糟。然后工程师会说：'好吧，您的规格确实很宽松。您的公差是不确定的' 。所有这些东西，所有的工程评估，等等，等等。这是对什么是软件开发的根本误解。软件开发的工程意义与搭建桥梁的意义不同。它们不仅是同一根学科的不同分支。
许多软件工程师的这种自我厌恶完全是徒劳的，而且永远都不会解决。软件开发是一个年轻的行业，如果我们再给它30年的ISO认证或任何严格的要求，我们将得出一个浪漫的工程概念，即它们在航空航天，电梯或桥梁中的工程…… 不是。这是一个根本不同的领域，需要根本不同的方法。
我们已经有了许多答案。我们只是害怕拥抱他们。例如，在传统工程估计中，很大一部分。事情是根据估算和关键路径图进行的，因为这只是建造摩天大楼的方式。倒入混凝土后，您无需重新配置定向塔的方式。软件开发并非如此。软件在许多方面都非常接近写作，游戏制作和电影的创作过程。体验设计未知事物的过程，直到看到它，您才知道它是否好。
看电影制作。我们拍摄电影已有一百年了。我们还没有弄清楚创作过程吗？没有！我们还没有。您可以聘请出色的导演，出色的演员，但仍可以制作一部完全烂影片。与建筑物相比，如果您选择了一个伟大的建筑师，一个伟大的工程公司和一个伟大的总承包商，那么您将到达一栋可以运转的建筑物。您可能会犯一些小错误，但是基本结构是合理的，除非有人犯了一个完全疏忽的错误。在电影制作，音乐，软件中，事情总是失败的。即使知道如何构建事物的技巧的好人聚在一起并从事某些工作，他们仍然会失败。