如何构建大型应用程序

architecture distributed

5667 观看

12回复

3673 作者的声誉

我想我已经非常擅长编程的基础知识(适用于各种语言)。我可以写一个*好的**代码行。我可以写一个方法。我可以写一堂课。我可以写一组很好的课程。我可以写出好的小型或中型应用程序。

但是,我不知道如何构建一个好的大型应用程序。特别是在涉及多种技术并且更多可能与时间有关的情况下。假设一个带有大型Web前端的项目,一个连接到其他集成后端的大型服务器后端,最后是一个庞大而复杂的数据库。哦,我参与了其中的一些应用程序,我可以构建一个我确定的。然而,我不太确定它是否有资格作为“好”。

因此,我的问题是参考书籍或其他良好的阅读来源,在那里我可以学习如何为一般大型项目分发和组织代码和数据。例如,我是想要非常严格地对事物进行分层,还是要将其封装为独立单元。我是否想要尝试将大部分逻辑保留在同一个池中,或者它应该只是分布,因为在添加我添加的任何功能时它似乎最合乎逻辑。

我已经看到很多关于这些问题的一般原则(例如没有意大利面条代码,肉丸代码......),并阅读了一些讨论此事的优秀文章,但我从来没有遇到过能引导我具体实践知识的来源。我意识到问题的难点,所以我很高兴听到其他人发现的帮助他们寻求这些知识的读物。

一如既往,感谢您的回复。

****鉴于“好”代码定义的辩论性质,在这种情况下,术语“好”将不会被定义(它意味着你认为它应该是什么意思)。

作者: srmark 的来源 发布者: 2009 年 1 月 23 日

回应 (12)


17

12168 作者的声誉

借用tvanfosson:

从一个小应用程序开始,每当有人想要添加新功能时说“是”。

作者: carrier 发布者: 23.01.2009 05:41

11

7032 作者的声誉

这是我们用来指导编码标准和方法的书:

替代文字 大规模C ++软件设计

自从它首次在众所周知的卫生巾背面绘制以来,我正在开发的程序已经开发了近10年。而且这个项目今天仍然很强劲。它还不完美,并且仍然存在循环依赖的问题,并且一些类接口不是很干净,但是大多数类都不是这样,程序有效并且我们的用户很高兴。

正如许多其他人之前所做的那样,我还建议由Steve McConnell执行代码完成软件评估。我特别喜欢他用“增长”软件而不是构建或构建软件的比喻。这种查看软件的方式更适合于具有较长生命周期的东西。

作者: Scottie T 发布者: 23.01.2009 05:43

4

16339 作者的声誉

  1. 确定哪些功能最重要; 别忘了
  2. 决定哪些特点是最重要的,而忘记了休息
  3. 实施它们(应该花费几周时间,否则重复步骤1和2)
  4. 发射
  5. 查看哪些功能有效,哪些功能无效,哪些功能缺失
  6. 回到第1步
作者: davetron5000 发布者: 23.01.2009 05:43

3

24225 作者的声誉

使用设计模式使其可扩展,这意味着您不必更改所有内容以楔入新功能。

决定构建和构建它所需的内容。

将其分解为单独执行任务的模块。

计划计划计划,在开始之前了解您正在构建的内容,并构建其他内容。

只写你需要的功能,不要添加你认为可能有用的东西,但是......保持足够的灵活性,以便能够添加你可能需要添加的anthing。

作者: Omar Kooheji 发布者: 23.01.2009 05:48

0

704 作者的声誉

好吧,你可以看看理性的统一过程。检查基本部件,选择一些您认为需要的工件。列出您想要的所有功能,并将它们组织在需求列表中。还要仔细规划您的软件架构,这样您就不必在以后更改它。有了这些技巧,开发大型应用程序会相对容易一些。

作者: Danmaxis 发布者: 23.01.2009 05:49

4

3255 作者的声誉

大型应用程序不会在一个晚上创建。企业应用程序从小块开始,然后将它们组合在一起。如果您设计的应用程序是一种可以扩展的方式,那么它将更容易与所有周围因素集成,如数据库,第三方工具等。如果你进入infoq.com你会发现很多很好的案例关于缩放和体系结构的研究和材料,如Myspace,亚马逊等等。除了体验之外,您将无法开发出色的大型应用程序。

