江苏龙网

  1. 首页 > 人文 > >

个Ruby On Rail 创始人讨论软件开发( 三 )


如果您从事本机应用程序开发 ， 并且声誉很高 ， 那么也许六个星期的时间还不够 。也许您还需要更多 。或者可能不是 。这取决于您是否可以运输要运输的物品 。但是整个行业已经开始思考"哦 ， 两周是一个很好的时间表" 。什么？ 我们如何变得如此确定？ 即使对于一家拥有5,000名员工的公司来说 ， 六个星期也是一个比较现实的起点 。
您还不太满意地谈到了软件开发中出现的其他趋势 ， 例如微服务和无服务器或测试驱动开发 。您实际上是否对软件工程学中的任何趋势感兴趣？这是一个棘手的问题 。找出我不喜欢的所有东西要容易得多 。
显然 ， 我有些偏见 ， 因为我在推动这些事情 。我正在实施Ruby on Rails和Shape Up ， 并分享了一些我认为应该如何进行软件开发的知识 。这并不意味着没有其他方法可以做到 。Web开发有各种各样的技术堆栈和方法 ， 这些使我微笑 。我很高兴看到我们在JavaScript开发方面取得的进步 。前端发生的升级在原子级别上非常出色 。我认为我们误入歧途的是分子水平 。人们采用的框架和方法都不是很好 ， 但是我认为基础的技术改进是通过编译器 ， polyfilling和JavaScript在这些版本上的核心进展 。
我们在网络上所做的许多事情都使用了25年的基础知识 。发生的核心创新更多地是在识别应该强调的重点 ， 重要的方面和推动的方面 。例如 ， 对于Web行业而言 ， 前端开发应通过JSON（服务器端仅负责生成API ， 然后API返回JSON）的做法是绕道而走 。我们应该回到拥抱HTML的角度 。将HTML放在我们的工作中心 ， 通过网络发送HTML ， 以便我们在第一次加载时就返回完整的Web文档 ， 然后再通过HTML进行后续水化或更新 。
我想回到微服务 。我之前与之交谈的一位工程师谈到了它们 ， 这是对整体软件变得过于复杂以至于无法维护的一种回应 。微服务对您有什么帮助？让我们从前提开始 。单片软件变得如此复杂……这是什么"成为"？ 这只是发生在我们身上吗？ 我们是完全无辜的旁观者吗？ 复杂性只是笼罩着我们 ， 我们无能为力吗？ 那是胡扯的假设 ， 我们需要反驳 。完全废话 。您不必让复杂性翻滚 。您选择 。一旦您选择了复杂性 ， 那么自然的反应就是尝试将这种复杂性推到更多不同的盒子中 ， 因为您无法一次全部处理好吧？ 错误！ 首先处理该死的事情 。为什么事情如此复杂？ 他们必须这么复杂吗？ 他们可以不那么复杂吗？ 我认为答案是：是的 ， 它们不必这么复杂 。是的 ， 我们可以做些什么 。不 ， 这并不意味着我们只需要提交即可 。
我想在这里解决根本原因 。大规模的Web开发应该比以往更简单 。我们在压缩过去非常复杂且人们需要非常仔细考虑的众多领域的概念性开销方面迈出了巨大的一步 。人们仍然以某种方式最终导致整体应用不堪重负 ， 这是他们自己创造的野兽 。与其尝试去思考我们该怎么做 ， 不如说："我们可以把复杂性放到哪里？"我们将讨论的重点放在为什么我们首先具有复杂性上吗？
开发人员谈论意外的和固有的复杂性 。实施过程是偶然的复杂性 ， 固有的复杂性是我们工作所在领域的复杂性 。大多数Web应用程序固有的复杂性与以往一样 。我们退步的地方是引入大量的意外复杂性 。如果您无法控制单一应用程序的复杂性 ， 那么到底是什么让您认为有能力在一系列服务中分配这种复杂性 ， 这些服务现在必须进行交互并处理网络的不可靠性 ， 重试 ， 两阶段提交和 在处理方法调用 ， 参数以及运行单个进程的基础知识时 ， 所有这些其他复杂性根本就不存在 。在复杂性级别上 ， 与分发应用程序相比 ， 对应用程序造成的危害几乎没有 。您甚至可以解决最小的问题 ， 一旦分发 ， 问题的复杂性就会增加一个数量级 。
其他行业 ， 甚至政治家都将技术视为创新的来源 。同时 ， 我听到开发人员越来越多地说整个领域从根本上被破坏了……不不不 。这是由于误解 ， 认为大多数软件开发都是工程学 。我不相信 。是的 ， 当您通过工程师的眼光看待软件开发时 ， 事情看起来很糟 。然后工程师会说：'好吧 ， 您的规格确实很宽松 。您的公差是不确定的' 。所有这些东西 ， 所有的工程评估 ， 等等 ， 等等 。这是对什么是软件开发的根本误解 。软件开发的工程意义与搭建桥梁的意义不同 。它们不仅是同一根学科的不同分支 。


推荐阅读


上一篇：iPhone 12选购前瞻！官方充电头可能还是必选项

下一篇：Win10 2004补丁更新 增强系统安全性