大规模开发中最重要的基础设施组件是什么？
企业业务应用程序的基础构建块有哪些？ 我正在考虑多个应用程序共享的可重用组件，以：
- 更快地扩展
- 通过消除重新构建来加快开发速度
- 通过最大限度地减少关键故障点来提供稳定的基础架构
我在集中/标准化方面看到的成功概念的一些示例：
- 日志
- 队列
- 调度
What are some of the building blocks foundational to enterprise business applications? I'm thinking about re-usable components multiple applications share to:
- Scale up faster
- Speed development by eliminating re-building
- Provide a stable infrastructures by minimizing key points of failure
Some examples of concepts I've seen success with centralizing/standardizing:
- logging
- queueing
- scheduling
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会添加 GUI 小部件，使团队能够在应用程序中保持相同的外观和感觉。
同样，在一个大型项目中，多个团队必须处理将在某个时刻插入在一起的子系统，一组类似子系统的设计模式是非常宝贵的。
此外，创建一组通用库（或者在采用 Boost 的 C++ 中更好），当需要通用实用程序时可以使用这些库，效果很好。
我还会尽早创建带有示例的测试框架。 我发现如果你有一个用于测试子系统的模板，那么人们就会使用它。 如果早期没有任何测试框架，您必然会遇到开发人员测试的所有极端情况。
I'd add GUI widgets that allow teams to maintain the same look and feel across the application(s).
As well, in a large project where multiple teams must work on sub-systems that are going to plug together at some point a set of design patterns for similar sub-systems is invaluable.
Additionally, creating a common set of libraries (or better yet in C++ adopting Boost) which are the place to go when a common utility is required has worked well.
I would also create the testing framework with samples early on. I have found that if you have a template for testing the sub-systems then people will use it. Without any testing framework early on you are bound to get all extremes of developer testing.
当您说组件时，您是指代码组件还是基础架构组件？ 我认为基础设施（支持服务和流程），而不是代码，为开发的质量、速度和易用性带来了最大的好处。 您给出的示例现在位于大多数语言的标准库中，或者非常特定于应用程序/用例。
我还假设版本控制是给定的，因为它对于所有开发都是不可或缺的。
我想说最的基础设施将是持续构建/自动化测试。 这让人们可以编写他们想要的任何代码，签入它，并确保它与其他人的代码兼容。
第二重要的是通用库。 这些可以让人们更快地开发并建立外观、感觉和设计的标准（希望是好的）。 随着公共库的使用越来越多，持续构建的重要性也随之增加，因为这些库中的微小变化都可能导致回归。
然而，通用库的一个问题是它们需要付出很大的努力才能设计得好 - 因此它们值得重用 - 并且需要很长时间才能达到这一点。 大多数都会从特定的项目开始，然后有人将其侵入到他们的项目中，然后进行一些分支，然后复制和粘贴。 一段时间后，可能是几年后，有人会审核代码并开始将它们合并到一个公共位置。 应制定升级公共库以及如何（或是否）同时拥有两个版本的计划。 另一个隐藏的缺点是它们在短期内允许更快的开发，但从长远来看会阻碍开发，因为人们会被锁定在旧版本中（对于第三方库来说更是如此）。
第三是构建工具。 这意味着可以使用通用工具来简化构建、检查、搜索以及以任何方式与代码交互的过程。 当您提交补丁时，自动将错误标记为已解决，或者通知连续构建者依赖项已更改，或者在提交测试之前自动运行测试，从而使测试易于（且快速）运行。
第四种是密封构建，它是构建工具的简单扩展。 这意味着应用程序是独立的。 这有两个好处：1）机器重用更容易，更重要的是，2）开发人员上手非常容易 - 他们不需要安装额外的库，或更改 /etc 中的某些内容，或在其文件中设置某些内容环境 - 它只是构建和运行。
我能想到的其他一些：
When you say components, do you mean code components, or infrastructure components? I'd argue the infrastructure (supporting services and processes), rather than the code, gives the most benefit to quality, speed, and ease of development. The examples you give are in the standard libraries of most languages now, or are very application/use-case specific.
I'm also just going to assume version control is a given, since its so integral to all development.
I'd say the most important infrastructure would be a continuous build/automated testing. This lets people write whatever code they want, check it in, and make sure it works with everyone else's.
Second most important would be common libraries. These let people develop faster and establish standards (hopefully good) for look, feel, and design. As common libraries are used more, the importance of the continuous build increases, since small changes in those can cause regressions.
One problem with common libraries, though, is they take a lot of effort to design well - so they're worth reusing - and it takes a long time to get them to that point. Most will start as specific to a project, and then someone will hack it into their project, followed by some branching, then copy and pasting. After awhile, years probably, someone will audit the code and start merging them into a common place. A plan should be made for upgrading common libraries and how (or if) to have two versions of them at once. Another hidden drawback is they allow faster development in the short term, but hinder development in the long term, as people become locked into older versions (this is more true of third party libraries).
Third would be build tools. This means common tools to simplify building, checking out, searching, and otherwise having to interact with the code in any way. Things that automate marking bugs as resolved when you submit a patch, or notify continuous builders that dependencies have changed, or automatically running tests before you submit a test, making tests easy (and fast) to run.
Fourth would be hermetic builds, which is a simple extension of build tools. This means that an app is self contained. This has two benefits: 1) machine reuse is easier, and more importantly, 2) its incredibly easy for a developer to get started - they don't need to install extra libraries, or change something in /etc, or set something in their environment - it just builds and runs.
Some other's I can think of:
不完全在基础设施领域：
如果没有这些，您就需要为同一客户进行一系列应用程序开发活动。
这些都应该是现成的，以满足使用它们的应用程序的需求。 例如，J2EE 构建的应用程序的日志记录解决方案将不同于 .NET 的日志记录解决方案。 （在一家重要的企业中，单一文化本身就是一个问题。）
Not completely in the infrastructure space:
Without these you have a series of application development actives for the same customer.
These should all be off the shelve to suite the needs of the applications using them. E.g. logging solution for a J2EE built application will be different to a .NET one. (In a significant enterprise mono-culture can be a problem in itself.)