65.9K
CodeProject 正在变化。 阅读更多。
Home

软件开发中的方法、风格或理念

starIconstarIconstarIconstarIcon
emptyStarIcon
starIcon

4.60/5 (12投票s)

2009年3月9日

CPOL

10分钟阅读

viewsIcon

73287

什么是KISS?只是提醒一下。

目录

引言

前几天我母亲问我是否知道KISS是什么。提起“保持简单,愚蠢”原则,让我想起了一年前我在工作中做一个的演示。我所在的公司在努力交付高质量产品的同时,又要应对不断增加的用户需求(和定制)。管理团队不知如何激励开发和质量保证团队,也不知道如何衡量成果。这个问题很复杂,涉及多方面,是文化层面的,在软件开发界并不罕见。虽然软件定律的统一理论仍然难以捉摸,但软件行业可以采用许多不同的方法、风格和理念来达成目标。

在这里,我概述了一些在中小软件公司中流行的当前趋势。

本文是他人作品的汇编。任何错误或遗漏的归属都不是故意的。如果您知道有遗漏,请告知我,我会进行更正。更多详情,请参阅资源

背景

项目管理 项目管理是对资源(例如人员)进行组织和管理,以在定义的范围质量时间成本限制内完成项目的学科。
项目 项目是为创建独特的产品或服务而进行的临时一次性的活动,它会带来有益的改变或附加价值。
操作 运营或流程是永久性或半永久性的持续功能性工作,用于一遍又一遍地创建相同的产品或服务。
  • 这两个系统的管理方式通常大相径庭,需要不同的技术技能和理念,因此需要项目管理的发展。
  • 在任何领域,成功的项目经理都必须能够从头到尾设想整个项目,并有能力确保这一愿景得以实现。
  • 项目目标可以表述为S.M.A.R.T.
    • 具体的 (Specific)
    • 可衡量的 (Measurable)
    • 可实现的 (Achievable)
    • 现实的 (Realistic)
    • 有时间限制的 (Time-bounded)
  • 如今,各种管理都以项目形式表达。事实证明,使用复杂的模型来处理为期仅几周的项目(或者更确切地说,是任务)会在许多情况下导致不必要的成本和低下的机动性。相反,项目管理专家试图识别不同的轻量级模型,例如软件开发的极限编程和Scrum技术。

轻量级软件开发

软件开发 软件开发是将用户需求或市场目标转化为软件产品的过程。
软件过程 软件开发过程是应用于软件产品开发的一种结构。该过程的骨架包括领域分析、需求分析、规范、软件架构、编码、测试、文档、软件培训和支持以及维护。该过程可以是顺序的或迭代的。

优点

敏捷软件开发过程建立在迭代开发的基础上。在此基础上,它们增加了比传统方法更轻量、更以人为中心的视角。

挑战

