在此记录受益于一位大神的两句话，虽然文字不多，但读后有醍醐灌顶的感觉：
驾驭首先要做到通晓。了解所有业务逻辑的来龙去脉，知道一些典型系统设计方案以及其针对的问题，还有优劣比较。接触过一些实际的系统。在此之上，才有可能把合适的设计套用到当前的业务逻辑上，把现有的业务逻辑抽象成一个已经存在（部分）解决方案，或更经典的方式。
接手一个稳定性不好的系统，如果没有足够的时间从头设计、完全重构。那么至少要知道影响稳定性的几个关键要素，然后根据重要性、紧急性和解决问题需要的资源（时间、技能集、人等）进行优先级排序，逐个击破。对于所有的改善型动作，确保有适合的评测和监控，这样能够知道不同的措施效果到底是怎么样的。
总结：
- 对业务细节足够了解。
- 对一些经典架构要足够了解，并知道他们所针对的问题。
- 可以对比不同架构的优势。
- 对不好的架构如果没时间重新设计，得分析不好的点在哪儿，等腾出时间或人手再逐个击破。
- 重新设计后要有足够的测试，以确保没有问题。