zoukankan      html  css  js  c++  java
  • Skyscrapers Aren’t Scalable

    Skyscrapers Aren’t Scalable

    Michael Nygard

    WE oFTEn HEAR SoFTWARE EnginEERing CoMpAREd to building sky- scrapers, dams, or roads. It’s true in some important aspects.
    The hardest part of civil engineering isn’t designing a building that will stand up once it is finished, but figuring out the construction process. The construc- tion process has to go from a bare site to a finished building. In the interim, every worker must be able to apply his trade, and the unfinished structure has to stand up the whole time. We can take a lesson from that when it comes to deploying large integrated systems. (“Integrated” includes virtually every enterprise and web application!) Traditional “big bang” deployments are like stacking up a pile of beams and girders, throwing them into the air, and expect- ing them to stick together in the shape of a building.
    Instead, we should plan to deploy one component at a time. Whether this is a replacement or a greenfield project, this has two large benefits.
    First, when we deploy software, we are exposing ourselves to the accumulated technical risk embodied in the code. By deploying one component at a time, we spread technical risk out over a longer period of time. Every component has its own chance to fail in production, letting us harden each one independently.
    The second large benefit is that it forces us to create well-defined interfaces between components. Deploying a single component of a new system often means reverse-integrating it with the old system. Therefore, by the time deployment is complete, each component has worked with two different systems: the original and the replacement. Nothing is reusable until it has been reused, so piecewise deployment automatically means greater reusability. In practice, it also leads to better coherence and looser coupling.

    Conversely, there are some important ways that civil engineering analogies mislead us. In particular, the concreteness of the real world pushes us toward a waterfall process. After all, nobody starts building a skyscraper without knowing where it’s going or how tall it should be. Adding floors to an existing building is costly, disruptive, and risky, so we try to avoid it. Once designed, the skyscraper isn’t supposed to change its location or height. Skyscrapers aren’t scalable.
    We cannot easily add lanes to roads, but we’ve learned how to easily add fea- tures to software. This isn’t a defect of our software processes, but a virtue of the medium in which we work. It’s OK to release an application that only does a few things, as long as users value those things enough to pay for them. In fact, the earlier you release your application, the greater the net present value of the whole thing will be.
    “Early release” may appear to compete with “incremental deployment,” but they can actually work together quite well. Early release of individual compo- nents means that each one can iterate independently. In fact, it will force you to work out thorny issues like continuous availability during deployments and protocol versioning.
    It’s rare to find a technique that simultaneously provides higher commercial value and better architectural qualities, but early deployment of individual components offers both.

  • 相关阅读:
    单点登陆
    【springmvc学习】常用注解总结
    Excel里函数中的万金油,你确定不要点进来看看?
    Maven3在Eclipse上安装插件
    VSCode 云同步扩展设置 Settings Sync 插件
    Ubuntu 18.04 root 使用ssh密钥远程登陆
    [Asp.net] C# 操作Excel的几种方式 优缺点比较
    开源框架Autofac使用入门
    C# .net Ueditor实现图片上传到阿里云OSS 对象存储
    [python]TypeError: string indices must be integers解决方法
  • 原文地址:https://www.cnblogs.com/yangykaifa/p/7257509.html
Copyright © 2011-2022 走看看