尽管迭代开发方法有其优点,但软件架构师仍然面临着创建可靠的基础来开发的问题。这样的基础通常需要大量的初步分析和原型设计来构建开发模型。开发模型通常依赖于特定的设计模式和实体关系图(ERD)。没有这个初步的基础,迭代开发可能会在成本和质量方面带来长期的重大挑战。

    组织在采纳敏捷开发方面最大的担忧是什么/曾是什么?
    敏捷调查:广泛采用,强调生产力和质量
    [^]

  • “我知道你认为你理解了我所说的,但我不能确定你是否意识到你听到的不是我的意思。”(出自 Roger S. Pressman 的《软件工程》(实践者方法),第 5 版,2000 年,Mc Graw-Hill Education,ISBN 978-0071181822;然而,这句话归因于许多来源,包括理查德·尼克松、罗伯特·麦克洛斯基和艾伦·格林斯潘。它可能起源于几十年前一个匿名的学术笑话。)
  • Steve McConnell 在《代码大全》中将设计称为“棘手的问题”——一个在其完成之前无法完全了解其需求和限制的问题。
  • 如果迭代不够小以规避风险,这种方法也可能非常昂贵;类似于……“如果你不知道你想要什么样的房子,让我为你建一栋,看看你喜不喜欢。如果你不喜欢,我们就把它全部拆掉,重新开始。”
  • 微软开发人员一致认为最大的三个问题是(微软软件开发观察:关于人们……协同工作 [^]
    • 理解一段代码背后的逻辑(66%)
    • 由于来自团队成员或经理的请求而不得不频繁切换任务(62%)
    • 意识到其他地方的代码变更会影响自己的代码(61%)。
  • 在哪些环境中,敏捷会最成功? (作者:Steve McConnell)[^]
    • 对我而言,全方位的敏捷似乎[^]最适合那些预算按年固定、团队规模按年固定(由于预算原因),并且项目团队的任务是在固定团队规模下,在一年内交付最有价值的业务功能的环境。这主要描述了内部的业务系统开发组织。
    • 全方位的敏捷(尤其是灵活的需求部分)不太适合销售软件的公司,因为维护大量的需求灵活性与提供中期和长期可预测性的目标相悖。我们发现,许多组织比需求灵活性更看重可预测性。也就是说,他们比“响应变化”的能力更看重向关键客户或市场做出承诺的能力。
    • 然而,对于不那么全面的敏捷,我们发现许多敏捷实践非常适合绝大多数环境。无论你预先定义 5% 的需求还是 95% 的需求,短开发迭代几乎总是很有价值的。始终将软件保持在接近可发布质量的水平几乎总是很有价值的。Scrum 作为一种管理风格和纪律似乎具有广泛的适用性。小型、赋能的团队几乎总是很有用。我在关于敏捷开发遗产的执行演示文稿中更详细地介绍了特定敏捷开发实践的详细优缺点。

示例

  • Crystal Clear [^] Crystal Clear 可应用于最多 6 到 8 名本地开发人员组成的团队,这些团队正在开发非生命关键的系统。Crystal 系列方法侧重于效率和可居住性作为项目安全性的组成部分。
    • 频繁向用户交付可用代码(必需)
    • 反思性改进(必需)
    • 沟通效率,最好是协同工作(必需)
    • 个人安全
    • 焦点
    • 轻松访问专家用户
    • 自动化测试、配置管理和频繁集成

方法、风格或理念

形式化方法 形式化方法是基于数学的技术,用于软件和硬件系统的规范、开发和验证。由于使用形式化方法的成本很高,因此它们通常仅用于高完整性系统的开发,在这些系统中安全性或保密性很重要。
编程范式 编程范式是关于如何用编程语言来表述问题解决方案的一种基本编程风格。例如——面向方面[^]、基于规则[^]、函数分解[^]、过程式[^]、面向对象[^]。
方法论 方法论是解决特定软件工程问题的一种风格;一套标准化的实践(有时附带培训材料、正式的教育项目、工作表和图表工具),可以重复执行以产生软件。
反模式 反模式是特定的重复性实践,它们最初看起来有益,但最终会带来超出预期优势的不利后果。
  • 自顶向下和自底向上[^]。自顶向下和自底向上是信息处理和知识排序的策略,主要涉及软件,但也涉及其他人文和科学理论(参见系统学)。在实践中,它们可以被视为一种思考和教学风格。在许多情况下,自顶向下用作分析或分解的同义词,自底向上用作综合的同义词。
  • 契约式设计 (DBC)[^] DBC 的核心思想是一种关于软件系统元素如何基于相互义务和利益进行协作的比喻。
    • 它期望什么?
    • 它保证什么?
    • 它维护什么?
  • 测试驱动开发 (TDD)[^] 测试驱动开发是一种软件开发技术,由简短的迭代组成,其中首先编写涵盖所需改进或新功能的测试用例,然后实现通过测试所需的生产代码,最后重构软件以适应更改。
    • 需要测试自动化
    • “保持简单,愚蠢”(KISS [^])原则
    • “你不会需要它”(YAGNI [^])原则
    • “装作如此,直到你真的能做到”(Fake it, till you make it)原则
    • 需要诸如讨论和代码审查等技术,以确保不仅实现了正确的功能,而且生成的代码使用了可接受的风格
  • 模型驱动开发 (MDD)[^] 模型驱动开发是指一系列基于使用软件建模作为主要表达形式的开发方法。有时模型会构建到一定详细程度,然后在单独的步骤中手动编写代码。有时会构建完整的模型,包括可执行的操作。
  • 功能驱动开发 (FDD)。[^] FDD 是一种模型驱动的短迭代过程,由五个基本活动组成。为了准确的状态报告和跟踪软件开发项目,定义了标记每个功能进展的里程碑。
    • 开发总体模型
    • 构建功能列表
    • 按功能规划
    • 按功能设计
    • 按功能构建
    • 里程碑
  • 用户体验开发 (UX) [^] 用户体验是用于描述用户在使用产品或系统时的整体体验和满意度的术语。
    • 减少超出用户需求的功能
    • 提高系统的整体可用性
    • 通过详细和完善的指南加快设计和开发速度
    • 在满足用户的同时融入业务和营销目标
  • 牛仔式编码[^] 牛仔式编码是一种没有实际定义方法的软件开发方法——团队成员随心所欲。典型的牛仔式编码将不涉及项目目的或范围的初始定义,没有项目的正式描述,并且通常涉及一名程序员。
    • 家喻户晓,普遍适用。开发人员无需培训即可快速上手并提高效率。
    • 促进项目快速完成。
    • 允许快速解决小问题。通常一个问题足够小且足够好理解,以至于文档和规划是多余的。通常适用于需要一两天完成且仅涉及一名开发者的工作。
    • 可以允许进行一次探索性开发(spike),以查看某个编程想法是否有效,然后再进行依赖于该想法的更大项目。Spike 是指编写一个小型概念验证应用程序来证明某种方法是有效的。这些应用程序通常不构成实际完成的应用程序的一部分。
  • 混沌模型
  • 原型制作
  • ... 

结论

本文未完成。它只是肤浅的。但我希望它能让你一窥软件开发行业中流传的一些想法、术语和挑战。它旨在激发你去探索可能尚未引起你注意的领域。

将来,我希望能够编目所有软件开发的方法、风格和理念;并为其中每一个提供足够的示例或案例研究——以结构化、用户友好、集中的格式。:)

资源

修订历史

  • 2009-03-12 添加了结论
  • 2009-03-08 发布于 CodeProject
  • 2007-11-01 初始演示
软件开发中的方法、风格或理念 - CodeProject - 代码之家
© . All rights reserved.