微信二维码

二维码 扫二维码马上关注
扫码咨询
架构决策的多样性

        成功(或失败)主要是“小”决定

        对于一些人来说,架构就是关于决策的。一旦做出了最大和最重要的决定,体系结构工作就被认为完成了。遗憾的是,你的项目的成功很少取决于那些“大”决定。一个项目的成功在于我们经常忽略的“小”决定。最大的决策是静态的;一旦成功,它们就很少会改变。我们每天所做的小决定,实际上决定了支持新功能有多容易,以及随着软件的发展,团队可以保持多大的生产力。

        让我们研究一下其中的一些架构决策。

        大技术决策

        “重大”决策通常是技术选择决策。

        技术堆栈的选择是最大的架构决策之一。几年前,灯箱风靡一时。LAMP堆栈意味着您将使用Linux和Apache。更重要的是,它还意味着您将使用PHP编写代码并使用MySQL作为数据库。随着技术的发展,今天有了更多的组合,选择也更加细化。

        后端选择是另一个重要的体系结构决策。让我们快速研究一下选择Node.js的影响。编码范例将基于事件,加载共享将在多个Node.js进程之间传播。最重要的是,您将主要使用JavaScript编写代码。您将依赖许多Node.js库来进行数据库访问、缓存、身份验证等。

        选择微服务体系结构是另一个重要的决定。它不是选择底层框架或语言,而是基于选择运行时体系结构。它将允许您用不同的语言构建服务。然而,它将改变服务的开发和部署方式。

        库选择

        今天的开发严重依赖于开源库。对于web应用程序尤其如此。因此,在项目的过程中,将会做出许多与库的选择有关的决策。这些是架构决策。

        例如,图表库的选择将影响图形和图表的显示方式。根据应用程序中执行了多少图表绘制,影响可能是普遍的。

        使用ORM库访问数据库是另一个例子。我们使用Bookshelf+Knex访问PostgreSQL。最终,如果我们想从PostgreSQL转移到ORM库不支持的数据库,这将限制我们对数据库的选择。

        开源库的流行可能只是昙花一现。随着时间的推移,许多开源库无法跟上潮流,或者它们的创建者转向更大更好的东西。Redux-form曾经风靡一时,但现在它有了真正的竞争对手。今天的许多最佳选择可能不是未来的首选解决方案。有些甚至会因为它们的创造者失去兴趣而半途而废。它是不可预测的。

        对业务问题建模

        作为程序员,我们每天所做的大多数决策都与我们如何对业务问题建模有关。关键在于我们如何分解和实现业务问题的解决方案:我们如何定义相关的抽象和接口;什么进入一个类;模块和类如何相互关联;等。

        我们必须为用户界面定义组织原则,以及它在代码中的反映方式。我们还必须定义API的组织原则以及它在代码中的反映方式。这些是真实世界的架构决策,将决定我们项目的成败。

        这些决定需要多少思考?

        不要再责备那些重大的决定

        重大决策通常是静态的。一旦做出这些决定,就很少会改变。如果不进行重大重写,就不可能从PHP/Apache转到Java/Tomcat或JavaScript/Node.js。这些决策通常是在大多数程序员加入项目之前很久做出的。

        重大决策通常是基于技能的(架构就是这样!)如果您很熟悉JavaScript,您可能会选择Node.js作为后端,并为前端选择一个现代的JavaScript框架。几年前,GWT在精通Java的团队中很受欢迎。如果您的团队使用Microsoft . net和c#,那么很有可能是由精通Visual Studio、ASP或c++的人员做出选择的。

        重大决策影响多个视图类型。值得注意的是,这些决策不仅影响程序员,还影响应用程序的部署方式,甚至在更深的层次上影响用户对应用程序的看法。

        重大决策有时(虽然很少)可能是错误的。很难一概而论。所以,是的,重大的决策可能会出错,但通常情况并非如此。大多数主要框架都相当全面。下面是一些好的选择却不是这样的例子:

        你选择了ActiveX/IE,微软就失去了对桌面浏览器的垄断。

        您选择AngularJS(旧的Angular),但是发现它的复杂性令人望而生畏(注意:据报道Angular 2+有了很大的改进)。

        您在MongoDB上构建应用程序,然后发现需要事务(注意:Mongo 4.0现在有用于复制集的事务)。

        这通常发生在新技术不成熟或旧技术正在转型的时候。请注意,这并不意味着批评,因为选择旧的甚至不成熟的技术有完全合理的理由。

成功的关键决定往往是不假思索做出的。代码通过新的故事和bug修复进行发展。我们创建新函数时,没有考虑什么是业务逻辑的一部分,什么是         实用程序的一部分。我们在剪切和粘贴时没有考虑共享抽象。这些都是“小”决策,因为团队范围内的思考很少涉及其中。这取决于每个开发人员编写他们认为合适的代码。没有Sprint任务致力于确保设计的一致性,代码评审只是忽略了这个问题。最终的结果是一团乱麻,很难理解,也不可能长期维持。

        我们不强调这些决策的一个潜在原因是,它们是可以重构的。决策可以改变,甚至可以是渐进的。如果这些问题可以解决,那又何必担心呢?然而,有多少项目会投资于这些改进呢?

        通常,解决代码复杂性问题的方法就在于我们编写的代码。修复它应该是敏捷开发的一部分。它应该在我们的过程中可见。要做到这一点,我们必须首先拥有它。

更多精彩内容,请关注元吉优惠券网:专注阿里云代金券阿里云服务器报价腾讯云代金券的免费更新领取!
更多精彩内容推荐:

使用Firebase云消息向React Web应用程序添加推送通知
您可以用JavaScript使用控制台做的所有事情
定制发送个性化推送通知
阿里云SSL证书服务实践
Java开发人员的Redis:教程和代码示例
使用云虚拟主机上的网页图片显示不出来怎么办


在线客服
热线电话

扫一扫 微信加好友