项目中的大改动

前因

用户对程序员说：这个导出的目录文件（HTML）有两个问题：一个是点击链接打不开，另一个问题是用表格方式不贴近现实作为一个目录页面的格式。

程序员表现出有点无奈，也有点惊讶和一点愤怒。总的来说，改动不是问题，问题是需求之前不是谈好了吗，现在说改，则浪费了一天的时间。

项目需求改动

针对输出格式的改动，在行业是很普遍的：这里字体大一点，这里颜色调深一点，这里用表格方式展示这些数据，那边用一个柱状图来展示…… 相信这些改动，做过项目的人绝不会陌生。这些改动，相对另外一些改动（后面会解析），是比较容易的。

系统中可能的改动，按一般代码分层结构来看，大致可分为：

1. 界面改动（包括界面／通讯接口格式／系统与外部世界交互的地方）
2. 逻辑改动
3. 结构改动（数据模型、领域模型）
4. 框架改动

越在上层，感觉改动越容易，原因改动的底层不受影响，只影响上层的代码，改动量比较少，这是代码结构分层的必然结果。

假如你改动业务逻辑，你所需要操作的界面很大机会要改掉，甚至重做。同样道理，如果你改动数据结构，你的整个逻辑算法都得改掉，但是否需要改动界面，就看数据结构的改动如何影响逻辑算法暴露给上层的接口，隔离不好的，或者逻辑根本不兼容的，界面层一样要改。

通常，业务不会干涉技术用什么框架的，所以框架改动存粹是技术选型或者