2019关于敏捷开发的26个心得

《2019关于敏捷开发的26个心得》由会员上传分享，免费在线阅读，更多相关内容在应用文档-天天文库。

1、关于敏捷开发的26个心得　　敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。　　■用例一完全能够运行后再开发用例二。厨房里有一种说法正好可以印证这个问题：“做好一盘菜后你再做下一盘”．对于软件开发来说一个最大的问题就是人们喜欢并行开发多个任务。因为不可避免的，我们设计的功能中总会有一部分会被

2、放弃砍掉，如果提前开发，很可能做无用功。一次只开发一个用例；让这个用例功能完整；让相应的测试用例都能通过；相应的文稳都补齐；只有在当前的用例完全开发完成后，才做为一个整体提交到版本库，才进行下一个用例。　　■避免提交一个半成品。这一点大家似乎都知道，但这条原则必须列入任何一个开发指导里。能够听取这些忠告进行开发测试然后提交代码的程序员一定不会发生代码提交到版本库使整个项目无法编译码通过情况。如果系统编译失败，那一定是有人抄近道到了。　　■不要在还没有任何使用案例的情况下设计通用模块。只有在你知道有具体用例的情况下，你才可以实现一个具体的

3、类，而且你在该类中只应该实现当前该用例需要的方法。你也许会想到将来这个类会有其它的用途，你可以用注释的方式记录一下，但不要去实现它，只有在有了具体用例后你才可以实现它。　　■一定不要在没有使用例的情况下往类里添加成员方法。这跟上面一条极其相似，除了这里针对的是数据成员。开发人员很容易想到：一个客户记录里应该有送货地址的信息，但一定不要在没有任何用例要求这个属性的时候实现这个属性。■不要害怕做决定；不要害怕改变以前的决定。敏捷开发的目的是应对客户需求的不确定。开发前期你不可能获到全部的信息。你应该尽可能的拖延做决定的时间，但一旦到了你该做

4、决定的时候，你应该当机立断，让项目向前推进。你不能说一直等到有了足够的信息才做决定。相反，你要依赖现有的信息作出最正确们决定。之后，当有新的信息出现后。　　不要害怕对以前的决定作出更改。(老辈人有的称之为触发器，但我称之为随环境而变)　　■不断的了解如何改进系统。这项工作没有尽头，你应该做好思想准备，持续不断的寻找可以改进的地方，收集各种关于如何找到质量问题、解决质量问题的案例。　　■审查，审查，审查。敏捷开发可以帮助我们应对需求在将来的不确定，但过去的事情也存在不确定性。测试工作永远不能停下来。程序每次运行的表现都要被评审和记录。　　

5、■软件的设计要以人为本，而不是系统。很多开发人员退而求其次、以技术为中心，让设计为技术服务。永远不要忘记软件的终极目标是什么，是帮助人们完成工作。　　■测试是产品的一部分。许多开发人员和经理都认为产品就是你打包给客户的东西，其余的都不重要。其实测试也应该看作是产品的实际一部分，应该在设计时给予相当的重视，甚至，在很多时候，测试功能也应该同产品一起提交给客户。当开发人员开发一个设计用例时，有的功能会牵涉到所有修改着的但未完全开发完成、充分测试的代码。把未修改完成的代码保存到本地数天或数星期，这样增加了工作浪费的风险，会出现返工。想象有三个

6、任务，每个估计都要一天。如果三个一起开发，并行起来每个都需要3天，这样一累计会有9个单位的风险。如果顺序的开发，一个开发完成后再开发另一个，只会有3个单位的风险。这个并不符合我们的直觉。我们的直觉告诉我们，当我们在这种情况下时，我们希望三个一起完成。但是软件不像盖房子。小的、迅速的、完整的任务不仅仅会降低我们的认知负荷，也减少了进行中的开发对其他人正在进行的开发的相互影响。　　■不要过度功能范化。也就是我们所说的“YAGNI–YouArentGoingtoNeedIt”。程序员在编写一个类时喜欢料想：这个类可能在其它地方其它类中会有其它

7、用途用．如果这些用途是被当前的用例用到，那这样思考是没错的，但常常开发人员想到的这些用途都是目前不存在的用途，实际上可能是永远不会用到的用途。　　■如果两行代码能完成就不要写成三行。简洁的代码永远都会给需要阅读这段代码的人带来好处。但千万不要把代码压缩的难以理解了。精简的、书写规范的代码易于维护和查找错误，冗长的、太多修饰的代码则相反。尽可能的简化但不要过度。　　3　　■永远不要按行数多少来评价代码头。编写某个任务所产生的代码行数会因程序员而异，因编码风格而异。代码的行数不会提供任何关于程序完成情况和代码质量的信息。代码质量可以相差20

8、0倍之多，这是计算代码行数的方法不能胜任的。应该计算功能性的用例数。　　■我们应不断的再设计、再分析。应用这一条时你要非常的小心，因为有些代码很脆弱、难以维护。但不要害怕修改这些代码、让它符合真正的需求。一