不起那些花哨的名字。只是说说自己的读后感。

      先说说，。

      确实，当一个东西变成一种宗教，一种规定，或者这样说，变成某种教条的我们不得不遵循的规范的时候，那么这种东西就失去了很多当初作为方法的灵活性和生命力，就会变的僵硬和死气沉沉。特别是对于“敏捷”来说，一旦把敏捷作为一个一步一步的规范，那就完全失去了敏捷的意义。

      真的敏捷应该是一种理念。核心在于关注用户的需求与实际，核心在于应对现在快速变化的市场。敏捷的典型应用场景确实就是应该在那些用户不需要100%的可靠性但是可能会经常改变需求，需要尽快拿出解决方案的地方。敏捷开发需要很多轮的迭代。我觉得文中有一点说的很好。敏捷开发的手段可以帮助我们确定在规定的时间内到底能不能完成要求。因为敏捷的原则就是我们每次都尽快做出一个可发布的版本，然后通过与用户的交流和反馈，我们就可以知道某些功能是不是已经做到了要求，那么我们就可以不在那些功能上再花费时间（以后的几轮迭代中可以继续）；我们也可以知道哪些功能用户已经不需要了，那么当然，我们也不用再花费时间去做了。这样，实际上，去掉了以前形式化开发方法的桎梏。显得更加灵活，当然，这就是敏捷的意义。

     

      再说说，

      这里我主要结合我们小组——SuperBrothers进行的关于“英语学习助手”来讲一下感想。文中的一个很重要的观点是："代码越重用，浪费越严重"。我们的工程呢，是对原来的一个东西进行二次开发，但是这样就存在一个问题，原来的东西我们要怎么改？改多少？事实上，我们组由一位大牛领导，他完全放弃了原来的架构，这样导致工作量很大。特别对于我们来说，难度加大了很多。特别是在很多时候，我们都在等待他设计程序的接口，他对接口的要求很高，所以进度一直是让人头疼的事情。另一方面，大牛又真的很"大牛"，经常无声无息地就消失了，而且拒绝被联系。跪了。

• 如果封装得好，完全可以重用啊，节约开发时间。
• 问题在于设计一个封装良好的接口需要的能力和时间以及经验, 比实现一个恰巧对付,且仅满足你当下需求的模块要难的多,需要反复的时间多的多. 大多数和你项目无关的前人做的东西都达不到要求. 当然两者都是需要努力的。
• 不能摒弃别人的轮子. 问题在于什么是轮子? 轮子指的是一种设计, 一种圆圆的减少摩擦的让车子省力的动起来来的设计. 而不是你制造一部车的时候, 把报销的旧车上的车轮拆下来装上. 别人的模块的精华在于提炼出的接口易于使用. 实现则是次要的东西。

     

       最后说说，，这儿其实和上篇文章有些东西很相似。我的理解是这样的。首先原来的系统存在很多“大泥球”！！！！！！！！！！！！！！！！！！完全作者不考虑二次开发的做法，别口口声声说我还会维护，这TMD是程序员十大谎言之一！！！！我们的组长呢，组长决定Refresh，重新设计，重新设计接口。可是当我们进行了两周以后，我们发现一个很大的问题，那就是我们忽略了一个重点——你需要按时交付高质量的软件，并在预算之内。所以我们第一步要做的事情是——首先关注的特性和功能，然后集中在架构和性能。这个确实给我们上了一课。所以在开发的过程中，PM真的太重要了。或者说组长太重要了。当决定这个东西是做成一个什么定位的东西的时候。其实关系到这个软件到底能不能及时的出来。把握这个度真的很难！