写代码的目的
编写代码, 让机器替人们完成某些**工作**!!! 如果不能很好地完成**工作**,再炫酷的代码,都毫无价值.
我们要做的,就是这件事,并且让它简单. 为了达到这个目的,你会见到各种技巧: 随处可见的复用思想, 单一职责等…
价值观
沟通
- “不要浪费别人的时间”:尽可能简短的话描述出问题及观点;
- “想法”:我们喜欢听到不一般的想法,见解;
- “就事论事”:不要将情绪带入讨论,尊重他人的想法,即使你觉得很可笑,但也有可能是你错了.
简单
KEEP IT SIMPLE & STUPID
反馈
过度自信是编程的职业病，反馈则是其处方。 -- Kent Beck
通过图表来交流你的想法，你可以快速获得反馈，并能够按照建议行事
谦逊
最优秀的开发人员都拥有谦逊的美德,他们总能认识到自己并不是无所不知的。事实上,无论是开发人员还是客户,都有他们自己的专业领域,都能够为项目做出贡献。一个有效的做法是假设参与项目的每一个人都有相同的价值，都应该被尊重.
核心原则
主张简单
如果你现在不需要这样的功能, 那么现在就不必实现它. (注意:是现在,实现;并不意味着永远)
拥抱变化
因为变化所以美丽。你会面对很多变化,要学会从心里喜欢上它. 这样会让你每天都会期待明天的到来。但是如果你没有对应变化的能力,它会让你讨厌.
可持续性
软件和自然界很多动植物一样,都是在不断的”进化”; 当你在写当前版本的代码时,时不时地想一想:”这个以后可能会变化么?,会怎么变呢”.
递增变化
你不用在一开始就准备好一切。实际上,你就算想这么做也不太可能。而且,你不用在模型中包容所有的细节,你只要足够的细节就够了.
记住目的
为了展现你高超的技艺, 再去写一遍代码是错误的. 回头看再看一眼我们的目的就知道了. 时刻盯准我们的目标, 先用最少的成本去让它 work.
高质量的工作
没有人喜欢烂糟糟的工作。做这项工作的人不喜欢，是因为没有成就感；日后负责重构这项工作（因为某些原因）的人不喜欢，是因为它难以理解，难以更新；最终用户不喜欢，是因为它太脆弱，容易出错，也不符合他们的期望.
快速反馈
从开始采取行动，到获得行动的反馈，二者之间的时间至关紧要。和其他人一共开发模型，你的想法可以立刻获得反馈，特别是你的工作采用了共享建模技术的时候，例如白板、CRC卡片或即时贴之类的基本建模材料。和你的客户紧密工作，去了解他们的的需求，去分析这些需求，或是去开发满足他们需求的用户界面，这样，你就提供了快速反馈的机会。
团队协作
当你在用别人的一个API时,口中不断的:”fuck,为了调用它的接口,老子要多些20行臃肿的代码,你换种方式不就完了嘛”。 换位思考,当你在为别人编写API时, 换过来, “如果别人给我提供这样的接口参数时,我用起来爽么?”
时刻记住,只有你的代码被用户运行起来的时候,才体现出了它们的价值:
- 最重要的是通过尽早和不断交付有价值的软件满足客户需要;
- 我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持竞争优势;
- 经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好;
- 开发者应该在整个项目过程中始终朝夕在一起工作;
- 围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要;
- 在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈;
- 可以工作的软件是进度的主要度量标准;
- 对卓越技术与良好设计的不断追求将有助于提高敏捷性;
- 简单——尽可能减少工作量的艺术至关重要;
- 最好的架构、需求和设计都源自自我组织的团队;
- 每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为;
