改变生活（并节省时间！）的魔力以功能为重点的代码组织！

让我给你讲个故事

典型的应用程序是如何构建的？以及为什么这会成为一个问题。

组织和维护代码的更好方法

您的应用实际上做什么以及它如何实现

其他福利

后续步骤Next steps

规划你的软件开发职业生涯

让我给你讲个故事

我受聘于一家公司担任高级开发人员，当时该公司正处于大多数人认为的危机或十字路口。过去，开发人员之间几乎没有沟通，因此他们开发的产品完全是各自为政——没有专家指导、代码审查等等。

他们还花了大约两年时间，让一位“明星”开发人员重新设计了大部分产品。长话短说，当公司决定要培养“团队”精神，而不是让一位开发人员主导所有开发时，这位开发人员却因为不愿与其他开发人员沟通和分享而被解雇。后来才发现，重新设计的产品实际上比以前复杂一百万倍，耦合也更紧密！

所有这些都勾勒出我刚开始工作时的情形。没有人知道这个系统究竟是如何运作的。没有开发标准。添加新功能时，没有指导性的组织或架构（例如，完全自由）。

部署过程涉及一些 FTP 连接和多个步骤，可能需要长达 30 分钟——更不用说如果未按正确顺序“构建”会发生什么。诸如此类……

我立即解决的问题之一是“我应该把我的代码放在哪里？”

现有的（也就是重新设计的）功能实在太复杂了。给现有功能添加组件需要几天甚至几周的时间！其中 99% 的时间都花在了确定代码的位置上！

我将向您展示我为改善这种情况所做的工作 - 并将原本需要数周才能完成的工作缩短到几天/几小时。

典型的应用程序是如何构建的？以及为什么这会成为一个问题。

我工作过的每家拥有现有系统的公司，都会根据基础设施来组织系统/代码。例如，大多数系统都包含数据访问层、业务层（通常只是一个外壳，将逻辑推迟到数据访问层）和应用层。

应用层是 Web 应用，它调用业务层，最终进入数据访问层。大多数企业系统大概都是这样组织的。

为什么这很糟糕？有几个原因：

• 由于使用其他技术或范例的好处而需要有所不同的系统部分（功能）通常会被忽略，因为它们与管理架构不“匹配”。

• 查找系统的特定功能非常困难，因为它们分散在代码的多个区域中。

• 因此，修复或添加现有功能需要更多时间。

• 这导致开发人员对产品的理解和谈论方式与公司中其他人的理解和谈论方式出现分歧。

• 整个解决方案或代码库以根本的方式“粘合”在一起。

想象一下，您是一家公司的新开发人员。想象一下这样一个应用程序的文件夹/结构（您可能现在已经在另一台显示器上打开了一个应用程序）。仅从总体上看，您能告诉我这个应用程序的功能吗？

• 它解决了哪些业务问题？
• 您的公司关心什么问题？
• 该系统有哪些功能？

你不能。至少，不容易。代码是根据基础设施考虑来组织的，而不是业务导向的。

组织和维护代码的更好方法

我们该如何解决这个问题？这个想法很简单。只是它与行业惯常的做法截然不同。根据公司实际生产的产品和功能来组织代码！

例如，电子商务应用程序可能具有（我能想到的）“搜索”、“浏览”、“购物车”、“付款”等功能。

想象一下，我要求您（新加入团队和产品的开发人员）添加一项新功能：允许用户使用比特币付款。

你能想清楚应该从哪里开始吗？

是的，这是一个反问句。（应该问“付款”😉）

您的应用实际上做什么以及它如何实现

本文的重点是，你应该关注你的系统能做什么，而不是系统如何实现它。以一个典型的 MVC 结构为例：

你能告诉我这个应用能做什么吗？它能解决哪些业务问题？你会从哪里开始尝试调试某个功能？

现在，看看这个：

那现在呢？

附注：如果您使用的是 MVC 框架（例如），那么您可以将以下每个功能放入它自己的“迷你”应用程序中：

现在，您的解决方案主要集中于您要解决的业务领域 - 而它恰好是一个 MVC 应用程序。

其他福利

这会带来其他好处，例如：

• 如果对不同技术的需求合理，各个功能在实现细节上可以有所不同。由于它们不受已确定基础设施组织结构的束缚，因此特定功能可以根据需要进行演进。

• 单个功能的复杂性是孤立的，不会渗透到其他“层”或代码部分。

• 查找特定功能或功能部分的代码非常快。

• 它迫使开发人员思考并专注于业务和产品，而不是如何将业务目标强行塞入预定义且不相关的结构中。

• 整个系统并不像典型范例那样“粘合”在一起。

为了强调最后一点，许多读者会注意到，这提供了以后将这些功能提升到我们大多数人所说的“微服务”中的灵活性。

如果网站 70% 的流量和总体负载都针对“搜索”功能（由于需要所有数据库查询或其他原因） - 我们可以将该功能从代码库中“提升”出来作为它自己独立的项目（或模块、包等）并通过在运行时运行此功能的多个实例（比如说使用容器）来扩展它。

其余功能现在占总负载的 30%，可以放在性能仍然足够好的更便宜的服务器上。

后续步骤Next steps

我鼓励你在下一个项目中尝试这个策略。请通过推特@jamesmh_dev告诉我效果如何！

如果您正在寻找有关这些想法的更多细节和想法，我建议您从以下资源开始：

垂直切片架构
实体架构：切片而非层（视频）
清洁架构

PS：这篇文章最初发表在builtwithdot.net的博客上

规划你的软件开发职业生涯

一封电子邮件通讯，我将在其中回答订阅者的问题并围绕以下主题提供建议：

✔ 软件开发人员通常经历哪些阶段？
✔ 我如何知道自己处于哪个阶段？如何进入下一个阶段？
✔ 什么是技术领导者？如何成为技术领导者？

听起来很有趣？加入社区吧！