CodeGym University
学习
课程
任务
调查和小测验
游戏
帮助
提醒时间表
社区
用户
论坛
聊天
文章
成功故事
活动
评论
订阅服务
浅色主题
课程
评论
关于我们
开始
开始学习
立即开始学习
目标地图
课程
全部目标
全部级别
良好软件架构的标准
模块 3
第 14 级,
课程 3
效率 有经验的程序员可以很容易地分辨出架构的好坏,但如果被要求用几句话来描述它,他们不太可能做到。好的架构没有单一的标准,也没有单一的定义。 然而,如果你仔细想想,你可以写出一些好的架构应该满足的标准。一个好的架构首先是一个逻辑架构,它可以让程序的开发和维护过程更简单、更高效。 当程序具有良好的体系结构时,总是很容易理解它是如何工作的以及在何处编写代码。一个结构良好的程序更容易更改、测试、调试和开发。聪明人制定了以下优秀架构的标准: 效率; 灵活性; 可扩展性; 可扩展性;
不良软件架构的标准
模块 3
第 14 级,
课程 4
不良设计的标准 生活很简单:通常,要聪明,你只需要不做傻事。这也适用于软件开发:在大多数情况下,要想把一件事做好,你只需要不把它做得不好。 大多数程序员都有过设计糟糕的系统部分的经验。但更可悲的是,你们中的大多数人都会有悲伤的经历,意识到自己是这样一个系统的作者。我们想要最好的,但结果一如既往。 大多数开发人员并不渴望糟糕的架构,对于许多系统来说,他们开始说它的架构很糟糕。为什么会这样?架构设计是从一开始就不好,还是随着时间的推移变得不好? 这个问题的根源是缺乏“坏”设计的定
模块化软件架构
模块 3
第 14 级,
课程 5
6.1 分解 尽管标准多种多样,但大型系统开发的主要任务是降低系统的复杂性。为了降低复杂性,除了分成几部分之外什么也没有发明。 有时,为了简单起见,这被称为“分而治之”原则,但是,从软件架构师的角度来看,我们谈论的是层次分解。 一个复杂的系统必须由少量较简单的子系统构建而成,每个子系统又由较小的部分构建,依此类推,直到最小的部分足够简单,可以直接理解和创建。 好消息是这个解决方案不仅是唯一已知的,而且是通用的。除了降低复杂性之外,它还通过复制关键部分同时提供系统灵活性、良好的
正确的软件分解
模块 3
第 14 级,
课程 6
层次分解 您永远不应该立即开始为您的应用程序编写类。首先需要对其进行设计。设计应该以深思熟虑的架构结束。要获得此架构,您需要始终如一地分解系统。 分解必须分层进行——首先,系统被分成大的功能模块/子系统,以最一般的形式描述其操作。然后对生成的模块进行更详细的分析,并将其划分为子模块或对象。 在选择对象之前,将系统分成基本的语义块,至少在心理上是这样。在小型应用程序中,这通常很容易做到:几个级别的层次结构就足够了,因为系统首先分为子系统/包,而包又分为类。 这个想法并不像看起来
如何松散软件模块之间的耦合
模块 3
第 14 级,
课程 7
8.1 分解就是一切 为了清楚起见,一张来自一篇好文章“面向对象系统的解耦”的图片说明了将要讨论的要点。 您还认为设计应用程序架构很容易吗? 8.2 接口,实现隐藏 降低系统耦合度的主要原则是OOP的原则以及其背后的封装+抽象+多态的原则。 因此: 模块应该是彼此的“黑盒子”(封装)。这意味着一个模块不应该“爬升”到另一个模块并且不知道它的内部结构。一个子系统中的对象不应该直接访问另一个子系统中的对象。 模块/子系统应该仅通过接口(即不依赖于实现细节的抽象)相互交互。因此,每
依赖倒置
模块 3
第 14 级,
课程 8
9.1 依赖倒置 请记住,我们曾经说过,在服务器应用程序中,您不能只通过创建流new Thread().start()?只有容器应该创建线程。我们现在将进一步发展这个想法。 所有对象也应该只由容器创建。当然,我们不是在谈论所有对象,而是在谈论所谓的业务对象。它们通常也被称为垃圾箱。这种方法的支柱源于 SOLID 的第五条原则,该原则要求摆脱类并转向接口: 顶级模块不应该依赖于低级模块。那些和其他人都应该依赖于抽象。 抽象不应依赖于细节。实现必须依赖于抽象。 模块不应该包含对特
链接软件模块的替代方法
模块 3
第 14 级,
课程 9
用消息传递代替直接依赖 有时一个模块只需要通知其他人它发生了一些事件/变化,而这些信息以后发生什么并不重要。 在这种情况下,模块之间根本不需要“相互了解”,即包含直接链接并直接交互,但只需交换消息(messages)或事件(events)就足够了。 有时似乎通过消息传递的模块通信比直接依赖要弱得多。事实上,因为没有调用方法,所以没有关于类的信息。但这只不过是一种错觉。 逻辑开始与消息类型、它们的参数和传输的数据相关联,而不是方法名称。这些模块的连接性被抹黑了。 它曾经是这样的
软件生命周期
模块 3
第 15 级,
课程 0
软件产品生命周期的阶段 高质量软件的开发需要许多因素:合格的团队、工作流规划、产品符合客户期望、按时完成。 1.需求分析 这个阶段可以被认为是最重要的阶段之一。项目的成功取决于它。这一切都始于项目目标的形成。然后列出要完成的任务和未来软件的范围。之后,明确了项目的条件、期限和预算。在第一阶段的最后阶段,开发团队的技术任务得到批准。 2.设计阶段 设计从定义应用程序架构、功能、功能要求和接口开始。然后在程序和用户之间分配功能,考虑各种组件的要求。产品设计必须考虑客户的期望及其实
瀑布 - 瀑布模型
模块 3
第 15 级,
课程 1
级联模型设备 瀑布模型,也称为 Waterfall,是最著名的软件开发方法之一。该模型的作者是温斯顿罗伊斯。1970 年,他在一篇详细介绍其优缺点的文章中描述了他的创新的本质。在同一个地方,他解释了如何将这个模型细化为迭代模型。最初,在瀑布模型中,开发阶段按以下顺序进行: 需求的定义和协调; 立项; 编码; 创建软件产品的工作版本; 测试和调试; 软件安装; 支持。 根据瀑布模型,开发人员执行的操作是按顺序发生的——逐点进行。首先,正在完成工作以确定并同意以待完成列表的形式的
敏捷开发方法论——敏捷
模块 3
第 15 级,
课程 2
敏捷模型 灵活(敏捷)方法通过将工作流移动到几个小周期中来帮助降低软件开发的风险。这些周期称为迭代,通常持续两到三周。 迭代就像一个由任务组成的小型软件项目,每个任务都会改进功能。其中包括:制定计划、评估需求、就项目达成一致、编写代码、测试和创建技术文档。 对于一个完整的软件版本来说,一次迭代通常是不够的。然而,敏捷的好处是项目的一小部分在每次迭代结束时都准备好进行评估。这允许团队成员更改优先级以进行进一步的工作,而无需等待最终版本。 应用“敏捷”开发方法,您可以在每次迭代后
Scrum 简介
模块 3
第 15 级,
课程 3
Scrum 的历史 自 1970 年温斯顿·罗伊斯 (Winston Royce) 的“管理大型软件系统的开发”报告发表以来,许多人都在尝试寻找一种可以消除瀑布式开发模型缺点的方法。“瀑布”的替代方法是 Scrum 方法,现在将对其进行讨论。 Scrum 于 1986 年得名于 Takeuchi 和 Nonaki 的著作《新产品开发的新规则》。本文档认为,实现目标的最有效方法是为开发人员提供明确的行动计划。 1995 年,Sutherland 和 Schweiber 出版了另
使用 Scrum
模块 3
第 15 级,
课程 4
用户故事 用户故事是陈述开发中软件需求的有效方式。这些故事包含代表软件用户的简短建议。 由于在 Scrum 方法中,设定目标通常是客户或软件所有者的特权,因此它们被认为是影响开发过程的主要方式。每个用户故事在文本量和呈现的复杂性方面都有限制。历史通常写在一张小纸上,这本身就限制了体积。 借助用户故事,您可以记录客户的愿望并快速响应市场需求。 用户故事应该被视为一种简单的需求度量,因为它不包括验收测试程序。用户故事的编写必须符合准入程序。这将确保用户故事实现其目标。 故事结构如
显示更多
1
...
30
31
32
33
34
35
Please enable JavaScript to continue using this application.