目录
前言:
本篇博客内容来源自:极客时间课程《10x程序员工作法》处于学习记录。将个人认为比较重要的知识点进行摘抄记录。有兴趣的同学去极客时间学习完整课程。
一、高效程序员的思考框架
思考框架:
- 我现在是个什么水平?
- 我想达到一个什么水平?
- 我将怎样到达那个目标?
这三个问题实际上是帮我们确定:
- 现状;
- 目标;
- 实现路径。
四个思考原则:
以终为始:
就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目标,而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中,Where are we going?(我们要到哪儿去?)这个问题。
任务分解;
是将大目标拆分成一个一个可行的执行任务,工作分解得越细致,我们便越能更好地掌控工作,它是帮助我们回答思维框架中,How can we get there?(我们如何到达那里?)的问题。
沟通反馈;
是为了疏通与其他人交互的渠道。一方面,我们保证信息能够传达出去,减少因为理解偏差造成的工作疏漏;另一方面,也要保证我们能够准确接收外部信息,以免因为自我感觉良好,阻碍了进步。
自动化:
就是将繁琐的工作通过自动化的方式交给机器执行,这是我们程序员本职工作的一部分,我们擅长的是为其他人打造自动化的服务,但自己的工作却应用得不够,这也是我们工作中最值得优化的部分。
一句话总结:
面对问题时,用思考框架问问自己,现状、目标和路径。
二、 以终为始:如何让你的努力不白费?
- 我们习以为常的思维模式是线性而顺序的,第一步做完,做第二步;第二步做完,做第三步。
- “以终为始”的方式,不仅仅可以帮我们规划工作,还可以帮我们发现工作中的问题。
- 践行“以终为始”就是在做事之前,先考虑结果,根据结果来确定要做的事情。
- “以终为始”的思维可以帮助我们更好地规划我们手头任务,也可以帮助我们发现过程中的问题。
一句话总结:
遇到事情,倒着想。
三、 DoD的价值:你完成了工作,为什么他们还不满意?
DoD 是一个清单,清单是由一个个的检查项组成的,用来检查我们的工作完成情况。DoD 的检查项,就是我们开发产品所需的一系列有价值的活动。比如:编写代码、编写测试代码、通过测试人员验收等。什么样的活动是有价值的,也许每个团队的认识是不同的。但如果你的团队认为除了功能代码,其他都没价值,也许这是个信号,说明你的团队整体上是缺乏职业素养的,在这样的团队工作,前景并不乐观。
DoD 的检查项应该是实际可检查的。你说代码写好了,代码在哪里;你说测试覆盖率达标了,怎么看到;你说你功能做好了,演示一下。
DoD 是团队成员间彼此汇报的一种机制。别把“汇报”想复杂了,最简单的汇报就是说一句“这个功能做完了”。当我们有了 DoD,做事只有两种状态,即“做完”和“没做完”。在团队协作中,我们经常会听到有人说“这个事做完了 80%”,对不起,那叫没做完,根本没有 80% 做完的说法。
你应该知道,人与人协作,总会有这样或那样的理解差异。开始协作之前,我们最好先同步一下彼此的理解,确保之后不会因为理解不一致,而让协作方措手不及。怎样解决大家的理解偏差呢,我介绍了 DoD(完成的定义),它是行业中的一种最佳实践,能够在团队内部很好地同步大家对“完成”的理解。好的 DoD 是一个可以检查的清单,可以确保你不遗漏任何事情。
一句话总结:
在做任何事之前,先定义完成的标准。
四、 接到需求任务,你要先做哪件事?
我们把“以终为始”的原则应用在需求领域中,就会注意到,用户故事有一个非常重要的组成部分是验收标准。
验收标准不仅仅描述出了正常流程,也会关注到异常流程的处理,它也是我们验收测试用例的起点。一旦事先定义好验收标准,大量的扯皮工作就随之烟消云散了。
理解了验收标准的作用,即便我们不使用用户故事来定义需求,依然可以把用户故事中的关键点应用到自己的实践中,在功能列表的每个功能定义中,增加验收标准。
一句话总结:
在做任何需求或任务之前,先定好验收标准。
五、持续集成:集成本身就是写代码的一个环节
写代码是程序员的职责,但我们更有义务交付一个可运行的软件。
如果想将每个程序员编写的代码很好地组合在一起,我们就必须做一件事:集成。
究竟要在开发后多久才进行一次集成呢?是半天、两个小时、还是一个小时呢?倘若这个想法推演到极致,是否就变成了只要有代码提交,就去做集成?
一个好的做法是尽早把代码和已有代码集成到一起,而不应该等着所有代码都开发完了,再去做提交。
一句话总结:
尽早提交代码去集成。