在这一系列文章中，让我们来探讨如何创建自己的系统架构。
什么是系统架构？
系统架构是系统设计的最高层次。
系统设计是帮助应用程序代码编写的方法。
应用程序是实现业务目标的媒介。
可以忽略它吗？
即使在编写应用程序之前没有做好系统设计，你在编写任何代码之前依然要思考（如何实现），这就是所谓的意外系统设计，这将导致意外的系统结构（AA）。
很容易出现的意外架构：
Q：为什么我们的代码如此丑陋？
A：历史原因...
能够学到什么？
与其根据代码的成长设立准则、约束和模式，不如建立一个正确的体系机构。
系统架构就像铺设一条铁路，让编程的火车沿着它前行。
为什么要制定约束？
准则、约束和模式有助于：
- 遵循最小惊讶原则
- 理解现有系统是如何运作的
- 避免重复造轮子
- 在社区中分享你的创意
可以直接使用别人的架构吗？
你应该向他们学习，但他们可能有许多问题：
- 不提供增长策略（后续提升）
- 只适合一个规模的应用程序和团队
- 组件化和模块级别不确定
- 角色分工不明确（我看着你的“工人”）
- 太过死板或难以理解
我们是否有足够的能力来设计它？
没有人是足够的，但你懂得越多，越有希望。
以下建议也许能有所帮助：
- 阅读关于系统架构和设计模式的著作
- 不要相信有万能钥匙（没有一种架构是能够适用任何情况的）
- 在学习中分享对他人有用的知识
- 从其他平台中汲取经验和灵感
- 在业余时间尝试你的想法，如果它们很不错，那么就在工作中引进它们
- 如果有不确定性，暂时推迟决定（先使用稳妥的方法实现，再考虑改进）
- 与他人讨论想法和实现过程
如何开始？
首先，分析目标需求（尽可能完整）
功能要求
在最坏的情况下，可以得到一个清晰的功能说明书，如下：
- 应用程序功能列表
- 功能之间如何协作
- 哪些功能不需要连接互联网也能使用
在这个阶段，可能会认为需求已经足够满足业务，而你有责任对出现的众多问题寻找答案，例如： - UI看起来怎么样？
- 应用程序必须支持哪些设备？
- 需要做服务器端吗？
当你想不出其他问题要问时，就可以进入下一阶段了。
组织的需求
如果不是一个新的项目，那么可能有很多东西限制你的架构选择，至少要解决这些问题：
- 团队成员的水平？
- 他们对我们的架构有什么期待？
- 我们见了了工具和语言吗？
- 我们能重用现有的架构吗？
解决了上面的问题，就可以开始架构了吗？
是的，可以开始了。通过将功能和组织需求结合起来，您可以开始概述您的想法，并最终组成一个正式的体系结构！但这是一个完全不同的故事…
这就结束了吗？
在你的想法正式上线之前，我建议你对它们进行压力测试（根据下面的清单进行全面检查）。
以你的候选架构为例，尝试回答清单中的问题。
附：问题清单
健壮性、可扩展性
- 能有效地处理不断变化的业务需求吗？
- 支持在现有项目中逐步采用吗？
- 允许轻松地替换第三方组件吗？
- 是否鼓励小的独立组件的组合？
- 允许稍后向功能添加UI吗？
- 是否支持在集成而不是组件级别上打破保留循环？
- 支持人们同时在功能的不同部分工作吗？
- 是否限制了事件/通知系统对特定层的使用？
- 是否为偷工减料和技术债务提供了策略？
可维护性
- 是否提供了应对重型对象的策略？
- 是否限制对象的依赖项的数量？
- 样板代码量是否已经尽可能少了？
- 不同职责的组件是否已经足够细致？
- 项目结构是否可以改变？
- 能够运转正常吗？
是否易于理解
- 是否能够清晰的理解如何在组件之间传递数据？
- 应用流程是否能够理解？
- 是否避免了暂时依赖？
- 是否定义了如何存储状态？
- 是否最大程度地减少全局状态的数量？
- 允许打开一堆界面吗？
- 点击推送通知时能正确地跳转到对应界面吗？
代码质量
- 是否最大化可测试代码的数量？
- 是否建议使用runtime？
- 是否避免了强耦合？
- 是否允许用同步测试异步代码？
- 是否支持UI测试？
- 是否能够捕获异常？
译自：🚧Designing iOS architecture: Motivation
如有错误请指正
网友评论