敏捷软件开发第一部分（总）

开始学习敏捷软件开发，现以每周一次的频率记录学习心得。

本来是准备按一个月一个月的计划学习进度，在看了书本后有所改观。

较好的做计划策略：为下一周做详细的计划，为下3个月的做粗略的计划......（好吧，我感觉以我现在的情况，最好是做一周的计划，并大概推算出下一周的粗略计划，这样比较合适。毕竟现在加班每天基本工作-睡觉-工作-睡觉，在疲劳状态下学习感觉受益真心不好。好吧，我应该是在为我的懒找借口。）

第一部分是概念，大概的阐述了敏捷开发的起始以及形成的因素，并展示了一个实践例子，让人更好的理解了为何要这样做。

大致内容可以归纳为 原则（principle）、模式（pattern）、实践（practice）

原则：（本来还想从凭记忆打出来，发现脑袋一片空白，还是抄吧，加深记忆~）

1.最优先要做的是通过尽早地、持续地交付有价值的软件来使客户满意。交付越频繁，最终产品质量越高。

2.欢迎需求的变化，即使到了开发后期，敏捷过程能够驾驭变化，为客户创造竞争优势。

3.经常交付可以工作的软件，从几个星期到几个月，时间间隔越短越好。

4.在整个项目开发期间，业务人员和开发人员必须朝夕工作在一起。（记得，是必须）

5.依靠斗志高昂的人构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。

6.在团队内部，最有效率也最有效果的信息传达方式，就是面对面的交谈。

7.可以工作的软件是进度主要的开发阶段。

8.敏捷过程提倡可持续开发。

9.对卓越技术和良好设计的不断追求有助于提高敏捷性。

10.简单--尽量减少工作量的艺术是至关重要的。

11.最好的构架、需求和设计都源自自我组织的团队。敏捷团队是自我组织的团队。

12.每隔一段时间，团队都要总结如何更有效率，然后相应地调整自己的行为。

其他的内容里，就只对重构是比较能理解的了。

重构是在不改变代码行为的前提下，对其进行一系列的小改造，旨在改进系统结构的时间活动。每个改造都说是微不足道的，几乎不值得去做，但是所有的这些改造叠加在一起，就行为了对系统设计和构架显著的改进。

 

ps.作为一只小菜鸟，真心觉得代码需要经常重构，就我个人的例子，有时有些业务逻辑感觉不清晰，就先写了很庞大的函数，先将业务逻辑跑通，再开始一点点把功能拆分出来。在一开始的时候觉得自己还能理解，就不去理会，等过了一段时间之后，需求改动，再回去重新改的时候就发现自己也要花好一段时间去理解，而且有些改动还是影响到其他的逻辑。个人感觉当天处理的业务逻辑如果感觉处理的不好，就该好好花些时间去重构，毕竟自己挖的坑，再苦也要把坑填回去（捂脸哭泣~）

后续的就是谈到测试以及一个实践例子啦。测试的说实话，有些看不大懂，不过看了书本里的例子之后也大概明白了。（对，只是大概。）

嘛，第一周先这样，对于概念性的东西，其实我的理解还是比较薄弱的，还是在书的第二部分努力多敲代码吧。

下周计划是先看完第7章到第9章（这是保守估计看的内容，估摸最多可以看到14章并包含敲代码，如果判断的不准，会自主减少或追加。加油！）