演进式架构读书笔记（四）：陷阱与反模式

• 演进式架构的陷阱和反模式

1. 反模式：供应商为王。即以供应商提供的架构为核心来组织自身业务，被供应商掌控全局。类似于20200517的HW事件，美国通过掐断半导体晶圆片的供给（非禁止，要许可）。也就是说，如果你的商业帝国强烈依赖于第三方供应商（尤其是不可替代），那么可能大厦一夜即倾。
2. 陷阱：抽象泄露。所以重要的抽象，在某种程度上都会泄露。随着技术栈的不断变化，如何保证业务在技术不断发展时还能保持一定的稳定性？当然，重建几乎是不可避免的，但如果能在重建时付出的代价较小，显然对组织的研发效率是具备正面效应的。
3. 反模式：最后10%的陷阱。世界是复杂的，需要用动态平衡的思维去解决问题。如果企图使用某种快速开发工具来构建大型复杂软件，最终10%的需求大概率会无法满足，这时再回归通用语言就会代价奇高。
4. 反模式：代码复用和滥用。复用代码更像是器官移植而非乐高积木。乐高积木是软件设计的高级阶段，是理想。复用在某种程度上，确实是种耦合。在微服务架构中，通过增加重复来尽量减少耦合（耦合无法避免）。但更佳的思路，应该是允许对代码复用（在一定程度，应该提倡复用），但代码复用后，要允许业务开发者针对此代码进行扩充或者修改。一种更理想的方式是，对可复用代码也设置适应度函数，保证其在不断有新需求的情况下，仍具备演进能力。否则，复用代码会很快腐烂，因为需求的变化是必然的。在这里，还要撇清一个可能误导的概念。微服务强调的重复，应该是在服务间的。如果在服务内部，一个概念应该还是要有唯一的表达。
5. 陷阱：简历驱动开发。不要为了架构而构建架构，构建架构是为了解决问题。
6. 反模式：管理不当。警惕（但不应该杜绝）一切共享型的导向。要始终从问题域入手，实事求是。金发姑娘与三个小熊，隐喻了可以针对不同的项目特点，来选取不同的架构模式。
7. 陷阱：发布太慢。演进的速度和生产周期成正比，生产周期越短，演进速度越快。生产周期是指从真正写代码开始到系统发布？
8. 陷阱：产品定制。定制必然导致不同的版本分支，增加开发管理和测试的负担，同时影响演进速度。需要对定制需求做一个实事求是的评估，而不是为了销售无限制定制化。
9. 反模