在一次milestone开发过程当中，开发者会持续编辑issue列表，每一个issue都有本身的生命周期。燃尽图预期这些issues会被线性的消灭掉，因此从第一天直接到最后一天画个直线表示预期进度变化，然而实际开发会遇到各类困难，因此实际的进度变化曲线每每不是线性变化的，下面这篇文章给出了S型燃尽图：
https://sandofsky.com/blog/the-s-curve.htmlhtml
计算机是基于二进制的，有一句经典的台词是：这个世界上有两种人，一种是懂10进制的，另外一种是懂10进制的。可是在开发中，咱们经常要接触三进制。程序开发中有一个Keep it simple, stupid的所谓KISS原则，就是说咱们写程序，在没有必要的状况下，不要增长没必要要的抽象层。例如不少初学者在刚接触了设计模式以后，就会在很简单的程序上没必要要或者不正确的使用各类模式去写代码，但实际上那种程度的代码只须要把面向过程代码写好，作好函数这个级别的抽象便可。函数简洁但并不就简单，和一般的初学者相反，有经验的程序员更愿意用简洁的代码解决问题，而不会为了用上一堆所谓特性把代码写成花拳绣腿。一个函数须要考虑入口条件，出口条件，是否可重入，是否线程安全，所依赖的状态变化…等等。因此，有时若是你不放弃装饰，你就得放弃本质。git
可是，程序从开发的第一天开始就被持续迭代。有一句话说：程序从被写下的第一天开始就开始腐烂的过程，这是说程序会由于需求的不断变化而须要不断的被重构，一开始几行的代码可能会膨胀，再压缩，再膨胀，再压缩。不一样地方的代码会出现重复，各类各样的重复。因而，光有KISS是不够的，咱们须要另一个东西:Do Not Repeat Yourself,也就是所谓的DRY原则。怎样才能不自我重复呢？这就是所谓的三进制原则，一样一件事，重复作三次，就能够考虑批处理，计算机是最擅长作批量处理的事情，例如for循环，递归等。批处理的前提是结构的一致性，结构的一致为将他们装到容器里创造了可能。因此，为了批处理，咱们经常须要在结构上作抽象。一致性多是数据上的，也多是行为上的，根据程序即数据的原理，数据的一致性能够用行为的一致性表示，因此咱们能够只对行为的一致性考虑。在面向过程语言里，可能就是在函数这个级别考虑，在面向对象语言里，则更多能够在接口层体现。把共同的结构装到容器里的过程，就是组合的过程。程序员
好了，三进制大概说到这里。设计模式
从我一开始进入程序员这个行业开始，我就也会被软件开发中的人员配置问题困扰。一个团队，是否要有专职的项目经理，美工，测试，产品设计，以及并不讨人喜欢的行政，人力资源？从程序员的角度来讲，属于技术偏好型，能用技术解决的，毫不愿意经过增长一我的去解决，能用工具解决的，必定批量处理之。先进技术和工具，经常在效率上是数量级的压倒性优点。
回到小题，经过几年的过程，我想角色上不少时候这些角色都有其必要性，可是，一个角色要有多我的仍是一我的甚至直接由工具取代，则是能够因团队而不一样。怎样取舍和适应？我认为关键在于：是否有效率的解决问题，例如开发和测试，若是开发和测试两我的不能很好的协做，共同有效率解决问题，而一个二者皆作的更有效率，那么明显后者更好，反之则选择前者。
所以，角色分离，但人员能够合一。也就是人剑合一。数组
前面说燃尽图，软件开发，经常是一个长期过程。不是一锤子买卖，一个基础类库开发加一个上层产品开发就可能两年。但市场经常不等人，所以咱们要紧凑的过程和质量，那么就须要持续迭代。持续迭代体如今一个milestone以内的每一天之间，须要天天跟踪昨天，今天，明天的进度，解决的issue，新产生的issue，代码的提交，测试的经过率，发布的版本，用户的反馈等等。持续迭代同时体如今milestone和milestone之间，粒度会更大一些。
一个理解持续迭代的地方是解bug，任何bug，咱们都须要首先尝试去重现它，作二分排除定位，作单元测试刷豆子，搜集证据链，一步步掐头去尾缩小范围，最后解决。这也须要持续迭代。
持续迭代不只在节奏上保持紧凑，并且把过程渐进展开，咱们都知道软件开发的敌人是黑盒子，不能预期的时间和进度，因此持续迭代的过程，咱们经过燃尽图，issue管理，bug跟踪，反复把过程dump出来，让进度可视化，促进软件开发的正面化学反应和收敛。安全
while(rest>e){ step(); }
软件开发，涉及到不少须要推理的地方，例如天天的解bug，这里须要逻辑，也就须要充分必要。一个论点，它的论据是不是充分必要的，就是体现逻辑的地方。
其余地方，例如作案例分析，咱们训练思辨和分析，我想也应当是基于逻辑的。例如作需求分析，也是应该以是否符合逻辑为核心，若是连本身都说服不了，泛泛而谈的形式化需求分析，多半是须要被从新作的。因此，原则应当是，写完本身读一遍，根据是否充分必要去复审，也许须要补充数据，真实的数据很重要，有数据就能够拿数听说话，一个断言在有数据支撑的状况下，更可能有效。但使用数据要避免单样本统计学家式的武断，同时也要不失管中窥豹的洞察力，这大概须要反复锻炼，反复成功或者失败。性能优化
程序员是带工具属性的，工程上，每一个小事情均可能有相关的工具能够利用，若是没有，咱们就造工具。一样的管理源代码，咱们有svn,git，当咱们赤手空拳，咱们合并别人的代码，可能会先临时拷贝本身新改动的代码到某个临时文件夹S，而后把别人的代码覆盖进来，完了再把S和其diff，再修改。用git，这个过程就是git stash，git pull,git stash pop，因此有时候只要想一下一个操做过程当本身没有工具是是怎么作的，可能工具也大概就是这么作的，只是变成了更有效率的命令。工具也是符合逻辑的。
两个团队A和B。A没作事，B不用工具作事，B比A强；A不用工具作事，B用工具作事，期待的是B比A更有效率的解决问题，不然B并不就比A强；若是两队都作事也都有效率使用工具，则能够开始比内容。因此把那些提升效率的工具都用到习觉得常，瓶颈不卡在那些上面，咱们就进入比拼真正的最终目标上。反复的训练和使用，能够达到这点。异步
一个任务，耗时估计的靠谱度跟作过这件事的次数有关，通常来讲作过两三次额估计就靠谱点。这也是有经验公式可用。若是它是一个广泛原理，咱们能够利用它。从几率上来讲，一个事情一次的成功率为a，那么，屡次以后的成功率是可计算的，手机打字就不展开了。能够验证，重试能够增长成功率。因此，不少事第一次作，能够预估会有失败和错误，因此失败和犯错时冷静的保存数据，证据，记录，探测的这些点，均可以用来在重试时作可能的规避。不过不少人只尝试了一次，这就回到了经典论述：写100个helloworld不如对一个程序迭代100次。固然，咱们要考虑到人是复杂的，喜新厌旧是常态，并不能一律而论。由于，每一个人都是独立的个体，选择的自由正是这种平均值。重试要注意两次之间是否收敛，若是不收敛，则重试只会致使队列堆积，甚至引发雪崩，此时要检查更深的问题。svn
我经常作过一件事之后，发现不少事情并不须要各类奇葩的创新点子之类。作着作着就会看到，作好一件事最须要的并非创新什么的，而是：概念界定以后的基本功。说概念界定，是由于不少人对本身的职业角色定位不清，就会致使作的事情不能抓住基本点。而一旦界定了角色边界，明确了基本点，那么工做就变成如何完美的把那些基本点作到位上面。例如，保持节奏，从不拖延，持续迭代，细节的完备，以及坚持不越界的作不该该本身作(你得让该作这件事的人去作，有原则对彼此都是一种轻松)。把基本功的细节作到位，就是一种职业素养，和专业主义。我想，这是重要的。我最怕角色不清，要么认为你应该什么都作，要么认为你什么都不要作，角色不清，系统的调度会混乱而没有效率。一我的能够作不一样的事情，但最好在角色的语义上区分之。函数
所以，我也以为不少事，其实能作到这些的人本身也均可以作好，未必得找别人。这和我经历过处处找控件来组装，到掌握组合控件的基本原理后不认为有魔法控件同样，省去了拿来主义。
当咱们预估，咱们会没有充裕的时间作完整的过程，咱们能够打时间差。咱们说对一个系统作性能优化，不外乎在时间和空间上作优化。若是一个系统或者一个过程要到达预期质量所要消耗的最低时间已经不可再压缩，而且预估到时间总体上将呈现下滑趋势，那么就应该在一开始时间还足够充裕的状况下打提早量，经过一开始的紧凑有序的节奏把大部分脚手架都搭建起来，那么越到后期越会从容和有条不紊，反之则会手忙脚乱。凡事预则立，不预则废。
相反的作法是，对事情作惰性求值，直到咱们真正须要一个事情的结果时，才会去作这件事，惰性求值有时候能最大限度减小当前要作的事情。可是，惰性求值至关于一次异步投递任务到队列的过程，队列里等待被作的事情会堆积，当须要在限定时间内求某个事情的结果时，队列可能已经雪崩了。因此有队列的地方就要防雪崩，队列不能过长（根据优先级丢弃），保证你的队列能够在最低粒度时间片内被有序求值。若是你不想你必需要作的事情被丢弃，那么那些事情能够经过打时间差提早作掉，达到超出预期的效果。再说异步任务，异步任务均可能因为各类缘由而不会有返回值，因此有异步就要有定时器，作超时监听，一旦超时，作对应的处理。
不管是10进制，仍是10进制，亦或是点分10进制。它们都是版本号。咱们的人生就是在年轮的版本之间迭代。认真对待每一个版本，麻雀虽小，五脏俱全。每一个版本开始，明确本次版本的目标，屏蔽其余，只指目标，当其达成，测试经过，打包，发布，写上：
版本 0.0.3
版本和版本之间，贵在持续，节奏均匀。版本的发布日志，就是一个diff。两个集合，A和B的对称差，就是发版的日志。这让我想起，从写程序到如今，在各类场合写过两个数组，区间列表等的diff。不少时候，咱们都在作diff，我经常从程序处理的过程获得一些概念，借以类比或者理解生活的事情，然而并不将其泛化，人太容易只看到类比事物之间共性的地方，而其实事物的复杂更在于那些不一样的地方。手里有一把锤子，就处处找钉子的事情，永远都有。
经典的生产者，消费者情景是这样的：
这样的过程，不断执行的任务，获取或者释放系统资源，而系统资源变化能够反馈到调度器的容许执行窗口，每一帧则从队列里取出窗口内的任务执行。
咱们说，这是一个拥塞控制。不作拥塞控制的状况下，在执行的任务可能太少而没有充分利用系统资源，或者在执行的任务太多而把系统资源竞争到卡死，不管怎样，系统的资源利用率最饱和和任务的执行最多，是一个优化目标。因此，一个健壮的系统，有队列的状况下，要作拥塞控制。
拥赛控制的核心法则是：多还少补，在慢启动、拥赛避免、快速恢复3个阶段来回切换。
从瀑布到敏捷，有的人说我是classical的，严格的瀑布有序经典；有的人说，我是删繁就简的，小步敏捷迭代，蚂蚁搬家。 就像我认为角色须要分开，人员能够合一。不管是学理上仍是实践上，过程的不一样阶段是存在的，可是具体实施上可能会压缩和合并。 Plan, Build,Test，基本的控制点在于这三者，侧重点各不相同。全局一次，仍是反复屡次，只是调度策略的不一样。 假设过程是一条插值曲线，那么分段插值曲线比全局插值曲线有更好的局部性，学过数值分析的应该都知道全局插值曲线在控制点多了以后，插值多项式的次数高，会有振荡现象，就是因为局部性很差。