作为软件开发人员最担心的就是变化，因为一旦变化，意味着自己的开发任务加重， 轻则修改代码，重则修改框架，如果不用做任何修改，则皆大欢喜，现实告诉我们，这是小概率事件，但比买彩票中大奖的概率还是大很多。于是各种讨论开始，开发人员开始讲述修改如何的大，进度如何紧张，架构师也在一旁不停的唠叨这个修改点的重要性，以及对整个系统带来的好处。

　　在业界曾经有一句很经典的话：“在软件开发领域中，唯一的不变就是变化” 。一旦变化，就有人遭殃，不是开发人员，就是设计师或架构师。无论谁遭殃，都不得不拥抱变化。

　　拥抱变化是极限编程（eXtreme Programming）里面一个非常重要的概念，代表了敏捷阵营对于变化的一种态度，那就是不拒绝，而且还主动求变。本文不想探讨敏捷方面的知识，如何去拥抱变化，而是想要探讨程序的可扩展性，如何在编码过程中，以最小的代价来应对程序未来的变化。

　　关于可扩展性， 其本身就是一个多方面的概念集合。有人说程序的可扩展性必须建立在对未来需求的准确把握上，也有人说程序的可扩展性必须建立在能够对需求变化快速响应上。不论孰是孰非，其最终目的都是要求，能在需求发生变化的时候以最小的代价去应付变化。

　　可以从两个纬度对可扩展性进行讨论，一是设计可扩展性，二是编码可扩展性，前者从宏观上考虑，后者从微观上考虑，当然编码也是一种设计活动。本文重点论述编码的可扩展性，对于设计可扩展性，是一个系统性工程，由于作者还没有达到那个高度和境界，所以不敢瞎写，本文基本上不做介绍。

　　《UNIX 编程艺术》一书中有一条关于扩展原则的描述：设计要着眼于未来，未来总比预想快。 关于设计可扩展性， 对于系统架构师或者系统工程师不仅仅要考虑在实现用户需求的基础上如何构建系统，还要考虑计算资源的可扩展、应用规模的可扩展，以及对技术换代的可扩展和性能等。

　　近期发生的干旱和水灾，每次都能找到人为的因素。本文开头提到的场景，如果进行代码回溯，也能找到一些人为的因素。如果当时的编码者在写代码时充分考虑了代码可扩展性，在一定条件下，可以达到用最小的代价去应对变化。如果当时只是为了完成任务，交差，后续的维护者可能面对的不是拥抱变化，而是拥抱痛苦！

　　场景一：在某嵌入式电信级设备整框分布式环境中，有NEMI板（管理板），SWF板（业务板），STU板（业务板）和LC板（业务板），每块板上都有CPU，运行着各自的程序。目前的架构仅仅对NEMI/SWF/STU板支持了HA(HighAvailable)功能，在SWF卡上运行的某个业务，需要关注SWF卡的主备倒换事件。 运行在SWF卡上的程序可以收到来自NEMI和SWF卡的主备倒换事件，于是进行了如下编码：

void processSwitchEvent(GenMsg *pMsg)  
{  
    一些合法性判断语句  
    if(NEMI_SWITCH_EVENT == pMsg->getSwitchEventGrp())  
    {  
        MSG_INFO(“Received NEMI Switch Event……”);  
        return ;  
      
    //process SWF Switch Event  
    业务处理代码  
}        

        

        
        
      
        
it知识库：拥抱变化—— 可扩展性杂谈，转载需保留来源！
        
郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。