🤱🏿 📳 🤶🏻 如何每周阅读和修复100,000行代码 🔯 🧘 🙍

从一开始，总是很难弄清楚这个大老项目。建筑评估是建筑师的活动之一。通常，您必须处理大型的旧项目，并且必须在一周内提供结果。

每周如何评估大小为10万行或更多代码行的项目，同时为客户提供真正有用的结果。

大多数架构师和那些负责人都曾遇到过类似的项目评估。在我们公司中，它看起来像是一个半正式的过程或作为一项单独的服务，无论如何，大多数人都已经对此进行了处理。

您的非俄语朋友的原始英语在这里：一周内的体系结构评估。

我们公司的做法

我将告诉您它在我们公司的运作方式以及在这种情况下的行事方式，但是您可以根据您的项目和公司的需求轻松更改此方法。

有两种架构评估。

内部的 -我们通常在公司内部的项目中这样做。任何项目都可以要求进行体系结构评估的原因如下：

团队认为他们的项目是完美的，这令人怀疑。我们遇到过这样的情况，并且在这样的项目中，往往一切都不尽人意。
团队想要测试他们的项目和他们的决定。
团队知道一切都不好。他们甚至可能列出主要的问题和原因，但是他们需要完整的问题列表和建议以改进项目。

外部评估是比内部评估更为正式的过程。在一切都不好的情况下，客户总是只会出现一种情况。通常，客户了解存在全局问题，但无法正确确定原因并将其分解为各个部分。

评估外部客户端的体系结构是一个更复杂的情况。该过程应更加正式。项目总是大而古老的。他们有很多问题，错误和弯曲的代码。关于已完成工作的报告应在最多几周内准备好，其中应该有主要问题和改进建议。因此，如果我们处理项目的外部评估，那么内部将是一堆废话。考虑最困难的情况。

评估企业项目的架构

一个典型的评估项目是一个大型，古老的企业项目，存在很多问题。一位客户来找我们，要求修复他的项目。就像冰山一样，客户只能看到问题的一小部分，却不知道水下有什么（在代码的后面）。

客户可能抱怨并可能知道的问题：

性能问题
可用性问题
长期部署
缺乏单元测试和其他测试

客户最可能不知道的问题，但项目中可能存在这些问题：

安全问题
设计问题
错误的架构
算法错误
技术不当
技术债务
无效的开发过程

正式架构评估流程

这是我们在公司中遵循的一个正式流程，但是您可以根据您的公司和项目自行调整。

顾客要求

客户要求评估当前项目的体系结构。我们负责人收集有关该项目的基本信息，并选择必要的专家。根据项目的不同，他们可能是不同的专家。

解决方案架构师是负责评估和协调的主要人员（通常是唯一的人员）。
特定于堆栈的专家 -.Net，Java，Python和其他技术专家，具体取决于项目和
Cloud专家技术-这些专家可以是Azure，GCP或AWS云架构师。
基础架构 -DevOps，系统管理员等
其他专家是大数据，机器学习，性能工程师，安全专家，质量保证主管。

项目信息收集

您应该收集有关该项目的尽可能多的信息。您可以根据情况使用不同的技术：

问卷和其他通过邮件交流的方式。最无效的方式。
在线会议。
交换信息的专用工具，例如：Google doc，Confluence，存储库等。
举行“现场”会议。最有效，最昂贵的方法。

应该从客户那里收到什么？

基本信息。这个项目是关于什么的？其目的和价值。未来的主要目标和计划。业务目标和策略。主要问题和预期结果。

有关该项目的信息。技术堆栈，框架，编程语言。本地或云部署。如果项目在云中，则使用什么服务。使用了哪些建筑和设计模式。

没有功能要求。所有要求都与系统的性能，可用性和可用性有关。安全要求等

基本的键和数据流。

访问源代码。最重要的部分！您绝对应该可以访问有关如何组装项目的存储库和文档。

访问基础设施。可以访问舞台或生产基础结构，以便与现场系统配合工作，这将是很好的选择。如果客户拥有用于监视基础结构和生产力的工具，那么这将是巨大的成功。我们将在下一节中讨论这些工具。

文件资料。如果客户有文档，这是一个好的开始。它可能已经过时了，但这仍然是一个好的开始。永远不要相信文档-请在真实的基础结构上和源代码中与客户端进行检查。

