极限编程(XP)：将所有优势推至极致
2020-01-03
来源：技术大V公众号
仅用最简洁的代码来实现当前的需求，而不考虑未来可能的其他需要。这样做的原因是极限编程认为变化是经常的和难以预测的，我们现在预测的未来需求很可能随着种种变化而不会出现，所以干脆就不考虑未来的可能性，等它真正出现了再说。极限编程里有一个YAGNI的概念，即You aren't gonna need it(你将不会需要)的缩写。就是说你现在如果提前实现一些将来可能用到的东西，到时候你其实并不会用到它们，所以仅仅实现当前必需的要求就好。简单设计和上面提到的代码重构其实是一体两面的。不同模块简单设计的累积会让系统产生重构需求，而重构本身会让系统从整体上回到简洁的状态。
代码集体共有(Team Code Ownership)
也称代码共享，即开发团队中的每个人都有权利改动每一个部分的代码，而不是每个人只能改动自己负责部分的代码。鼓励主动性，在系统中发现了一个问题时，每个人都可以出来修正它。
系统隐喻(System Metaphor)
系统隐喻是指对代码中类、方法等命名尽量反映它在整个流程中的作用，这样在不详细阅读代码内容情况下也能从命名知道类和方法的用途，即使是不懂代码的用户或PM也能通过命名了解到系统运作的整个流程。用比喻来传达信息，解释功用。
程序员福利(Programmer Welfare)
可持续步调(Sustainable Pace)
极限编程要求程序员正常情况下一周工作时间不超过40小时，如果有需要加班时，连续加班时间不能超过一周。极限编程认为软件开发是长期的持之以恒的脑力过程，纯粹单拼时间不会提高生产率，和长跑一样，不急不慢才能以好成绩跑到最后。过分加班就像长跑时不合时宜的冲刺一样，一段时间内可能有短期效用，但这种效力不可持续，反而从长远上会伤害积极性，降低代码质量，产生有缺陷的产品。
结语
极限编程对软件开发的不可预测性采用了细化步骤和重视反馈的方式来解决。既然计划总是赶不上变化，那么我就走一步看一步，每走一步，就通过各方面的反馈来进行调整。每一步尽量跨得小一点(简单设计、小型发布、计划博弈)，同时尽量把得到反馈的时间减少，这样就能更快地做出调整。它对反馈的重视几乎到了无以复加的地步，反馈分为两方面：代码反馈和客户反馈。测试驱动开发、结伴编程和持续集成都是为了最快地得到代码的反馈，而现场客户、小型发布、计划博弈(邀请了客户参加)都是为了最快地得到客户的反馈。这所有的东西加在一起，都是为了更好地发现变化，拥抱变化，和变化共舞。
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
