在这本书中看到了自己包括当先编码也会存在的不好的习惯,做好笔记,反思,希望将来改过。
在这本书中的名言有好几处,这里先摘录出来,这些名言不仅适用于开发。
1、不管路走了多远,错了就要重新返回。
2、选定了路,就是选定了它通往的目的地。
3、对事不对人,让我们骄傲的应该是解决了问题,不是比较谁出的主意更好。
4、能够容纳自己并不接受的想法,表明你的头脑足够有学识。
5、即时你已经在正确的轨道上,但如果只是停滞不前,也仍然会被淘汰出局。
6、任何时候只要你没准备好,那就是敌人进攻你的最佳时机。
7、一步行动,胜过千万专家的意见。
8、不同环境就有问题,不同的人,当然就有不同的想法及经历。
9、要休息的话,就好好休息,休息时不要碰键盘。
10、无论何事,你们愿意怎样对待他人,他人也会怎样对待你们。
11、用问题来回答问题,可以引导提问的人走上正确的道路。
12、(自己对自己说的)不要等到合适的时候才告诉自己做到最好,而要每时每刻都最好最好。
序言中:
1、敏捷宣言:一种把以人为本、团队合作,快速响应变化和可工作的软件作为宗旨的开发方法;
2、个体和交互胜过过程和工具;可工作的软件胜过面面俱到的文档;客户协作胜过合同谈判,相应变化胜过遵循计划;
3、
敏捷开发就是在一个高度协作的环境中,不断的使用反馈进行自我调整和完善。
4、可使用的工具有:
WIKI,版本控制,单元测试,自动构建工具;
5、
持续集成和测试;
注解: 敏捷开发的宗旨是以人为本的,注重团队协作,目的是能够快速开发和响应变化的开发方法;在谈论这种方法适合哪种项目之前,先看看敏捷流程或者说敏捷的开发方法目的是为了什么?
1、团队协作:请问在其他的项目不需要团队协作吗?肯定是需要的,而且丝毫不差于敏捷项目;好的,我们在后面会知道敏捷要得人团队频繁沟通,频繁试错,频繁迭代,来适应快速变化的项目(也可能是假装很懂的甲方),所以这里团队协作是要团队在频繁沟通,试错,迭代,频繁周期周转的情况下好好合作,这就牵扯到什么样的人适合敏捷项目了,这里不赘述,下面谈到。
2、快速响应变化:也就是说变化很快,这种变化包括需求变化快而密集,而且项目截止日期很紧张;
3、快速试错,快速迭代,快速失败;请注意这里的12个字,这个才是敏捷最终要做到的。
所以:在敏捷开发中以人为本的意思就是每个人发挥自己最大的能力,去快速试错,快速失败,快速迭代,完成一个项目;
第一章:态度决定一切
1、专业的态度;除了问题,先解决问题,而不是先问是谁的错;指责不能修改bug;
2、 重视结果,过程符合标准并不意味着结果是正确的;
3、
欲速则不达,防微杜渐才是根本;解决问题是最基础的,知道产生问题的根本及影响才能区分出水平高低;理解开发过程及开发方法也是非常重要,且是作出有效改变的唯一途径;为何它们是这样的,以及如何成为这样的。
4、
切勿坠入快速简单修复bug的泥淖之中;
5、
代码要保持敞亮与整洁
6、
要交谈而不是争论或者针对人的辩论;对事不对人;
7、
设定最终期限(没有最好的方案,只有最适合的方案);逆向思维;设定仲裁人;支持已经做出的决定;设计充满了妥协;
注解:无论是否在敏捷中专业的态度是必须的,首先就是敬业,其次是先解决问题,而不是问谁的错,最后是以重视结果的方式来做好过程,但是目的一定要达到。在PMP项目管理课程中也是要强调出了问题,先解决问题,不是问谁的错,这一点看是简单,但是比较难做到,因为在很多情况下自己克制自己是可以做到的,但是一旦团队中有几个人是先推责任而不是解决问题,那就会容易自己也跟着脾气走,这时就需要项目经理出面了,需要提前指定好规则。
在编程中切勿坠入快速简单修复bug的泥淖之中,这一点很重要,但是绝大部分人都做不好,因为这是一种能力的凸显或者说表现的机会,但是还是按照这条规则要求自己吧,因为在这其中你会让自己很快脱颖而出,虽然在解决单个问题上时间可能比其他人。
代码保持敞亮和整洁,这个不好定义,风格不同,暂不商议;
对事不对人,这是是否专业上最容易看出来的。
第二章:
学无止境
1、
每天计划用一段时间来学习新技术;了解最新行情;
2、参加研讨会议;如饥食渴的阅读;午餐会议,分享;
3、
学习新的知识或是技术时切记不要把自己旧的思维习惯运用到新的技术上
4、
追根究底,打破砂锅问到底
5、
让开发很规律,有固定的迭代周期,并坚持
注解:这里的学习可能包括技术,可能包括其他的,在中国这种人情社会中,互相分享,为自己的同事找到合适的发展之路,担任部分职业规划师的职责,你会受用很多,尽管这个江湖很大,但也可能很小。
第三章:
交付用户想要的软件
1、
决定什么该做决定
2、
设计满足实现即可,不必过于详细
3、
设计分为两种:战略和战术。前期的设计属于战略,通常只有在没有深入理解需求的时候需要这样的设计,这时不应该深入到具体的细节
4、技术
是否能解决问题;会被拴住吗;维护成本;不要开发你能轻易下载的东西;
第四章:
敏捷反馈
1、
不要放过任何一个失败的测试
2、
任何一个设计都可以被改进
3、
不同环境,就有不同问题
4、
使用自动化会节省时间,持续集成工具;FIT,集成测试框架;
6、
关键业务逻辑必须要独立进行严格的测试,并且最后需要通过用户的审批
待完善。