大家好，欢迎来到停止重构的频道。
本期，我们讨论网站系统的扩展性。
扩展性指的是网站系统应该如何更好地处理需求变化、版本迭代。
对于有几个项目经验的人来说，可能对这样的问题不以为然，毕竟devops、CI/CD、git、敏捷开发、版本计划这些是耳濡目染的。
但是，很多项目还是会不断发生功能回退、每次版本发布几乎都要通宵、每次追加功能都需要花很长时间重新捋逻辑且bug频出。
这就是扩展性不好的表现，即使用上了与大公司一样的工具，效果也终将还是一塌糊涂。
其实，这是一个误区，扩展性并不单单是如何做好版本流程。
而是应该思考如何处理需求的变化，提升扩展性的关键是处理好需求的变化。
我们按这样的顺序讨论
-
迭代计划
-
代码规整
-
发布流程
迭代计划
迭代计划是非常重要的，很多项目的做法是，先明确上线日期，然后倒推每个功能点的完成时间。
这样确实能做出一份看起来很漂亮的计划，但这样的计划是没有现实意义的，往往也只会延期再延期。
关于迭代计划详细的介绍可以参考我们往期的《项目过程》。
我们推荐的做法是 ：根据业务架构把整个项目分为多个独立的子项目。
然后把当前需要进行的子项目分为三个阶段：主功能阶段、次要功能阶段、优化阶段。
之后，可按实际情况在每个阶段再细分迭代周期。
这样的好处是能很好地适配需求变化，主功能是不会变化的，也是优先保证的，不可能一开始要做一个直播平台，后来改做商城。
次要功能一开始是需求模糊的，也是需求变化的主要部分，但主体功能做完后，次要功能也是会逐渐清晰，基本能判断次要功能的合理性。
优化需求是最无法预测的，甚至很多都是突发的灵感，这些需求建议是集中在优化阶段处理。一是可以等项目大体成型后再判断功能的合理性；二是冷却灵感冲动，能更加理性地判断功能的必要性，不然，这些小功能看似体量都不大，但回顾一些严重延期的项目，往往就是胡乱追加这些不起眼的小功能造成的。
代码规整
在往期视频中不断强调编码规则，因为网站项目的需求是会变化的，而且一般会一期二期三期地持续建设。
很多项目的做法是，想适配未来的变化，把一些可能可以复用的代码抽离出来以减少后续的工作量。但是其实这样的做法不一定是好的。
抽离过多的通用代码会让代码结构十分臃肿，然感觉效率很高，但是一旦大版本迭代、团队人员流动的话，那代码就会变成一团乱麻。
在前面《代码少并不代表效率》中已经讨论过，做项目是需要考虑到需求可能会变更，且以后需要持续迭代的。
如果每次追加修改功能、排查BUG都需要长时间捋逻辑、定位修改点的话，那么项目只会越做越难。
当然，代码规整并不等于采用哪一套编码规范、符合什么国际标准，而是让团队近似千人一面地完成编码任务，无论规则看起来多简单或笨拙。
这样无论谁接手或离开，都不会存在代码黑洞，因为大家写的代码基本逻辑是相似的。
这样做的话，还能让迭代计划更顺利的完成，这其实在缓解软件项目的一大难题，量化，能相对准确地量化工作量，就不会出现严重延期的情况。
关于代码规整化更详细的讨论，可以参考往期《前端规整化》、《后端规整化》 。
发布流程
发布流程最好是先发布到测试环境，通过测试后再发布到生产环境，且测试期间不随意追加功能。当然为了节省发布成本，也可以只对大版本执行这样的流程。
为了防止人为问题，最好搭建CI/CD自动发布流程。
由于不可能每次发布都对全功能进行测试，所以很难避免新版本不会对旧功能产生影响，最好的做法是灰度发布，但是全部功能都实现灰度发布是不现实的。
我们推荐的做法是（也是很多项目的做法），整理网站系统的主要功能，在每次发布完成后，都进行最小集测试（1小时内可测试完），以保证主体功能不会出现问题。
另外，除非紧急漏洞，发布周期最好限制在一周一次，且最好不要在周五发布（周末很难第一时间响应），频繁且随意地发布可能会出现一些意想不到的突发问题，这些问题会无形中不断打乱计划。
根据项目规模，最好保留2次以上的历史版本备份，以便快速恢复，版本备份让团队有了暂时不修改问题的选择。
因为一些时候，新版本其实无关紧要，而正在进行的迭代可能十分重要，需要保证工期。
总结
以上是扩展性需要思考的几个关键问题，这些问题与我们使用什么工具无关。
但如果处理好这些问题，那么项目就会变得顺畅。
把变化考虑进来，会让架构、管理更加有用可行。
我们应该更加理性地接受和处理变化，而不是永远想着，顶一顶，就扛过去了。