一些工程的思想和理念。这些理念需要大量的实践和沉淀， 才能有深刻的理解。
系统的依赖越少越好
这里的依赖是指对外部服务的依赖， 以及技术组件的依赖：如zk ,redis, 分布式组件等。
如果系统依赖多， 系统稳定性就非常脆弱。 如果上下游系统或者redis等宕机了， 意味着系统可能不可用。
同时意味着测试的复杂度增加，无论对于单元测试还是集成测试， 复杂度都大大增加了。对于单元测试，需要引入一堆Mock组件， 对于集成测试增加搭建环境的成本了。 这也意味着测试效率非常低下。
所以设计系统时， 对于引入额外的依赖， 要慎重考虑。 多一个依赖，意味着系统的维护成本剧增。
简单至上
如果一个系统很复杂， 引起的后果将是灾难性的， 意味着这个系统的维护成本很高。 系统的熟悉成本很高， 修改代码成本很高， 因为改代码得很谨慎啊， 系统这么复杂，万一改出新的bug，如何是好！
在系统设计中， 一定要权衡好收益和付出。 如果为了解决一个业务问题， 收益是1%， 但是花了200%的精力去解决， 同时还增加了系统的复杂性，那么就得不偿失了。
同时，如果系统变得越来越复杂了， 那么就得提问了： 是不是有不合理的需求？ 是不是架构有问题？ 是不是设计有问题？ 是不是可砍掉部分功能？ 系统是不是可以拆分？ 是不是系统抽象的不够好。 这些点都值得反思。
在追求技术精益求精的同时， 也要追求效率的精益求精！
维护复杂的系统就像陷入泥潭一样，越陷越深。
过早优化是一切罪恶的根源
在设计系统时，发现都要考虑系统的可扩展性。 但是很多时候， 过早的优化是完全没有必要。这 不仅浪费了人力资源，还提升了系统的复杂度。具体可参考 对软件可扩展性的思考
