十二 07

软件架构与程序员的关系

作者: baiyuzhong 分类:架构实践   阅读:12,278 次 添加评论

文/刘龙龙

软件架构大多仅是概念,以说明大型软件中主要模块区分以及各模块的关联性;这些概念的实现要靠各种接口、协议以及软件支持工具来达成。其重点之一是针对“大型软件”的开发,需由很多程序员共同完成,如果不能将其适当区分、切割,不但不易分工,最后把部分编程结果集成时,还可能是项大工程。程序员在工作时应该了解自己负责的部分在哪个模块里、如何规范与他人的接口,才能顺利完成整个项目。

早期软件架构将数据与指令分开,编程时要区分变量声明与描述,不能混同;还有函数库的应用,只要写明函数的名称就可调用,不必费心考虑如求sin函数值或printf的细节。到了1980年代,软件设计开始有主从式架构的概念,将程序分割开,按客户端/服务器两个模块编程,软件应用的灵活度大幅提升,譬如,把它们分别安装在两台计算器上,通过网络来运算。这个概念的延伸即多层(n-tier)架构,浏览器、网站服务器、应用服务器和数据库服务器等各层次分开的模块共同完成应用软件的功能。

从使用需求与厂商提供的工具来看,现在的通用软件架构大致可以区分成八个主要模块:输入、程序处理、输出、用户接口、异常处理、数据库、网络以及多地区语言(国际化与本地化)支持。各模块内部又有各自的架构,例如最前面三个模块是传统的IPO架构,用户接口模块内部大多是图形呈现以及鼠标、手势识别等可视化编程的架构;而异常处理模块内部则常采用try-throw-catch的架构。数据库模块大多以能连接关系型数据库接口为设计基础,网络模块则以能连接互联网、支持相关通信协议的接口为诉求。多地区语言支持模块则要求把程序中所有与语言文化有关的数据(包括文字与图案)独立出来、分别处理。

早期以功能为主要架构设计考虑因素的技术大多会形成树状架构;而考虑对象因素的架构设计则会形成网状架构。当代以服务为主要架构设计考虑因素的技术形成的软件架构,可以举例似乎最简单不过的SOA和不容易马上理解的REST来感受。SOA说明网络上的服务要由用户、服务查询和服务提供三个角色完成才有效率;REST说明了客户端与服务器互动时状态(state)的概念,除了每次的问答(request-response)都必须是独立(stateless),还要考虑客户端处于何种状态(at rest或in transition),譬如,at rest状态才可以接受用户下一个指令。另外,如果服务器上的某个资源内容没有任何状态改变,客户端前一次取得的该资源内容则可以继续使用(如网页的cache)。

思考以上的描述,年轻的Android程序员大概能知道为何Android Development Kit环境中,系统自动有res/layout/value等文件夹的区分以及怎样运用才是有效编程。Java程序员能了解session bean与entity Den hoyeste

utbetalingen i denne spesielle gratis spilleautomater er pa hele 320. bean在MVC架构上的使用方式;而.NET程序员也可以回想被要求采用Code-Behind架构的背景。再往较早时期看一下,当初开发微软Windows应用软件使用SDK时,程序员就被训练成先把所有要出现在屏幕上的文字从各个程序中独立出来成为resource文档;1980年代IBM SNA/CICS程序员就采取如下的方式编程:把3270工作站上要显示的信息及可能输入的文字部分另建立成map。

现代的软件架构设计技术,都是前辈程序员靠创新、实践、经验传授等累积而得的精华,而各种搭配的软件开发工具与IDE也都非常完整。如果年轻程序员的编程工作没有采用这些工具或环境,或是虽然有采用,却不能了解它们的真正意义而误用,那可能还是土法炼钢而无法保持竞争力。

本文选自《程序员》杂志2011年05期,更多精彩内容敬请关注05期杂志

《程序员》杂志订阅火热进行中

转播到腾讯微博

----->立刻申请加入《程序员》杂志读者俱乐部,与杂志编辑直接交流,参与选题,优先投稿

One Response to “软件架构与程序员的关系”

  1. 挨踢e族 说道:

    不错,分析的很好

请评论

preload preload preload
京ICP备06065162