平凡却又深刻的编程理念：迭代
我要一步一步往上爬…… —— 《蜗牛》
迭代，也许是本系列里出现在程序员工作中的最高频词汇。
谈及迭代，程序员可能会直接想到
- 编程语言里的迭代器（iterator）或设计模式里的迭代模式，用于遍历对象集合而不需要了解对象的具体实现。
- 代码审核里的迭代。
- 工程项目里的迭代，比如敏捷开发过程里的sprint。
- 产品的版本迭代。
更广泛地想，迭代这种重复反馈过程的活动充斥在程序员工作的方方面面，比如代码从修改到最终上线的迭代，设计活动的迭代，在探索新项目/新功能早期做的POC（Proof of Concept）或原型，等等。
为什么会有这么多迭代？或者为什么需要迭代？每种迭代会有不同的具体原因。如果要往一个答案去思考，也许是因为大多活动的目标一般是复杂的，很难一步完成的，而分开步子走更可控。
我觉得，迭代理念的核心在于缩短反馈周期，从而快速消除复杂性和不确定性，保证良好的效能。
在做一件复杂的或不确定的任务时，聪明或有经验的人会先“试试看”，从而快速评估可行性、难度和工作量等。正如本系列文章第一个分享（《Make it Work then Make it Better》）说的，先搞定一个可用的版本再去改善。
同时，越早接收反馈，越早明确效果并进行必要的调整；比如
- 代码的修改，构建（Build）和自动化的单元和模块测试是最早的反馈；接着为了保证安全上线，会进行灰度发布，监控核心指标的变化，这是正式发布之前的反馈。
- 算法的更新也需要先进行线下验证，然后再进行线上环境的测试集验证、灰度测试、A/B测试到最终的发布。如此能将潜在的问题及早被发现，以便进行下一次迭代。
对于团队工作而言，迭代周期有利于团队集中力量完成最重要的任务。同时，迭代周期也是团队生产力的体现，或者迭代周期要符合团队生产力的现状。
- 迭代周期太快，一种可能是工作没有得到有效反馈和调整，渐渐地迭代就是失去了意义，只留下周期性的流程；或者花费在同步和调整的成本增加，也容易忽略产品全局的优先级。
- 迭代周期太慢，我觉得主要是影响有效输出的最大化，毕竟反馈晚了，必要的调整也就晚了。
迭代理念的兴起，是一个很自然追求生产效率的过程。计算机软件主要还是近二三十年才飞速发展，成为一个现在大多人都知道的行业。飞速发展的过程，必然会伴随着更好的语言、工具和工程理念的出现。当然，软件易于改动的特性，也极大地加速了这个进程。
同时，随着生活中接收信息的节奏越来越快，人们对及时反馈的需求也明显增强。比如培养一种技能，现在流行的理念已经不再是强调长时间积累的“台上一分钟，台下十年功”，而是《精进》、《刻意学习》等书籍里强调的追求能有短期反馈的有针对性的高效学习。要注意的是，这不意味着学习就变成一种快速的过程，而是有了持续的短期有效的反馈学习才更容易坚持下去。其实这种小目标大成功的理念在常见的高中作文素材就有体现——一位著名的马拉松选手将马拉松的路线分成多个小终点，每次经过一个小终点，他知道自己完成一个小目标，而离最后的目标越来越近。
"想做世界首富，这个奋斗的方向是对的，但是最好先定一个能达到的小目标，比如我先挣它1个亿。" ——王健林
结合上周的主题《生命周期》，迭代可以理解成生命周期里重复的一段段活动。良好的迭代节奏和卓有成效的迭代效果，有助于打造理想的生命周期，比如起步得快，发展得更稳，繁荣得更持久等。这样的生命周期可以是项目的、产品的，或者是人生的。
