需求的变化时普遍存在的，人往往不知道自己需求什么。因此，要拥抱变化。提高自己代码的可扩展性。
你只能复制平庸，永远无法复制优秀。因此，在欣赏别人代码的或者使用demo的时候，要带着欣赏和批判的眼光来进行判定。
优秀的程序员，应该让优秀成为一种习惯。思考无处不在。
持续集成的过程中：之所以你不知道你为什么会出错，调不出bug，是因为你在写的时候，也不知道这些东西为什么是对的，为什么这样写。你所做的只是为了完成任务的模仿。
设计模式只是一种设计结果，你应该从中学习到的是一种解决问题的思想，同时，在自己的项目中加以利用。
软件设计：角色，职责，协作。
用代码去描述事件，而不是用文档。因此，当你的代码足够优秀，别人读你的代码，就会知道你在做什么，怎么做了？
用简单直观的方式来处理某件事情。
要尽力去掌握别人所不能掌握的稀缺资源。例如，一种卓越优秀的编程习惯。
SOLID:原则
程序中绝对不能出现else if。
if很多时候的重构：
首先：进行关注点分离，找到不变和可变的部分。（分离）
然后：将不同的关注点进行分离，创建新的方法。（抽离共同）
抽象，封装，多态：设计模式其实是一种封装的手段，封装是进行重构的基本。抽象:定义一种规约，一种共同遵守的预定。多态：对抽象进行实现。（重构中的面向对象三要素）
好的代码是不会恐惧单元测试，单元测试只会让你代码更加自信。
一个好的程序员会使用能力范围内最好的工具。
对于一个程序员来说，鼠标使用的越多，操作越复杂.帮助文档越多，程序越不宜用。
常用开原协议：MIT,Apache，JPL,....
敏捷常用词汇：
TOC,XP,SCRUM,BECKLOG.TIMEBOX,FDD,DSDM,AGILE,TDD, CI,PG,Metorphor,Sustainble Pace,Planning Game,Simple Design,Pair Programming,Collective OwnerShip,Small Release.
敏捷宣言：
个体和交互：胜过过程和工具
可以工作的软件：胜过面面俱到的文档
客户合作：胜过合同谈判
相应变化：胜过遵循计划
最后附上：xp图（scrum的迭代环图）
实际开发中，适应敏捷开发的几点要求.
首先：尽可能的写好，单元测试，尽可能的实现TDD.
然后：和团队配合默契，注重结对编程和展示会议。
最后：关注代码质量（sonar）
来源：oschina
链接：https://my.oschina.net/u/854917/blog/177669