类型别名的存在，是 渐进式代码修复(Gradual code repair) 的关键，什么是渐进式代码修复？
举一个例子，重构。重构代码，我们当然希望重构后的好处，能够适用于所有代码，但是，重构的好处与代价是成正比的，往往一次重构会伴随着大量的修改，随着代码量越来越大，一次完成所有修改变得不可行。修复需要逐步完成。
假如现在，我移动了 xxxpkg.buff 到 xxxpkg.byte 下，或许只是移动了两个文件，但是带来的是需要修改 N 个引用的文件，这样的修复，比实际的移动多了 N倍，随着代码量的增长，可能是更多倍。
在代码量少时，我们可以一次性完成所有的修复，这样的修复被称为原子代码修复(atomic code repair)，它的概念很简单，就是在一次提交中，更新所有的因为重构带来的问题修复，但是概念的简单会被实际的复杂性抵消，一次提交可能非常大，大的提交很难去一次性修复，出现问题也很难去溯源，最重要的是，可能会与其他同学的工作产生冲突，例如某个同学，在工作时，使用了旧的 API，合并代码时，并不会产生冲突，而我的提交错过了它的引用。
因此，我们需要一个过渡期，这个过渡期就是为了逐步替换，也就是渐进式代码修复，将旧的引用，逐步替换，同时将旧的换为新的，这就是渐进式代码修复，它的缺点是比原子代码修复的工作量更大，但是它更容易提交、审查，并且保证了，没有人引用后再删除旧的类型别名。
总结一下，类型别名，在特定情况下，帮助代码逐步修复。
