企业业务应用程序的基础构建块有哪些?我正在考虑多个应用程序共享的可重用组件:
我在集中/标准化方面取得成功的一些概念示例:
答案 0 :(得分:1)
我添加了GUI小部件,允许团队在整个应用程序中保持相同的外观。
同样,在一个大型项目中,多个团队必须在子系统上工作,这些子系统将在某些时候插入一组相似子系统的设计模式是非常宝贵的。
此外,创建一组通用的库(或者更好的C ++采用Boost),这些库是需要通用实用程序的地方,但效果很好。
我也会在早期创建带有样本的测试框架。我发现,如果你有一个用于测试子系统的模板,那么人们就会使用它。在早期没有任何测试框架的情况下,您必然会得到所有极端的开发人员测试。
答案 1 :(得分:1)
当您说组件时,您的意思是代码组件还是基础架构组件?我认为基础设施(支持服务和流程)而不是代码可以最大限度地提高质量,速度和开发的便利性。您提供的示例现在位于大多数语言的标准库中,或者是特定于应用程序/用例的。
我也只是假设版本控制是给定的,因为它对所有开发都是不可或缺的。
我认为大多数重要基础设施将是持续构建/自动化测试。这可以让人们编写他们想要的任何代码,检查它,并确保它可以与其他人一起使用。
第二个最重要的是公共库。这些让人们更快地发展并建立外观,感觉和设计的标准(希望是好的)。随着常用库的使用越来越多,连续构建的重要性也会增加,因为这些库中的微小变化会导致回归。
但是,普通图书馆的一个问题是,它们需要花费很多精力才能设计出来 - 所以它们值得重用 - 而且需要很长时间才能达到这一点。大多数将从项目的具体开始,然后有人将其入侵他们的项目,然后进行一些分支,然后复制和粘贴。经过一段时间,很多年后,有人会审核代码并开始将它们合并到一个共同的位置。应该制定一个计划来升级公共库以及如何(或者如果)同时拥有它们的两个版本。另一个隐藏的缺点是它们可以在短期内加快开发速度,但从长远来看会阻碍开发,因为人们会陷入旧版本(对于第三方库来说更是如此)。第三个是构建工具。这意味着简化构建,检出,搜索以及以任何方式与代码交互的常用工具。在提交补丁时自动标记错误的事情,或者通知连续构建器依赖性已发生变化,或者在提交测试之前自动运行测试,使测试变得容易(和快速)运行。
第四个是密封版本,这是构建工具的简单扩展。这意味着应用程序是自包含的。这有两个好处:1)机器重用更容易,更重要的是,2)它非常容易让开发人员入门 - 他们不需要安装额外的库,或者在/ etc中更改某些内容,或者在其中设置一些内容环境 - 它只是构建和运行。
我能想到的其他一些:
答案 2 :(得分:0)
不完全在基础设施领域:
如果没有这些,您可以为同一个客户提供一系列应用程序开发活动。
- 登录
- 排队
- 调度
这些应该都是搁置的,以满足使用它们的应用程序的需求。例如。 J2EE构建的应用程序的日志记录解决方案与.NET的不同。 (在重要的企业中,单一文化本身就是一个问题。)