对《万事欠备设计先行》的一点想法，兼谈XP和CMMI
周末陪女友，故沉默了，其实大脑并没有沉默，之前看到《万事欠备设计先行》 就有说点什么的冲动，但是始终说不出来，经过周末的一番思索终于说得出来了
BirdsHover 兄在文中所描述的情况其实相当的普遍，这点从观帖的人数可以看出，其实应该算是XP的一个经典场景。XP的精髓就是拥抱变化，不过老实来说就国内很多团队的水平来说，盲目的XP其实是一个相当大的赌博，真是不在变化中死亡就在变化中变态。这里倒不是想反驳 BirdsHover兄的见解，不过感觉层次停留在开发人员的阶段来思考这个问题未免有些失之偏颇，这里的 BirdsHover兄的意思就是提高抽象层级，在前期设计一大堆构件出来，在业务流程确定之后在搭积木一样的把构建拼凑起来。但是这里有两个问题，第一个是抽象的层次的问题，过高层次的抽象会造成系统的复杂度增加，一个足够灵活的构件必然是一个非常复杂的构件，这种构件设计和实现上的复杂度可能会超过这个系统本身，打个比方说，在项目里为了方便用了ibaties.net，但是由于变化可能很大，会常常修改Entity Class和配置文件，于是为了这里也足够灵活就去写了个ibaties.net的本项目专用配置管理工具，结果项目花了一个月，写这个工具就用去一半的时间。不知道 BirdsHover兄是否这么感觉，我凭个人猜测的，如果说得不对请指正。
当然项目没有银弹，所以我也找不出更好的办法来解决，所以这里暂时藏拙了，等我想到再说。这里说说XP和CMMI，在之前的问题 BirdsHover兄想到了XP的方法。很多人喜欢把XP和CMMI放到一起来说，其实我觉得是不恰当的，XP的Scope和CMMI比起来小得多，XP只专注于开发的，而CMMI则关注项目的整个生命周期，所以其实就不具备可比性，不过CMMI也不是死板的代名词，采用小步增量迭代的方式一样的也能灵活的适应变化，不过管理学上的东西太深奥了，有的时候并不是靠理论能够完全解决问题的，任何高深理论都有遇到中国国情这块铁板的时候，所以再说下去就假打了，就此打住，上班拉
BirdsHover 兄在文中所描述的情况其实相当的普遍，这点从观帖的人数可以看出，其实应该算是XP的一个经典场景。XP的精髓就是拥抱变化，不过老实来说就国内很多团队的水平来说，盲目的XP其实是一个相当大的赌博，真是不在变化中死亡就在变化中变态。这里倒不是想反驳 BirdsHover兄的见解，不过感觉层次停留在开发人员的阶段来思考这个问题未免有些失之偏颇，这里的 BirdsHover兄的意思就是提高抽象层级，在前期设计一大堆构件出来，在业务流程确定之后在搭积木一样的把构建拼凑起来。但是这里有两个问题，第一个是抽象的层次的问题，过高层次的抽象会造成系统的复杂度增加，一个足够灵活的构件必然是一个非常复杂的构件，这种构件设计和实现上的复杂度可能会超过这个系统本身，打个比方说，在项目里为了方便用了ibaties.net，但是由于变化可能很大，会常常修改Entity Class和配置文件，于是为了这里也足够灵活就去写了个ibaties.net的本项目专用配置管理工具，结果项目花了一个月，写这个工具就用去一半的时间。不知道 BirdsHover兄是否这么感觉，我凭个人猜测的，如果说得不对请指正。
当然项目没有银弹，所以我也找不出更好的办法来解决，所以这里暂时藏拙了，等我想到再说。这里说说XP和CMMI，在之前的问题 BirdsHover兄想到了XP的方法。很多人喜欢把XP和CMMI放到一起来说，其实我觉得是不恰当的，XP的Scope和CMMI比起来小得多，XP只专注于开发的，而CMMI则关注项目的整个生命周期，所以其实就不具备可比性，不过CMMI也不是死板的代名词，采用小步增量迭代的方式一样的也能灵活的适应变化，不过管理学上的东西太深奥了，有的时候并不是靠理论能够完全解决问题的，任何高深理论都有遇到中国国情这块铁板的时候，所以再说下去就假打了，就此打住，上班拉
