2019-02-03Feature toggle（功能开关）分享两篇文章：
https://martinfowler.com/articles/feature-toggles.html
https://www.infoq.cn/article/function-switch-realize-better-continuous-implementations作者回复: 多谢补充！
14
2019-04-18又发现了几个任务分解都好处，
1. 让自己的工作可以被量化。
2. 可以加强对任务估算的能力。
3. 可以掌控项目的进度。
4. 每完成一组任务就可以提交一个 PR，这时就可以去休息一下。之前是一直坐到「天荒地老」...而且不知道任务什么时候完成，感觉自己做完了，想一想又有几点需要做...作者回复: 很高兴看到了你的进步！
9
2019-03-22看了这么多，忍不住发个言：这是我定过的所有极客专栏里 写的最有诚意、最有价值的一个！作者回复: 欢迎把它分享给你的朋友！
7
2019-01-30老师好, 关于基于主分支的策略上线流程是怎么样的, 假如两个人同时在开发两个功能, 并不断的进行小的粒度提交, 那其中一个人完成功能要上线的话, 另一个人的功能才完成一部分, 待主干中已经有他那没完成的任务的代码了, 是要一块发布吗作者回复: 这种问题的常见解决方案是Feature Toggle。
6- 2019-01-30很受启发 6
2019-11-07这世界很简单，忽视啥就在啥上面吃亏。
开发多年，潜移默化的，我习惯了在稳定的根基上构建代码，
重构，改善代码既有设计是本神书，推荐大家看看，里面套路包满满，例如代码意图与实现分离这句话，我在第一次看到时感受到了震撼，突然觉得自己之前写代码好sb.
然后随阅读量上升，当我看到这段文字时
An algorithm can be regarded as consisting of a logic component, which specifies the knowledge to be used in solving problems, and a control component, which determines the problem-solving strategies by means of which that knowledge is used. The logic component determines the meaning of the algorithm whereas the control component only affects its efficiency. The efficiency of an algorithm can often be improved by improving the control component without changing the logic of the algorithm. We argue that computer programs would be more often correct and more easily improved and modified if their logic and control aspects were identified and separated in the program text.
以及google 整理术后，更明白为啥要那样处理了。
不扯太远，话说回来，tdd 的精髓我认为就是任务细分和重构。而且很多时候重构就是为了更好的去理解和实现任务细分。形成更好的正向循环。并且每一步是建立在成功的根基上。
然而此事还可以继续再横向迁移一下。
一个计划能稳定可保障的执行，靠的就是合适粒度的分解。（放心，我们平时都分的过粗了，分的不适合我们的大脑高效工作了）
我自己是马拉松爱好者，更深知步子迈大了对跑全马来说意味者什么，更别提大铁，巨人，utmb（utmb 是我此生的梦想）了
高强度上班一天好累，本想早点睡觉，奈何点错了专栏，大脑被作者的内容给搞兴奋了，又一次没控制住自己，最后还是想说非常感谢，读好的文章是一种享受，灵魂在被洗礼的感觉，谢谢展开 2
2019-01-30任务分解也是我目前最想做好的，也是最无从下手的，概念都懂，做起来吃力，即使做一份分解清单出来，也不知道是不是好的。因为现在也在带团队做项目，所以对做任务分解的重要性深有体会，现在尝试让所有人在思维认知上有变化，一步步去实操微操作级别的任务分解，学好这些软技能才能快速成长为大牛级的人物。而所有问题中最大最迫切的问题是如何能快速合理的做任务分解，得到任务清单，希望老师能多拿些实际需求来讲解下如何分解出合理的任务清单，是否可以在后面的章节中留些任务分解的作业，实践后老师给一些指正作者回复: 稍安勿躁，下一讲，我就带着大家做一次任务分解，先体会一下分解可以做到什么程度。
2- 2019-03-22想起某个广告词，每天一小步，向上走就是新高度。小步快跑是关键 1
2019-01-31对任务分解的体会非常深刻，刚入职的时候任务评估不准。现在想想主要是两个原因：1、需求梳理的不清晰，还没清楚地搞明白需求就动手写代码，导致返工、导致一些“意想不到”的情况。2、任务分解做的不好，没有将任务分解成非常清晰地可执行的单元，导致有些时候无从下手，而且任务时间评估不准确。 1- 2019-01-31听了老师的音频讲解，有种醍醐灌顶的感觉，很多以前没有想明白的问题，都得到了答案，感谢！
编辑回复: 加油💪
1 
2019-01-30刚刚做完2018年项目的复盘，其中很重要的一个教训就是拆解不细致。依赖供应商的系统，而他们习惯于完成全部接口开发后才对接交付，结果其他依赖于此的系统迟迟不能交付，这段时间业务方增加很多工作量不说，等完成上线才发现移动端体验距离我们习惯差很远，再加上其他问题，导致供应商项目暂停。幸好之前有预见，提前做了二手准备，才不至于项目整体失败。没有做细致的推演，没有做细致的拆分和迭代交付，道理容易懂，但教训仍然要自己品尝才会深刻作者回复: 你已经能理解任务分解的价值，缺少的就是分解得小，拆小才能对任务有更深的理解。
1
2020-02-08老师请教个问题，传统的项目型公司，一个客户一个项目但是都是基于同一个产品的，那么是否适合用一个分支的模式，还是不同项目不同分支呢？
2019-08-24极客时间里，我买了二十门课了，这是第一门我看得欲罢不能的课程，思路连贯清晰，看完让人惊叹。这么普通的主题讲的这么高水准确实不易。
2019-08-04“如果不能很好地分解，那说明我还没想清楚，还需要更多信息，或者需要找到更好的解决方案。” 那么怎么样快速想清楚一个问题呢，想清楚这个过程是否也可以做任务分解
2019-07-02任务分解得不够小带来的问题，比如接到一个需求，就马上动手，没有进行任务分解，或者凭感觉任务分解。
2019-06-11“在我的实际工作中，我带的团队基本上都会采用基于主分支的策略。“，這難道不嘲讽吗？口口声声说任务 越细越好，最后却选择主分支吞噬了小心翼翼呵护出来的“小”。。。
为什么不把任务的小执行透彻？
从头到尾强调小，最后却选择主干，难道值得骄傲？展开
2019-05-16讲任务原子化，拆分的越小，越容易做到- 2019-05-09Feature Toggle 并不算一个好的解决方案. 我们使用的是频繁的分支合并. 每次 master 分支有提交会自动向其他分支合并, 这样有冲突就可以第一时间发现了.
作者回复: 这取决于你怎么定义“频繁”，如果真的能够每天都提交，分支也可以接受，但如果真能每天都提交，你还会开分支吗？
2019-03-10baby step~
主干分支用着委实不错。但有几个点，一个是在已用线上产品的时候，我们通常会有一条release分支。这样当有线上bug出现的时候，我们能在release分支上快速修复 + 上线。
另外一个是，在规律性的迭代上线时，难免会遇到有story没有完成(开发或者测试)，此时，就得使用feature toggle 或者 revert代码了。
最后是当在做一个很明显上线前不可能完成的大feature的时候，一般我们会启另一条分支来开发。此时会定时从主分支merge代码，因为有些改动可能会影响已用的业务
2019-03-08任务足够小的操作也方便切换 这个思路不错