译文 | 为何软件架构如此重要？

本文翻译自：Why Software Architecture Matters
(https://www.imaginarycloud.com/blog/why-software-architecture-matters/)

抛开某项特定的技术或某个特定的项目不说，这篇文章我想讲讲关于犯错这个话题。

谈论和赞赏成功也许很轻松，可是我发现犯错还是个颇有意思的话题。主要是由于它们在学习的过程当中很有用处。

一开始我将讲一些背景知识，而后阐述一下我对软件架构的见解。 后者是我认为在软件开发过程当中最重要的一部分，而且谈下如何避免陷入常见的开发陷阱。

预热阶段

当任何一个程序员被问到：

“哪一种方式你更为热衷：从零开始一个项目，或者维护一个已存在的项目?”

他们一般回答：

“从零开始一个项目”

答案是显而易见的，由于成就感给人带来的感受更棒。咱们能够这样说：“这是我作的（至少是其中至关的一部份内容）。以前并不存在，而如今，看！就在眼前。”

但其中的意义每每不止于此。人类的大脑是喜欢有秩序的，它喜欢从一些混乱和看似随机的信息中寻找规律（模式），在软件开发中，这点也同样。

可是在一个已存在的项目中会发生什么？极可能这个项目已经掺杂必定程度的混乱，而且它的混乱程度显然比一个不存在的项目严重多了。

所以，最直接的回应（作法）是从头开始一个项目，这样的话你就能够彻底经过你的经验来把控它的混乱度。

固然，在软件的乌托邦，咱们永远不会由于疏忽大意而（给项目）形成混乱的局面。遗憾的是，咱们并非生活在那个世界，可是咱们能够用工具和原则来指导咱们。

优秀的架构省时省力

咱们所拥有的用来处理回归复原、修复BUG等使人厌恶的任务的最好方式就是提早作规划。一个优秀的架构是咱们的朋友。

一个优秀的设计解决方案顶得上数千个小时的时间，毕竟在将来它真的帮咱们省掉了不少时间。

咱们大多数都看过一些书，咱们知道要作什么。咱们一样应该认真地进行（软件）测试和应用设计模式。“让咱们真正专一并贯彻于MVC（译注：一种将业务逻辑、数据和界面显示分离的软件设计模式）；让咱们为此采用BDD模式（译注：行为驱动开发，敏捷开发技术的一种）；让咱们在写生产代码前先设计特性测试。”

有时候，咱们忘记了第一步该作什么的重要性，甚至在那以前。

架构

固然，在你写功能性代码前，是的，请写下你的第一个测试案例。

但在你写下第一个测试案例以前，设计团队有可能已经收集了全部的需求，已经与客户和其余利益相关方达成了协议，他们甚至可能已经出来了多个版本的产品设计方案并进行了多加验证，因此你可能会认为你应该当即进行代码的编写。

你应该作的

整个团队应该坐下来讨论关于他们将要开发的产品。他们应该拿出一张纸或者到白板面前，而后开始列举将来产品将要有的特性。

清晰地肯定出全部的技术要求和提议方案的可行性。考虑在实施不一样的实现方案中每一步所面临的挑战并为此想出解决措施，多是（采用）不一样的框架，甚至是不一样的编程语言。

兜底地说，（在软件开发中）没有其余事情能值得你花的时间与花在架构同样多。

从错误中学习

对于我来讲，最好的学习方式之一就是犯错。

尽管犯错会让人感到困窘和沮丧，但当咱们真犯了错，咱们就会投入精力去弄明白究竟发生了什么，会努力地寻找解决方案，找到再也不犯一样错误的最好办法。

这就等同于经验。

经验就是错误的别称。

—— 奥斯卡·王尔德

最近我在作一个很是复杂的IOS项目。在项目刚开始的时候，有几件事情是没作好的。需求并无百分百肯定，先决条件并无百分之百知足，APIs（应用程序接口）还没准备好……

但最重要的多是：咱们没有像咱们应该作的那样定义出项目的架构。

固然，我是在出现损失时才意识到这点的。咱们（当时）作了大量的还原、改写的工做，有几回我一直追问本身说：“为何我没有采用正确的方式？”

一个陷阱是：没有使用测试框架。归根到底，测试和验证是经过用户测试和代码检视来完成的。而后当一个测试框架真正地被引进项目时，这已经太晚了。

一个热门的被众人所承认的IOS开发框架并非都能适用于全部的复杂状况的，也并不必定适用于各类开发语言和弥补在设计产品架构时（从技术的角度来看）所做出的糟糕决策。

更好的方法：一些经验法则

敲黑板。你接到一个新项目，可能你在需求收集阶段就已经开始参与了。抛开脑海中已有的针对这项目的总体技术解决方案的想法，我会建议：

1. 写下全部的东西。制做图表，画组件图、类图、流程图，写下全部你以为有助于你和团队快速了解问题全貌的东西。

   平时常拿出来进行反复思考，在写下第一行代码前可能会对其作屡次的更改修正。

2. 当全部的组件/模块已经定义好了，尝试为其找一些现有的可靠的解决方案。开源框架是一个很好的方向，由于它们已经被不少人测试过和使用过，所以也会比你本身实现的方案少不少的BUG。

3. 当选择一个外部或第三方的框架时，确保它们与其余框架“合得来”。尽可能找出足够的证据证实你将使用到的框架之间都可以很好地进行兼容。

   在开发过程当中你不得不更换某些框架，由于你发现某些部分在其余框架中运行时并无像预期那样进行工做，无论怎样这都会迫使你耗费时间去另寻解决方案，同时这也会耗费你更多时间去作那些并不想作的回归工做。

4. 选择一个好的测试框架。跟上一条类似，确保测试框架无需耗费你额外的精力就能与其余框架一块儿工做。

   一个测试框架的好坏取决于它针对项目所能覆盖的测试范围。若是它对你将使用到的特定的技术和模块不是很合适或者不能彻底进行覆盖，那就不要依赖它。

八个盖子十个锅并非一个好的主意

对于下一个我将会参与到的项目，我会不遗余力遵循这些原则而且在有必要的时候进行更新。也许这里的假定有一个或多个会有所改动或者被改善。

对于开始实施一个新项目时首先应该作什么这事，若是你的经历告诉你有不一样的观点，你能够自由地分享你的观点和建议。