- 互联网架构并非靠设计出来的，而是经过实战不断演练而成，因此经验尤为重要。
- 代码量是无法真正权衡水平的，在做需求时多去思考更合理的解决方案、写代码时尽量避免重复劳动，才是我们要追求的。
- 实际软件工程项目中，模块切分的太大则会产生模块化不足的现象，模块切分的太小则会陷入过度模块化陷阱。
- 模块化不足会让你的项目失去灵活性，并且与业务高度耦合，相同的代码不得不写多次才能实现同样的功能；
- 而过度模块化则会让程序员记忆成本增加，并可能出现只有在特定情形下多个模块组合才能达成某个目的的“魔法组合方式”，不利于维护。
- 随着业务的变化、系统设计也要持续演进升级。
- 没有一开始就完美的架构， 好的架构设计一定是演化来的，不是一开始就设计出来的。
写代码的时候 代码要有课扩展 ( 面向抽象接口编程)，维护，重用
- 假设这几行代码可以完成一个功能，提炼到一个方法里面去
- 假设这个方法在某个业务逻辑层可以共用，往上抽取
- 假设这个方法在多个模块之间要共用，就把它提炼到一个工具类里面去
- 假设这个方法在多个系统里面可以共用，那把这个方法发布成一个webservice 服务(系统级别的重用)
架构的本质是降本增效，是对业务场景抽象后得出的支撑框架，架构为业务而生，被业务场景抛弃
每一次的架构设计都是企业和团队技术研发力、业务复杂度、规模大小、时间成本、运维能力等各方面折中的结果