• 《软件框架设计的艺术》试读:1.3 大型软件



    在21世纪的前10年中,大部分软件系统都可以用脏乱差来形容,没有哪个软件的设计配得上用优雅这个词。这主要是因为开发时,大家的目标就是用尽可能少的资源来尽快地开发完项目。为了达到这个目标,开发团队往往直接复用现有的一些软件框架,而完全不顾这些重量级的框架其实是远远超出他们的需要。

    发布网页

    最近,我想在自己的服务器上放一个动态网页。有两种方法来完成这件事,一是在某个端口开一个套接字,读入数据流,再写点什么作为应答;二是基于现有的一些技术组装个系统。这两种方法我都尝试了一下。

    首先尝试的是第一种方法,即“从零开始”。我先阅读HTTP协议规范的相关文档,解析读入的头文件,再写了输出。完成这些功能的代码量不大,经过一些调试以后,程序就可以正常运行了。但接下来,还要再添加一些功能,如为网页的访问加上安全验证和处理POST请求等。我还需要阅读RFC①文档,并实现文档中的各项内容。最终所花费的工作量比我预计的要大得多。

    因此我尝试了第二种方法。我选择了Tomcat作为Web服务器,然后编写了一个Servlet,配置好相关的文件,短短时间内,我就完成了所有的开发工作。仅有一个缺点,那就是我现在的系统大小超过1 MB,而不是50 KB。

    现代的软件都是基于大型组件进行组装的。没有人独自从上到下完成所有内容,而是你会先安装一个可靠又低廉的操作系统,然后在上面安装Web服务器和数据库服务器。在安装了大量的软件以后,才能动手解决真正的问题,比如说想生成一个HTML页面。在此时写一个HTML页面简直易如反掌。但没有人敢说整个系统非常简单。事实上,这个对外只提供简单页面浏览的系统已经复杂到了极点,相信没有人敢说自己完全了解整个系统的全部内容。这可以称为无绪状态在软件开发中的绝佳示例:编写这个HTML页面的程序员在对整个系统仅有很少了解的前提下,仍然可以完成自己的工作。

    整个方案看起来就像一台推土机的工作方式一样。开发时,如果需要一个数据库,就安装一个数据库软件,如果需要一个比较可靠的运行平台,就安装Java平台和一个应用服务器,完全不会考虑这些框架是否过重了。总能找到一台足够大的推土机,把这些东西推到应用上去。如果发现应用占用了太多的内存,从理性主义观点出发,你会去考虑优化,而如果继续采用推土机式的处理方式,只需要再买上几GB内存就搞定了。如果系统的运行效率还不高,甚至可以多花点钱搞个集群,或者干脆上虚拟化技术,这样一层层堆上去,整个程序就会变得越来越大,永远都不会变小了。

    那么使用推土机式开发方式是好还是坏呢?事实上,这种处理问题方式的开发效率很高,相比之下,试图寻找Wirth那种“简洁又美观的解决办法”的效果更好,但是太耗时。如果你将目光放到Web系统上,会发现有大量的系统是采用这种推土机方式建立的。Amazon、Yahoo!,以及其他的大型站点也采用了这种方式,而且运行得很好,没有出现什么严重的问题。一切似乎都表明,对于现代的软件设计和编码来说,推土机方式完全可行。我们已经拥有了不可思议的计算能力,这使得人们更倾向于野蛮的程序开发方式②。而且这种工作方式行之有效!

    ① RFC是Request For Comments的缩写,是一系列以编号排定的文件。文件收集了因特网的相关信息,以及UNIX和因特网社区的软件文件。目前RFC文件是由ISOC(Internet Society)所赞助发行的。基本的因特网通信协议都在RFC文件内详细说明。——译者注

    ② 作者这句话的意思是指,早期计算机处理能力比较低,网络也不好,硬件配置与现代计算机相差很多,所以编写代码时要特别注意,才能保证性能,但现在的计算机处理能力已经有了若干个数量级的提高,所以编码时对性能等各方面考虑的就比较少了。——译者注
  • 相关阅读:
    cube.js 上下文实践的一些说明
    sitespeed.io 开源web 性能监控&&优化工具集
    sideway/joi js 强大的data schma 校验框架
    cube.js 最新版本的一些特性
    cube.js 支持的类型以及格式化
    cube.js 多租户模式使用一个说明
    airbyte 基于singer 扩展的EL 平台
    cube.js dimensions 的一些说明
    cube.js measures 的一些说明
    cube.js 上下文变量
  • 原文地址:https://www.cnblogs.com/shihao/p/2145065.html
Copyright © 2020-2023  润新知