作者: Oscar Cabrero 发布者: 23.01.2009 05:49

3

1663 作者的声誉

使用测试驱动设计逐步增加

作者: Noel Walters 发布者: 23.01.2009 06:10

26

43312 作者的声誉

决定

作为程序员,我们喜欢相信自己是聪明人,所以很难承认某些东西太大而且太复杂,甚至不能同时考虑所有问题。但对于一个大型软件项目来说,这是真的,你越早认识到你有限的大脑容量并开始想出简化问题的方法,你就会越好。

另一个要实现的主要事情是,您将花费大部分时间来更改现有代码。构建初始代码库只是蜜月期 - 你需要设计你的代码时考虑到这个想法,6个月之后你会坐在它前面尝试解决一些问题而不知道这个特定模块是如何工作的,甚至虽然你自己写了。

所以,我们能做些什么?

最小化代码中不相关部分之间的耦合。代码将随着时间的推移以您无法预料的方式发生变化 - 与不熟悉的产品,需求变化相结合会出现显示问题 - 这些问题将导致波动的变化。如果已建立稳定的接口并对其进行编码,则可以在实现中进行所需的任何更改,而不会影响使用该接口的代码。您需要花费时间和精力开发经得起时间考验的接口 - 如果接口也需要改变,那么您将回到正方形。

建立可用于回归测试的自动化测试。是的,预先做了很多工作。但是,如果您能够进行更改,运行测试并确定它仍然可以正常运行,而且没有那种担心如果您对源代码控制进行最新更改,一切都会失败的感觉,它将会得到回报。

摆脱棘手的东西。 我偶尔会看到一些聪明的C ++模板技巧并想一想,“哇!这就是我的代码所需要的!” 但事实是,代码变得易读和容易理解的减少往往不值得增加通用性。如果你像我这样,其自然倾向是试图解决一般的方式尽可能的每一个问题,你需要学会克制它,直到你真正跨越来需要对于通用的解决方案。如果出现这种需要,你可能不得不重写一些代码 - 这没什么大不了的。

作者: j_random_hacker 发布者: 23.01.2009 07:47

5

7512 作者的声誉

正如我在其他地方提到的,大型应用程序不仅更大,它们也不同。这么多,我们谈论的是小型大型的编程。当您进行大规模编程时,问题的性质及其解决方案会发生重大的质的转变。这条线非常模糊,有许多具体问题可能会迫使你越过那条线。

其中一些问题包括:

  • 大小(例如一个根本不适合单个硬盘的数据库)
  • 复杂性(从一体化应用程序到多个子系统)
  • 并发性(从0到数千/数百万的并发用户)
  • 可用性(从9%的正常运行时间到99.999%的正常运行时间)
  • 可靠性(从每日故障到MTBF几年)
  • 速度(响应时间从小时到毫秒)
  • 产品化(从您的宠物项目到可销售的商品)
  • 等等

怎么处理这一切?学习并使用所有有价值的技术,并学习评估哪些是有价值的 - 这需要一段时间,而且没有快速的答案。

然而,有一种技术容易,明显,并且适合所有人:分而治之。隔离每个主要功能,每个子系统,每个外部依赖,以便您的主系统仅在其外边缘接触它们。当你可以通过在很短的时间内调整一个瘦接口来改变每一个,那么你已经完成了一些事情。这将带你走很长的路。

最好的祝愿。

作者: Rob Williams 发布者: 23.01.2009 07:50

3

53496 作者的声誉

值得注意的是,有多少评论说盲目迭代是唯一的方法。

迭代是至关重要的(我是一个巨大的粉丝),但有些人可以计划大型项目 - 这只是我们中很少有人见过的。

想想看,我们所有人都在车道上打篮球。我们非常好,我们可以获得大多数篮子,并且在公园里实际上有一个非常有趣的游戏。

然而,仅仅因为我们从未遇到职业球员,并不意味着他们不存在,并且不能整天在球场上下踢我们的每一个屁股。

