文 | 魔术师
作者是一名 java 开发者，和大多数程序员一样，作者是一个热衷于提升自我技术水平的人。作者总是希望用最少的代码来实现某一项功能，也会经常翻看自己写的旧代码，看看有没有可以提升的空间。最近(2019年1月)，从旧代码中发现了一些代码的演化规律，可以解释为什么代码会越来越臃肿。
HelloWorld
开发者都知道，需求总是千变万化的，有的是全新的需求，有的是在旧的需求上边新增需求。所有的这些需求都要通过代码来转化成实际的产品。
全新的需求如果是通过全新的方案设计来实现，那增加的代码量实际上并不多，把新需求的功能实现就可以了。这种情况属于少数情况，因为大多数情况下都是在旧的需求上边新增需求，要求新的需求也能够满足，旧的需求也要保留。这种需求的增加，就是代码变得臃肿的一个重要原因。因为要做兼容性，因此在添加新功能的同时，还要保证旧功能也可以使用。旧功能使用的技术、背后的逻辑等可能已经被淘汰或者被弃用，但是如果按照新的统一来做又不太可能，会因为缺乏某些因素(新功能必须,但是旧功能没有的因素)，所以只能在旧功能的代码中做兼容处理，这些做兼容处理的代码，就是臃肿的代码。版本迭代的越多、需求变化的越多，需要兼容的代码也就越多。于是一项非常简单的需求，由于兼容性，代码就变得异常臃肿了。
以上就是代码变得越来越臃肿的原因。
那么，这就完了吗？
作者又深入进行了思考，有没有什么办法不做兼容性？答案是有，但是效果非常不好。当年微软在手机操作系统中还占有一席之地的时候，从 windows mobile 6 升级到 windows phone 7时，软件不兼容,从 windows phone 7 到 windows phone 8时，软件又不兼容，最后，自己把自己折腾死了。做不做兼容其实是取决于用户的，而不是厂商，如果用户觉得新版本和旧版本体验跨越太大的话，他们会强烈反对的，具体的体现就是如果有可替代的产品，他会果断抛弃这一家的产品。
难道不做兼容性就只有死路一条？作者又往上进行了思考。如果产品从一开始就把后边可能出现的情况都考虑进去，那么，后边需求的改动不就很小，甚至没有了吗？嗯，沿着这个思路作者仔细想了想，发现这样才能够从根本上解决代码臃肿的问题。按照这个推论，作者发现，如果有一项能够历经岁月磨砺、检验的伟大项目，那么这个项目的设计者要得一半的功劳。
作者也好奇有没有只做了一个版本，后期就没有更新，但是仍然没有过时的产品或者技术？答案是有。学过编程的人应该对于 xml 不会陌生，这个文本格式是从1998年作为 W3C 标准，但是到目前(2019 年)为止，仍然是 1.0 版本，可见其设计的水准以及设计者的深谋远虑。要知道软件技术更新迭代是非常迅速的，http 协议都已经更新好几个版本了。
所以一个好的开始是成功的一半。
对了，代码只是人类社会生活中及其微小的一部分，如果把代码换成公司组织、国家体制，思考一下，逻辑是不是相通的？
---- 2019-1-6
网友评论