0

企业业务应用程序的基础构建块有哪些？我正在考虑多个应用程序共享的可重用组件：

  1. 更快地扩大规模
  2. 通过消除重建来加速开发
  3. 通过最小化关键故障点提供稳定的基础架构

我在集中化/标准化方面看到的一些成功的概念示例：

  • 日志记录
  • 排队
  • 调度
4

3 回答 3

1

我会添加允许团队在应用程序中保持相同外观和感觉的 GUI 小部件。

同样，在一个大型项目中，多个团队必须在子系统上工作，这些子系统将在某个时候组合在一起，一组类似子系统的设计模式是非常宝贵的。

此外，创建一组通用库（或者在采用 Boost 的 C++ 中更好）是需要通用实用程序的地方，效果很好。

我也会在早期创建带有样本的测试框架。我发现如果你有一个用于测试子系统的模板，那么人们就会使用它。在早期没有任何测试框架的情况下，您一定会获得所有极端的开发人员测试。

于 2009-03-26T16:24:30.030 回答
1

当您说组件时，您是指代码组件还是基础架构组件？我认为基础设施（支持服务和流程），而不是代码，为质量、速度和易于开发带来了最大的好处。您提供的示例现在位于大多数语言的标准库中，或者非常特定于应用程序/用例。

我也只是假设版本控制是给定的，因为它对所有开发都是不可或缺的。

我想说最重要的基础设施是持续构建/自动化测试。这让人们可以编写他们想要的任何代码，将其签入，并确保它可以与其他所有人的代码一起使用。

第二个最重要的是公共库。这些让人们可以更快地开发并建立外观、感觉和设计的标准（希望是好的）。随着公共库的使用越来越多，持续构建的重要性增加，因为这些库的微小变化可能会导致回归。

但是，通用库的一个问题是，它们需要付出很多努力才能设计得很好——所以它们值得重用——而且需要很长时间才能达到这一点。大多数会从特定于一个项目开始，然后有人会将其破解到他们的项目中，然后进行一些分支，然后复制和粘贴。一段时间后，可能是几年后，有人会审核代码并开始将它们合并到一个共同的地方。应该为升级公共库以及如何（或是否）同时拥有它们的两个版本制定计划。另一个隐藏的缺点是它们在短期内允许更快的开发，但从长远来看会阻碍开发，因为人们会被锁定在旧版本中（第三方库更是如此）。

第三是构建工具。这意味着可以使用通用工具来简化构建、签出、搜索以及必须以任何方式与代码交互。当您提交补丁时自动将错误标记为已解决，或通知持续构建者依赖项已更改，或在您提交测试之前自动运行测试，使测试易于（且快速）运行。

第四是密封构建，它是构建工具的简单扩展。这意味着应用程序是自包含的。这有两个好处：1）机器重用更容易，更重要的是，2）开发人员上手非常容易 - 他们不需要安装额外的库，或更改 /etc 中的某些内容，或在他们的环境 - 它只是构建和运行。

其他一些我能想到的：

  • 监控：如果一切都使用相同的监控方法，那么人们就不必黑盒监控公共库。由于所有数据都在一个地方，因此它还可以更轻松地识别问题。
  • 日志存储：Grepping 和 groking 日志是一种痛苦。拥有一个所有日志以结构化格式存储的集中位置，可以轻松搜索和发现问题。
  • 分支管理：在一个大型项目中，这让开发人员可以开发、测试人员测试和发布人员发布，而无需互相干预。
于 2009-03-26T17:21:35.667 回答
0

不完全在基础设施领域：

  • 定义的逻辑数据模型。
  • 定义的业务流程（涵盖边缘案例）。

如果没有这些，您将拥有针对同一客户的一系列应用程序开发活动。

  • 日志记录
  • 排队
  • 调度

这些都应该是现成的，以适应使用它们的应用程序的需求。例如，J2EE 构建应用程序的日志记录解决方案将不同于 .NET 的。（在一个重要的企业中，单一文化本身就是一个问题。）

于 2009-03-26T16:26:34.957 回答