唯一的问题是没有专业的编程游戏 - 也许如果有我们会看到它们更多。

作者: Bill K 发布者: 23.01.2009 08:42

0

10755 作者的声誉

我会说,作为负责大型应用程序的人

  • 使用Spring等非侵入式框架
  • 减少耦合
  • 尽可能创建不可变对象 - 它们是线程友好的
  • 接受您的应用程序可能需要拆分为单独的流程以更好地扩展并为此进行规划。
  • 构建可靠的工具集并学习工具。

不要恐慌

作者: Fortyrunner 发布者: 23.01.2009 11:44

-2

284 作者的声誉

关于产品和供应商锁定的一些想法:

  • 尝试尽可能独立于供应商和平台。这将阻止您使用新产品/平台/框架等从头开始重新实现所有内容。
  • 这实际上意味着使用Java SE + Java EE +和开源RDBMS,如Java EE封装的JPA封装的PostgreSQL。不要使用额外的库,框架(spring,hibernate,...)等。这样你就可以随时切换产品和供应商。
  • 我认为您只能通过Java获得这种级别的产品和平台独立性。即使您使用OSS库和框架,如果您发现实现不符合您的需求并且您必须重做所有内容,您将后悔使用它们。
  • 您可以使用Java Application Verification Kit检查代码的产品独立性。
  • 事先花一些时间在架构上,但也要在整个实现过程中重新设计架构。一本好书(不幸的是只有德语)是Adam Bien的“Java EE 5 Architekturen”。

@j_random_hacker:实际上,没有 - 我仍然认为我的第一点是在大型应用程序中使用java而不是反对它的论据。每种语言都是一种语言。当然,你总是要对语言做出承诺。

  • 但Java SE&EE包括语言,编译器,虚拟机以及所有必需的库/框架。但是整个Java SE / EE平台有不同的实现:来自Sun,Apache,IBM,HP,Oracle,BEA的Java SE(JDK)。来自Sun,Apache,Red Hat,IBM,Oracle等的Java EE(Application Server)。.Net与C#只有一个实现(来自Microsoft和一个名为Mono的类似语言/平台的实现)。
  • 我认为PHP也只有一个实现。有很多不同的C ++编译器。但它们都实现了略有不同的C ++语言,并且它们不与所有共享相同API的库捆绑在一起。选择Java,我知道我可以选择六个Java SE实现和六个Java EE应用服务器来运行该软件,该软件又可以在Linux,Solaris,FreeBSD,HP-UX,IBM z / OS,Windows上运行,Mac OS X以及各种各样的硬件平台。所以我不必担心,如果我在开发后期甚至在生产中发现一个非常糟糕的实现问题 - 我会离开Sun而永远不会回头。(这就是我推荐Java应用程序验证工具包的原因。通过查看源代码,您可以确定,Sun,IBM,甲骨文或任何其他邪恶的公司都没有将他们的任何专有资料作为依赖关系潜入您的资源,这可能会将您绑定到该公司。你像鸟一样自由。)
  • 你不能用PHP或Ruby做到这一点。使用这些语言,如果没有其他人这样做,您将不得不自己修补实现问题,因为花费数月的错误修补时间到PHP或Ruby仍然比重写整个应用程序要少。
  • Sun开源了:Java SE(完整的JDK)和Java EE(Glassfish应用服务器)。唯一不是“开源”的是有一种绑定语言规范,它由sun领导,并得到其他人的大量贡献。这就是为什么你可以从sun获取Java实现,修改Java语言并重新分发源和二进制文件,但如果不符合语言规范,则不能再调用“Java”(Sun仅保护Java商标)实际应用于事物java)。这听起来可能听起来很“邪恶”,但实际上确保存在“Java”这样的东西:你可以编写一个java应用程序并在任何java实现上运行它。
  • 如果您无法忍受任何Sun微系统,但想要一个开源Java,那么您可以将Apache Harmony(Java SE)与Apache Geronimo(Java EE)一起使用。
作者: SAL9000 发布者: 26.01.2009 11:41
32x32