我理解xp与rup,cmm是两个极端(都是很好的),而经验就是如何在这两个极端中根据项目、开发小组等情况把握平衡点,
1、敏捷方法强调最少化的文档,甚至认为“好的代码就是你所需要的所有文档”。是这样吗?
是,如果不能用一句话把函数说明白,把这个函数分解,直到一句话能把它说明白,而此时函数名就说明了一切。(当然不可能用远这样,还是要写文档,特别是中国人很难用简单的英语来起函数名称)
2、敏捷方法试图减少了最广泛的user的沟通,例如希望通过“official user”作为桥梁与其他相关使用者沟通。是这样吗?
错了,敏捷方法是最注重用户了,希望有专门的用户从始至终的跟在开发小组旁边,随时解决问题
3、敏捷方法强调淡化过程和工具。是这样吗?
敏捷是一种新的方法,当然原来用的过程和工具都不能用了,但是现在地pair工具,refactoring工具都在研制中,会有一套新的工具,如果你在新的方法下使用旧工具,岂不是...!@#$%^&
4、敏捷方法的核心就在于refactoring,希望一切的change都能通过refactoring解决。是这样吗?
不只是refactoring了,refactoring也不只是解决change了,建议阅读refactoring这本书后再看design pattern。
1、敏捷方法强调最少化的文档,甚至认为“好的代码就是你所需要的所有文档”。是这样吗?
是,如果不能用一句话把函数说明白,把这个函数分解,直到一句话能把它说明白,而此时函数名就说明了一切。(当然不可能用远这样,还是要写文档,特别是中国人很难用简单的英语来起函数名称)
2、敏捷方法试图减少了最广泛的user的沟通,例如希望通过“official user”作为桥梁与其他相关使用者沟通。是这样吗?
错了,敏捷方法是最注重用户了,希望有专门的用户从始至终的跟在开发小组旁边,随时解决问题
3、敏捷方法强调淡化过程和工具。是这样吗?
敏捷是一种新的方法,当然原来用的过程和工具都不能用了,但是现在地pair工具,refactoring工具都在研制中,会有一套新的工具,如果你在新的方法下使用旧工具,岂不是...!@#$%^&
4、敏捷方法的核心就在于refactoring,希望一切的change都能通过refactoring解决。是这样吗?
不只是refactoring了,refactoring也不只是解决change了,建议阅读refactoring这本书后再看design pattern。