从哪些方面去思考产品架构
1. 针对App
- 如何让业务开发工程师方便安全地调用网络API？然后尽可能保证用户在各种网络环境下都能有良好的体验？
- 页面如何组织，才能尽可能降低业务方代码的耦合度？尽可能降低业务方开发界面的复杂度，提高他们的效率？
- 当数据有在本地存取的需求的时候，如何能够保证数据在本地的合理安排？如何尽可能地减小性能消耗？
- iOS应用有审核周期，如何能够通过不发版本的方式展示新的内容给用户？如何修复紧急bug？
2.针对团队：
- 收集用户数据，给产品和运营提供参考
- 合理地组织各业务方开发的业务模块，以及相关基础模块
- 每日app的自动打包，提供给QA工程师的测试工具
架构设计的方法
第一步：搞清楚要解决哪些问题，并找到解决这些问题的充要条件：清楚你要做什么，业务方希望要什么。而不是为了架构而架构，也不是为了体验新技术而改架构方案
第二步：问题分类，分模块
第三步：搞清楚各问题之间的依赖关系，建立好模块交流规范并设计模块
第四步：推演预测一下未来可能的走向，必要时添加新的模块，记录更多的基础数据以备未来之需
第五步：先解决依赖关系中最基础的问题，实现基础模块，然后再用基础模块堆叠出整个架构
第六步：打点，跑单元测试，跑性能测试，根据数据去优化对应的地方
总而言之就是要遵循这些原则：自顶向下设计（1，2，3，4步），自底向上实现（5），先测量，后优化（6）。
什么样的架构是好架构？
- 代码整齐，分类明确，没有common，没有core
- 不用文档，或很少文档，就能让业务方上手
- 思路和方法要统一，尽量不要多元（先确定解决思路，再开搞）
- 没有横向依赖，万不得已不出现跨层访问
- 对业务方该限制的地方有限制，该灵活的地方要给业务方创造灵活实现的条件
- 易测试，易拓展
- 保持一定量的超前性
- 接口少，接口参数少
- 高性能
关于架构分层
原则：自顶向下的设计方式
- 先确定所有要解决的问题
- 确定都有哪些模块
- 这些模块再往下细化设计
- 把这些列出来的问题和模块做好分类。
- 分类之后不出意外大多数都是三层。如果发现某一层特别庞大，那就可以再拆开来变成四层，变成五层。