- 浏览: 308564 次
- 性别:
- 来自: 北京
文章分类
最新评论
-
开发小菜:
支持IE9以下的吗?
HTML5+CSS3+JQuery打造自定义视频播放器 -
攻城使:
开发Html5必须得下载么,我用dw编写,把文件复制到myec ...
html5开发 myeclipse安装aptana插件 -
疾风鹰狼:
...
根据判断浏览器类型屏幕分辨率自动调用不同CSS的代码 -
sardodo:
你好,我想问下,导入例子中的.dae格式模型是可以看到旋转的小 ...
c3dl 初步认识 -
BIOHAZARDX:
下载学习,初学者膜拜一下。
html5 实现动画(三)
我收集各式各样的至理名言。最近我一直在研究敏捷软件开发;有收获吗?下面就是能够指导敏捷软件开发团队的26条核心原则。
用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。 一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定); 让这个用例功能完整; 让相应的测试用例都能通过; 相应的文稳都补齐; 只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。
避免提交一个半成品。 这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。 如果系统编译失败,那一定是有人抄近道到了。
不要在还没有任何使用案例的情况下设计通用模块。 只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。
一定不要在没有使用例的情况下往类里添加成员方法。 这跟上面一条极其相似,除了这里针对的是数据成员。 开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。
不要害怕做决定;不要害怕改变以前的决定。 敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。 你不能说一直等到有了足够的信息才做决定。 相反,你要依赖现有的信息作出最正确们决定。 之后,当有新的信息出现后,不要害怕对以前的决定作出更改。 (老辈人有的称之为触发器,但我称之为随环境而变)
不断的了解如何改进系统。 这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。
审查,审查,审查。 敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。 测试工作永远不能停下来。 程序每次运行的表现都要被评审和记录。
软件的设计要以人为本,而不是系统。 很多开发人员退而求其次、以技术为中心,让设计为技术服务。 永远不要忘记软件的终极目标是什么,是帮助人们完成工作。
测试是产品的一部分。 许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。 其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。 (后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)
先写测试用例,后写代码。 测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。 想想吧,先写测试用例后编码能节省多少时间。 但是:写完测试用例1,然后编写用例1,完后才开始用例2。
清理垃圾代码。 很显然,又是一个尽人皆知的道理,但它也必须写入任何的开发原则里,因为它是如此的重要。 查找垃圾代码的工作永远没有尽头,找到它,消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处,那它很可能就是没用的。
培养对集成失败问题立即做出反应的习惯。 你要明白,当集成构建失败时,它会影响项目中的每一个人,所以没有比让核心程序能正确的集成和测试通过更重要的事情了。 我曾经见到过有的团队的集成构建中断几个月都不去管它,因为他们有其他的工作要做。 每个人都在忍受这种情况,但没人采取措施。 我们应该明白,应该广泛的认识到,只要做出一点点工作,整个的团队会因此得到非常大的回报。
团队的每个成员都要知道客户的需求。 大型复杂的项目必须要分割到几个独立的团队去开发,然后派发到每个开发人员的手中,但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。
把意义相关的东西放在一起。 组织好代码,让高度相关的东西都放在一起,也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。 理想情况下,类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里,这样是为了按另一种方式组织它们:例如把相同的数据类型的放到一起,或按字母顺序分类。 举个例子,有人会把所有的常量放在单独一个包下的一个类里,他们这样做毫无必要,增加了程序的复杂性。 按照指导原则,它们应该按照相关性进行分组,从而减少复杂性。
先测试后提交代码。 这个准则能让你确保“永远不要让集成构建失败”的准则。
过早优化是灾难之源 这句话是引用Don Knuth的,今天听起来一点不错。 在内核里的代码应该尽力的写好来避免不要的浪费,但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。 相反,评审整个系统的运行表现,找出真正影响性能的1%的代码,只针对这些代码做优化。
最小化未完成的编码任务的工作包(backlog)。 当开发人员开发一个设计用例时,有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。 把未修改完成的代码保存到本地数天或数星期,这样增加了工作浪费的风险,会出现返工。 想象有三个任务,每个估计都要一天。 如果三个一起开发,并行起来每个都需要3天,这样一累计会有9个’单位’的风险。 如果顺序的开发,一个开发完成后再开发另一个,只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们,当我们在这种情况下时,我们希望三个一起完成。 但是软件不像盖房子。 小的、迅速的、完整的任务不仅仅会降低我们的认知负荷,也减少了进行中的开发对其他人正在进行的开发的相互影响。
不要过度功能范化。 也就是我们所说的 “YAGNI – You Aren’t Going to Need It” 。 程序员在编写一个类时喜欢料想:这个类可能在其它地方其它类中会有其它用途用. 如果这些用途是被当前的用例用到,那这样思考是没错的,但常常开发人员想到的这些用途都是目前不存在的用途,实际上可能是永远不会用到的用途。 (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
如果两行代码能完成就不要写成三行。 简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。 精简的、书写规范的代码易于维护和查找错误,冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。
永远不要按行数多少来评价代码头。 编写某个任务所产生的代码行数会因程序员而异,因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。 代码质量可以相差200倍之多,这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。
我们应不断的再设计、再分析。 应用这一条时你要非常的小心,因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的,但现在有个用例需要它是浮点型,不要害怕去改变它,只要你按步骤:测试,写文档,布署。
删除死代码。 当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说,我们需要往类里添加一个新方法来替换以前的旧方法,通用人们会保留老方法‘以防不测’。 其实,我们应该花一些功夫去检查看看这个老方法是否还有用,如果没有证据显示它还有用,就该删掉它。 更糟糕的错误做法是把这些代码注释掉,留下一堆注释码。 注释掉的代码一旦发现就该被删掉,不能留到测试时还有、甚至提交到代码库。 添加代码总是容易的,删除代码总是困难的。 因此,一旦发现有可能没用的代码,你应该花点时去确认它、删除它,这样会让代码更加可维护。
不要自创新语言。 程序员喜欢使用文本文件来实现功能性的趋动,这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现,人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。 这种设计上的缺陷是:软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。 所以,真正的最终用户是不可能知道软件的内部工作机理的,不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途,也不应该被抵制,但设计人员必须以非常非常安全的方式使用它们,尽可能使用现有的语言,必免使用新发明的语言。
只有当准备好了实现和测试才去确定设计。 我应该有一个总体的认识我们要做什么,应该有个总体架构目标,而不是详细设计、详细的具体方法的实现,只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。 详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了,或者是你的设计一开始就建立在错误的假设上。
软件是可塑的。 软件不像盖房子,我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。 而且,软件产品和设计之间的互动明显比规格说明书有效率。 所以,你应该直接实现你的设计,这样客户就能很容易明白你的设计细节。 当发现有问题、要改变设计时,修改软件要比修改文档容易的多。 更重要的是,当客户看到了能运行的程序后,你也就更能搞清客户的需求是什么了。
对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 程序员一般都非常的懒,抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误,他会记得这种一直使用的错误描述信息是什么意思。 但站在客服技术支持的处境,他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。
上面这些条目没有特别的顺序。 欢迎对这些我汇总的指导原则进行评论,也许你并不认可其中的几条,也请发表你们意见。
英文原文:26 Hints for Agile Software Development
用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题:“做好一盘菜后你再做下一盘”. 对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的,我们设计的功能中总会有一部分会被放弃砍掉,如果提前开发,很可能做无用功。 一次只开发一个用例(或很少几个用例,这根据你的开发团队的大小而定); 让这个用例功能完整; 让相应的测试用例都能通过; 相应的文稳都补齐; 只有在当前的用例完全开发完成后,才做为一个整体提交到版本库,才进行下一个用例。
避免提交一个半成品。 这一点大家似乎都知道,但这条原则必须列入任何一个开发指导里。 能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。 如果系统编译失败,那一定是有人抄近道到了。
不要在还没有任何使用案例的情况下设计通用模块。 只有在你知道有具体用例的情况下,你才可以实现一个具体的类,而且你在该类中只应该实现当前该用例需要的方法。 你也许会想到将来这个类会有其它的用途,你可以用注释的方式记录一下,但不要去实现它,只有在有了具体用例后你才可以实现它。
一定不要在没有使用例的情况下往类里添加成员方法。 这跟上面一条极其相似,除了这里针对的是数据成员。 开发人员很容易想到:一个‘客户记录’里应该有‘送货地址’的信息,但一定不要在没有任何用例要求这个属性的时候实现这个属性。
不要害怕做决定;不要害怕改变以前的决定。 敏捷开发的目的是应对客户需求的不确定。 开发前期你不可能获到全部的信息。 你应该尽可能的拖延做决定的时间,但一旦到了你该做决定的时候,你应该当机立断,让项目向前推进。 你不能说一直等到有了足够的信息才做决定。 相反,你要依赖现有的信息作出最正确们决定。 之后,当有新的信息出现后,不要害怕对以前的决定作出更改。 (老辈人有的称之为触发器,但我称之为随环境而变)
不断的了解如何改进系统。 这项工作没有尽头,你应该做好思想准备,持续不断的寻找可以改进的地方,收集各种关于如何找到质量问题、解决质量问题的案例。
审查,审查,审查。 敏捷开发可以帮助我们应对需求在将来的不确定,但过去的事情也存在不确定性。 测试工作永远不能停下来。 程序每次运行的表现都要被评审和记录。
软件的设计要以人为本,而不是系统。 很多开发人员退而求其次、以技术为中心,让设计为技术服务。 永远不要忘记软件的终极目标是什么,是帮助人们完成工作。
测试是产品的一部分。 许多开发人员和经理都认为产品就是你打包给客户的东西,其余的都不重要。 其实测试也应该看作是产品的实际一部分,应该在设计时给予相当的重视,甚至,在很多时候,测试功能也应该同产品一起提交给客户。 (后面说的这部分很多人都不认可,一个内置的能自我测试软件包并不会占用多少额外的资源,但当你需要用到它时,你会发现它的巨大价值。)
先写测试用例,后写代码。 测试用例可以用来精确的说明我们的设计需求。 很多时候我们都是通过运行测试用例后发现我们的设计中存在问题。 想想吧,先写测试用例后编码能节省多少时间。 但是:写完测试用例1,然后编写用例1,完后才开始用例2。
清理垃圾代码。 很显然,又是一个尽人皆知的道理,但它也必须写入任何的开发原则里,因为它是如此的重要。 查找垃圾代码的工作永远没有尽头,找到它,消灭它。 要去除掉所有的不能给实际用户带来价值的代码。 如果你不能指出某段代码对用户有什么用处,那它很可能就是没用的。
培养对集成失败问题立即做出反应的习惯。 你要明白,当集成构建失败时,它会影响项目中的每一个人,所以没有比让核心程序能正确的集成和测试通过更重要的事情了。 我曾经见到过有的团队的集成构建中断几个月都不去管它,因为他们有其他的工作要做。 每个人都在忍受这种情况,但没人采取措施。 我们应该明白,应该广泛的认识到,只要做出一点点工作,整个的团队会因此得到非常大的回报。
团队的每个成员都要知道客户的需求。 大型复杂的项目必须要分割到几个独立的团队去开发,然后派发到每个开发人员的手中,但这绝对不能变成程序员可以不明白最终产品的使用用户的需求和目标是什么。
把意义相关的东西放在一起。 组织好代码,让高度相关的东西都放在一起,也就是放在一个类里。 这是标准的面向对象设计原则里的封装的概念。 理想情况下,类之外的程序并不需要知道类里面的工作细节。 有些开发人员喜欢把代码放到好几个文件里,这样是为了按另一种方式组织它们:例如把相同的数据类型的放到一起,或按字母顺序分类。 举个例子,有人会把所有的常量放在单独一个包下的一个类里,他们这样做毫无必要,增加了程序的复杂性。 按照指导原则,它们应该按照相关性进行分组,从而减少复杂性。
先测试后提交代码。 这个准则能让你确保“永远不要让集成构建失败”的准则。
过早优化是灾难之源 这句话是引用Don Knuth的,今天听起来一点不错。 在内核里的代码应该尽力的写好来避免不要的浪费,但针对高于单个方法的级别的优化应该在整个项目测试通过、针对最终实际用户的压力测试用例通过之后才能进行。 仅仅根据静态的代码来判断哪些是影响整个性能最主要的问题的论断往往是错误的。 相反,评审整个系统的运行表现,找出真正影响性能的1%的代码,只针对这些代码做优化。
最小化未完成的编码任务的工作包(backlog)。 当开发人员开发一个设计用例时,有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。 把未修改完成的代码保存到本地数天或数星期,这样增加了工作浪费的风险,会出现返工。 想象有三个任务,每个估计都要一天。 如果三个一起开发,并行起来每个都需要3天,这样一累计会有9个’单位’的风险。 如果顺序的开发,一个开发完成后再开发另一个,只会有3个‘单位’的风险。 这个并不符合我们的直觉。 我们的直觉告诉我们,当我们在这种情况下时,我们希望三个一起完成。 但是软件不像盖房子。 小的、迅速的、完整的任务不仅仅会降低我们的认知负荷,也减少了进行中的开发对其他人正在进行的开发的相互影响。
不要过度功能范化。 也就是我们所说的 “YAGNI – You Aren’t Going to Need It” 。 程序员在编写一个类时喜欢料想:这个类可能在其它地方其它类中会有其它用途用. 如果这些用途是被当前的用例用到,那这样思考是没错的,但常常开发人员想到的这些用途都是目前不存在的用途,实际上可能是永远不会用到的用途。 (This subject always reminds me of the classic Saturday Night Live skit about the product which was both a floor wax, and a dessert topping.)
如果两行代码能完成就不要写成三行。 简洁的代码永远都会给需要阅读这段代码的人带来好处。 但千万不要把代码压缩的难以理解了。 精简的、书写规范的代码易于维护和查找错误,冗长的、太多修饰的代码则相反。 尽可能的简化但不要过度。
永远不要按行数多少来评价代码头。 编写某个任务所产生的代码行数会因程序员而异,因编码风格而异。 代码的行数不会提供任何关于程序完成情况和代码质量的信息。 代码质量可以相差200倍之多,这是计算代码行数的方法不能胜任的。 应该计算功能性的用例数。
我们应不断的再设计、再分析。 应用这一条时你要非常的小心,因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。 一个数据成员以前是整数型的,但现在有个用例需要它是浮点型,不要害怕去改变它,只要你按步骤:测试,写文档,布署。
删除死代码。 当发现有一大段不能理解的代码时我们习惯的做法是“让死狗躺在哪”。 比如说,我们需要往类里添加一个新方法来替换以前的旧方法,通用人们会保留老方法‘以防不测’。 其实,我们应该花一些功夫去检查看看这个老方法是否还有用,如果没有证据显示它还有用,就该删掉它。 更糟糕的错误做法是把这些代码注释掉,留下一堆注释码。 注释掉的代码一旦发现就该被删掉,不能留到测试时还有、甚至提交到代码库。 添加代码总是容易的,删除代码总是困难的。 因此,一旦发现有可能没用的代码,你应该花点时去确认它、删除它,这样会让代码更加可维护。
不要自创新语言。 程序员喜欢使用文本文件来实现功能性的趋动,这样可以使程序变的可配置。 通过配置文件来改变软件行为所产生的后果是不过控的。 XML的诞生促使了一系列的特别的自定义的‘脚本语言‘的出现,人们试图通过文件的配置以让最终用户‘编程’来控制软件的功能、避免重新编译。 这种设计上的缺陷是:软件里的各种操作的准确定义在脱离了具体上下文的特定实现的情况下不可能被准确的定义。这些各式各样的脚本型语言只是对那些对软件代码的内部工作机理有着相关的知识背景的人才会价值。 所以,真正的最终用户是不可能知道软件的内部工作机理的,不可能推理出这些复杂的指令组合会产生什么样的预期结果。 脚本有它的用途,也不应该被抵制,但设计人员必须以非常非常安全的方式使用它们,尽可能使用现有的语言,必免使用新发明的语言。
只有当准备好了实现和测试才去确定设计。 我应该有一个总体的认识我们要做什么,应该有个总体架构目标,而不是详细设计、详细的具体方法的实现,只有当开发迭代到一定程度后、足以让我们定下设计细节后才去把它表现成文档。 详细设计只应该包括当前需求用例中需要覆盖的部分。 软件开发中最大的浪费就是你花时间设计出来东西后被告知不需要了,或者是你的设计一开始就建立在错误的假设上。
软件是可塑的。 软件不像盖房子,我们可以轻易的改的面目全非。 无数事实表明软件比它的规格说明书善变的多。 而且,软件产品和设计之间的互动明显比规格说明书有效率。 所以,你应该直接实现你的设计,这样客户就能很容易明白你的设计细节。 当发现有问题、要改变设计时,修改软件要比修改文档容易的多。 更重要的是,当客户看到了能运行的程序后,你也就更能搞清客户的需求是什么了。
对被检测到的和被报告的异常情况请多花一点时间对其进行详细描述。 程序员一般都非常的懒,抛出异常时只描述错误的表面现象。 设想如果只是作者自己会遇到这种错误,他会记得这种一直使用的错误描述信息是什么意思。 但站在客服技术支持的处境,他们因为这种不准确的、不完整的错误描述浪费了大量时间。 这些信息应该达到让一个刚走进屋里没有任何经验的人能看明白的程度。 客户和客服基本都是对编程不懂的人。
上面这些条目没有特别的顺序。 欢迎对这些我汇总的指导原则进行评论,也许你并不认可其中的几条,也请发表你们意见。
英文原文:26 Hints for Agile Software Development
发表评论
-
Google I/O 2011 Keynote 第二天
2011-05-12 09:52 833我们已经进入Mosco ... -
谷歌I/O 2011开发者大会现场报道
2011-05-11 10:16 895谷歌在全球设立了123个地方同步直播此次I/O开发者大 ... -
Google I/O 2011 Keynote 第一天内容
2011-05-11 10:07 828北京时间2011年5月11日凌晨0:00,Google将在 ... -
创新不断 Google I/O大会开幕八大亮点解析
2011-05-11 09:45 1089旧金山当地时间2011年5月10日上午10点,Google ... -
PhoneGAP一款Html5开源框架,支持6个移动平台
2011-04-21 11:32 794这是我发表在html5研究小组上的一片文章,给大家分享新看点! ... -
微软如何面对HTML5,算是“坑爹”吗?
2011-04-21 11:30 870这是我发表在html5研究 ... -
回顾被人们遗忘的软件前辈们
2011-03-28 14:45 959中国广大地区有在清明 ... -
不要放弃你的梦想
2011-03-24 17:08 619本文是从 For God's sake, follow you ... -
真正的程序员,请你站出来
2011-03-24 17:05 568我们积极的对外招聘已经有四个多月了,如果要问从这次经历中有哪些 ... -
你第一要做的是开始去做
2011-03-24 17:02 590很多人都问我,“我想 ... -
你知道有几个开发人员是超过40的?
2011-03-24 17:01 600对你们当中不少人而言 ... -
改良程序的11技巧
2011-03-24 16:53 627本文是从 11 tips for better code 这篇 ... -
“测试是浪费时间,我的程序肯定没问题”
2011-03-24 16:48 551本文是从 Testing is waste of time, ... -
你的架构很烂,但我并不在意
2011-03-24 16:45 707本文是从 Your Architecture Sucks an ... -
为什么我不适合搞编程
2011-03-24 16:42 560本文是从 这篇文章翻译 ... -
你的代码写的很烂
2011-03-24 16:41 543我有一个很熟的朋友,他现在忙的不可开交。他手上有一大堆没有完 ... -
我的丈夫是个程序员(老外)
2011-03-24 16:39 908本文是从 My husband is a programmer ... -
超级性感的卷轴式概念手机:Rollerphone
2011-03-23 15:16 650说新经济最重要的特点,不是要赚钱,而是要性感——从这个角度上 ... -
回收站删除文件找回
2011-03-17 16:46 854误删资料恢复 一不小心,删错了,还把回收站清空了,咋办啊? ... -
JSON 的说明
2011-03-17 13:56 1429JSON 是什么? JSON的全称 ...
相关推荐
#### 二、敏捷开发的实践技巧 **1. 逐步构建用例** - **实践要点**:确保一个用例完全开发完成并通过所有相关测试后再开始下一个用例。这种做法有助于避免因多任务并行导致的无效劳动。 - **关键价值**:减少不必...
敏捷开发是一种以人为核心、迭代、循序渐进的开发方法论,旨在应对快速变化的市场需求,提高软件产品的质量和开发团队的效率。敏捷开发的主要思想来源于极限编程(Extreme Programming, XP),它强调灵活应对需求...
### 敏捷开发的26个心得解析 #### 一、概述 敏捷开发是一种强调适应性和灵活性的软件开发方法论,其核心理念是以用户需求进化为中心,通过迭代和循序渐进的方式来构建软件。与传统的瀑布式开发模式不同,敏捷开发...
本文将分享过去一年中实施敏捷开发的心得体会,特别是在产品开发过程中的关键要素,如概念和架构设计、SWOT分析、业务驱动与客户导向、版本兼容性以及文档管理。 1) 注重概念和架构设计,而轻详细设计 敏捷开发倡导...
通过合理选择瀑布模型、迭代式开发、螺旋式开发和敏捷开发的应用场景,我们可以更好地满足不同类型的项目需求,提高团队的生产力和客户满意度。在实际操作中,我们需要不断学习和调整,以实现敏捷管理的精髓,让团队...
敏捷开发流程通常包括迭代前准备、迭代开发和系统集成测试(SIT)三个阶段。在每个阶段,团队会进行一系列敏捷活动,如站立会议、结对编程、故事点估算、头脑风暴会议、需求分析、测试用例编写、持续集成(虽然本次...
《敏捷实践的秘密(来自软件界实践者的经验心得)》这一资料集揭示了敏捷开发的核心理念和实际操作中的技巧。通过团队建设、技术探析、敏捷实践和敏捷测试等多个角度,我们可以深入理解如何在项目中成功地实施敏捷。...
在这一阶段,学员可能经历了从编写简单的代码到解决复杂问题的转变,理解了团队协作、版本控制和敏捷开发的重要性。这些心得分享有助于后来者更好地规划自己的学习路径。 "成为软件工程师之心得"意味着学员已将目标...
Java项目开发心得分享 在Java项目开发过程中,我们往往能够积累丰富的经验和技能,尤其是在一个团队环境中,协同工作、解决问题和持续学习是提升的关键。在这个特定的项目中,我们的部门成功地组建了一支高效的JAVA...
以下是关于敏捷开发的26个心得所涵盖的核心原则: 1. **单一任务完成原则**:开发过程中,应专注于一个用例的完整实现,确保其功能、测试用例和文档都完备后再进行下一个用例的开发,避免并行任务导致的浪费。 2. ...
- 理解敏捷开发方法(如Scrum、XP等),如何在敏捷环境中运作,包括站立会议、迭代规划、回顾和日常协作。 5. 测试与问题解决 - 软件测试是确保产品质量的关键环节,实习生需要了解单元测试、集成测试和系统测试...
理解软件生命周期模型,如瀑布模型、敏捷开发等,有助于我们规划和管理项目。软件工程课程不仅仅是理论知识的传授,更重要的是培养我们严谨的思维习惯和规范的开发流程。 在软件工程中,我们学会了如何书写清晰的...
下面是博客园的青宇对敏捷开发的一些理解与心得分享:我们部门是一个基础平台研发部门,主要为其他各部门提供技术接口和服务支持。也正是由于这个特性,部门内正在考虑基于WCF搭建一套服务平台。部门内提倡敏捷开发...
- 采用敏捷开发方法,如极限编程(XP),可以尽早发现问题,通过迭代不断调整和改进代码。 5. **代码审查与团队协作** - 代码审查是保证代码质量的有效手段,可以发现潜在问题,促进团队知识共享,提升整体水平。...
在这个章节中,作者详细介绍了如何运用Scrum等敏捷开发方法来管理个人事务,包括但不限于设定短期与长期目标、制定实施计划、定期检查进度等。这种方法不仅适用于项目管理,同样适用于个人生活的各个方面,比如职业...
Scrum是一种敏捷项目管理框架,特别适用于复杂和不断变化的软件开发环境。它强调灵活性、迭代开发、团队协作和快速反馈,以适应不确定性和需求变化。以下是对Scrum核心概念的详细阐述: 1. 敏捷哲学:敏捷的核心...
从早期的瀑布模型到后来的敏捷开发,再到现在的DevOps实践,软件工程的理论和模型在不断演进。这些理论和模型的一个核心目标是解决软件开发周期的问题——如何合理地组织和控制软件开发过程中的各个步骤。 在学习...