体系结构评估过程

那么，如何在这么短的时间内处理如此大量的信息呢？首先，并行化工作。

DevOps应该研究基础架构。我把那些带入了代码。绩效工程师可以查看绩效指标。数据库专家应该更深入地研究数据结构。

但是，如果您有很多资源，这是一个理想的情况。通常，一个项目由一到三个人进行评估。您甚至可以自己进行评估，如果您在项目的所有领域都有适当的知识和经验，这通常会发生。在这种情况下，您需要使所有过程尽可能自动化。

不幸的是，您将必须手动阅读文档。凭借适当的经验，您可以快速了解文档的质量。那里什么是真实的，什么显然与现实不符。有时，您可能会在文档中找到这种架构，在现实生活中将永远无法使用。这是引发您思考的触发器，但是在项目中如何实际完成。

自动化项目评估的有用工具

评估代码是一个简单的练习。您可以使用静态代码分析器来显示设计，性能和安全性问题。以下是其中的一些：

结构101对建筑师来说是一个很好的工具。它将向您展示全局，模块之间的关系以及潜在的重构区域。像所有好的工具一样，它要花很多钱，同时您可以使用30天的试用版。

SonarQube是一个很好的旧工具。静态代码分析工具。使您能够识别20多种编程语言的错误代码，错误，安全问题。

所有云提供商都具有基础架构监视工具。这将使您能够在成本和性能方面正确评估基础架构的有效性。对于AWS，这是可信赖的顾问。对于Azure，它只是一个Azure Advisor。

其他性能监控和日志记录可以帮助您发现所有级别的性能问题。从查询效率低的数据库开始，到后端，再到前端。即使客户端以前没有安装这些工具，您也可以将它们快速集成到现有系统中，以识别性能问题。

与往常一样，好的工具值得。我可以推荐一些付费工具。当然，您可以使用开源，但是您将需要更多时间。并且这应该提前完成，而不是在评估体系结构的过程中。

新的
Relic-应用程序性能评估工具Datadog-基于云的姐妹监视服务

有许多用于安全测试的工具。这次，我将向您推荐一个免费的系统扫描工具。

OWASP ZAP是用于扫描Web应用程序是否符合安全标准的工具。

全部放在一起。

我们正在准备报告

从客户数据开始您的报告。描述项目的目标，限制，非功能性需求。在此之后，所有传入的数据都应提及源代码，文档，基础结构。

下一步。列出您手动或使用自动化工具发现的所有问题。将大型自动生成的报告放在“应用程序”部分的末尾。这里应该是所发现问题的简短明了证据。
优先处理在错误，警告和信息量表上发现的问题。您可以选择自己的比例尺，但这是公认的。

作为一名真正的架构师，您必须提供有关如何解决已发现问题的建议。描述客户将获得的业务改进和价值。如何从中显示业务价值我们之前讨论过的体系结构重构。

用小迭代准备路线图。每次迭代都应包含执行时间，描述，改进所需的资源量，技术价值和业务价值。

我们完成架构评估，并向客户提供报告

永远不要仅仅通过邮件发送报告。没有适当的解释，它可能会或可能不会被阅读，或者无法理解。简而言之，实时交流有助于消除人与人之间的误会。您应该与客户开会，讨论发现的问题，重点放在最重要的问题上。值得客户注意那些他甚至不会怀疑的问题。例如安全性问题，并说明它们如何影响业务。显示改进的路线图，并讨论更适合客户的不同选项。它可以是时间，资源和工作量。

作为集会的摘要，请将您的报告发送给客户。

最后

评估体系结构是一个复杂的过程。要正确进行评估，您需要有足够的经验和知识。

的确如此-在短短一周内为客户及其业务提供有用的结果。即使你一个人做。

根据我的经验，在中间下载了许多改进，有时甚至从未开始。那些为自己选择中间立场并且仅对劳动力最少的业务最有用的改进措施的一部分，极大地改善了产品质量。几年之后什么也不做的人可以完全关闭该项目。

您的目标是以最低的价格向客户展示最大的改进。您可以在闲暇时阅读体系结构

部分的其他文章。

希望您能编写干净的代码和好的体系结构解决方案。

我们的facebook小组是Software Architecture and Development。

如何每周阅读和修复100,000行代码