程序思考
程序流程
出现问题
bug、新需求、新的场景要兼容等等
解决问题
- 为什么会出现这种问题？
- 问题汇总和细化
- 问题归类
- 解决问题方案
- 该方案会导致其它问题吗？权衡。风险、概率、损失
总结
通常来说解决一类问题，都会导致其它问题的发生，所以需要尽量提前预期到。
好的设计一个意义在于能通过整体规划来把不可控因素控制在一定范围内。
一个程序在早期就能有意识规避 bug ，那远远好于在后期发现 bug，进行处理，越复杂系统越是如此。
设计的意义
设计在于可以为未来扩展做很好的铺垫。在现在快速试错的市场下，敏捷开发和快速迭代是基本要求。期间我们可以注意到在一开始的瑕疵，到中后期想修复需要付出上千倍不止的代价。
所以在开始阶段，我们可以有一个长远的目标，可以不清晰，不明确，主要是看的远。然后尽量朝着目标靠近，这样可以为后面减轻大量的工作。
期间一个重要的指标是区分重要程度，否则这里很容易陷入各种细节，导致工作和收益明显不成正比。之前我在开发中就经常陷入细节中，比如发现代码有几万分之一甚至几十万分之一的概率出错，如果这是随手修改倒还好，但一旦要修改大量代码就有点不值当。会大量提高成本包括复查、测试、风险等。针对这种问题，我们可以把它局限在很小范围内简化处理，如果能稍带上一个日志能检测更好。当然，在要求严格的场景发现这种问题，那要尽快汇报解决。
我们能根据目标和需求把各个细节都局限在各个方块内，做到就算一个被替换或者出错也不会影响其它，就算基本成功了。至于这种设计是否能优化，符合需求，做到更好，就是仁者见仁，智者见智了。有人持有性能第一，那么就会从性能考虑，算法等等放一块统一优化处理，以算法为核心。有人持有架构第一，那么会从扩展性考虑，根据模块未来考虑将其解耦，通过接口隔离等等方式。
比如我在公司做基本库和组件的工作，负责 app 底层的架构和设计。这块就要求能看的远，预期到 app 未来的方向，最可能或者最通用会朝哪个方向发展。从而能做到支持 app 业务快速开发工作。如果让 app 业务开发组用起来还觉得麻烦，而且不能实际解决问题，那么可以想象 app 基本不会使用，宁愿自己开发个简单的，满足自己需求的。
这一点其实之前我比较看好 Picasso 的图片处理库，因为它精巧简洁，能很好满足简单使用和自己自定义的使用。但后来发现 glide 使用的更广泛，因为 glide 加了很多实用功能，比如图片加载和 activty 生命周期绑定，自动三级缓存，按大小缓存（以空间换时间）等等，但它又不想 Fresco 侵入性强，用法复杂等缺点。可以说 glide 提供了一站式服务，而且能满足大部分场景，这一点是其它库无法直接媲美的。对业务开发者来说明显 glide 这种更符合要求。