# 在成为高效程序员的路上

# 前言

一个好的程序员的工作效率是普通程序员的10倍。你要有一个认识:我们所遇到的问题,大多不是程序问题

软件行业里有一本名著叫《人月神话》,其中提到两个非常重要的概念:本质复杂度(Essential Complexity)和偶然复杂度(Accident Complexity)。大部分程序员忙碌解决的问题,都不是程序问题,而是由偶然复杂度导致的问题 。那么我们如何减少偶然复杂度引发的问题,让软件开发工作有序、高效地进行?

  • 你需要一个思考框架
    • Where are we?(我们现在在哪?) 现状
    • Where are we going?(我们要到哪儿去?) 目标
    • **How can we get there?(我们如何到达那里?) ** 实现路径
  • 你需要四个思考原则
    • 以终为始任务分解沟通反馈自动化

# 以终为始

  • 遇到事情,倒着想

任何事物都要经过两次创造:一次是在头脑中的创造,也就是智力上的或者第一次创造(Mental/First Creation),然后才是付诸实践,也就是实际的构建或第二次创造(Physical/Second Creation)

对做软件的人来说,我们应该把“终”定位成做一个对用户有价值的软件

践行“以终为始”就是在做事之前,先考虑结果,根据结果来确定要做的事情

  • 在做任何事之前,先定义完成的标准

DoD(Definition of Done,完成的定义)

  • DoD 是一个清单,清单是由一个个的检查项组成的,用来检查我们的工作完成情况。
  • DoD 的检查项应该是实际可检查的。
  • DoD 是团队成员间彼此汇报的一种机制。 当我们有了 DoD,做事只有两种状态,即“做完”和“没做 完”。

站在 DoD 的肩膀上

  • 它不仅局限在团队内部协作上,如果你可以放开思路,会发现 DoD 的思维在工作中用途非常广泛。 .
  • DoD 是一个的思维模式,是一种尽可能消除不确定性,达成共识的方式。
  • 在做任何需求或任务之前,先定好验收标准

    功能列表式的需求描述方式,将一个完整的需求敲成了碎片。

    验收标准非常重要的一环是异常流程的描述。 验收标准给出了这个需求最基本的测试用例,它保证了开发人员完成需求最基本的质量。

    如果你的团队采用用户故事的格式进行需求描述固然好,如果不能,在功能列表中,补充验 收标准也会极大程度地改善双方协作的效率。

  • 尽早提交代码去集成

    写代码是程序员的职责,但我们更有义务交付一个可运行的软件。

  • 默认所有需求都不做,直到弄清楚为什么要做这件事

    我们必须要有自己的独立思考,多问几个为什么,尽可能减少掉到“坑”里之后再求救的次数

    软件开发的主流由面向确定性问题,逐渐变成了面向不确定性问题。

    精益创业 : 它要解决的是面向不确定性创造新事物 ,既然是不确定的,那你唯一能做的事情就是“试”。

    精益创业的方法论里,提出“开发(build)- 测量(measure)- 认知(learn)”这样一个反馈循环。

    精益创业提供给我们的是一个做产品的思考框架,我们能够接触到的大多数产品都可以放在这个框架内思考。

  • 扩大自己工作的上下文,别把自己局限在一个“程序员”的角色上

    “独善其身”不是好事

    不同角色工作上真正的差异是上下文的不同。 虽然写的代码都一样,但你看到的是树木,人家看到的是森林,他更能从全局思考。能想到某些问题,前提就是要跳出程序员角色思维,扩大自己工作的上下文

    当你对软件开发的全生命周期都有了认识之后,你看到的就不再是一个点了,而是一条线。争取在更大的上下文工作

  • 在动手做一件事之前,先推演一番

    通向结果的路径才是更重要的。对比我们的工作,多数情况下,即便目标清晰,路径却是模糊的

    在军事上,人们将其称为沙盘推演,或沙盘模拟

  • 问一下自己,我的工作是不是可以用数字衡量

    一些人说,自己靠直觉就能把事情做好,其实这是一种误解,因为那种所谓的直觉,通常是一种洞见(Insight),洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累,而这其实是某种意义上的大数据

    而当事情复杂到一定程度时,简单地靠感觉是很难让人相信的。 从数字中发现问题,让系统更稳定。

    基于数据进行技术决策、预先设定系统指标,以及发现系统中的问题

  • 设计你的迭代 0 清单,给自己的项目做体检

    这里给出的迭代 0,它的具体内容只是基本的清单

    需求方面:细化过的迭代 1 需求 、用户界面和用户交互

    技术方面:基本技术准备 、发布准备

    把测试当作规范确定下来的办法就是把测试覆盖率加入构建脚本。

    image-20200623154857109

# 任务分解

  • 动手做一个工作之前,请先对它进行任务分解

    正是通过将宏大目标进行任务分解,马斯克才能将一个看似不着边际的目标向前推进。

    一个大问题,我们都很难给出答案,但回答小问题却是我们擅长的。

    那么,用这种思路解决问题的难点是什么呢?给出一个可执行的分解

    与很多实践相反,任务分解是一个知难行易的过程。

    不同的可执行定义差别在于,你是否能清楚地知道这个问题该如何解决。

    如今软件行业都在提倡拥抱变化,而任务分解是我们拥抱变化的前提。

  • 多写单元测试

    对于每个程序员来说,只有在开发阶段把代码和测试都写好,才有资格说,自己交付的是高质量的代码。

    自动化测试:

    • 测试框架最大的价值,是把自动化测试作为一种最佳实践引入到开发过程中,使得测试 动作可以通过标准化的手段固定下来

    • 测试模型:蛋卷与金字塔

      image-20200623160331971
    • 测试模型:测试金字塔

      image-20200623160408621

    越是底层的测试,牵扯到相关内容越少,而高层测试则涉及面更广。

    小事反馈周期短,而大事反馈周期长 。虽然冰淇淋蛋卷更符合直觉,但测试金字塔才是行业的最佳实践

  • 我们应该编写可测的代码

    测试驱动开发(Test Driven Development)

    image-20200623160703840

    测试先行开发和测试驱动开发的差异就在重构上,因为重构和测试的互相配合,它会驱动着你把代码写得越来越好。这是对“驱动”一词最粗浅的理解

    测试驱动设计 :由测试驱动代码的编写。

    我的代码怎么写才是能测试的,也就是说,我们要编写具有可测试性的代码。 写代码之前,请先想想怎么测 。

  • 将任务拆小越小越好

    Kent Beck 的做法清晰而有节奏,每个任务完成之后,代码都是可以提交的。

    大多数程序员之所以开发效率低,很多时候是没想清楚就动手了。

    很多人看了一些 TDD 的练习觉得很简单,但自己动起手来却不知道如何下手。中间就是缺了任务分解的环节。

    如果你有了一个微习惯,坚持就不难了。

    一个经过分解后的任务,需要关注的内容是有限的,我们就可以针对着这个任务,把方方面面的细节想得更加清晰。

  • 按照完整实现一个需求的顺序去安排分解出来的任务

    很多人可能更习惯一个类一个类的写,我要说,最好按照一个需求、一个需求的过程走,这样,任务是可以随时停下来的。

    检验每个任务项是否拆分到位,就是看你是否知道它应该怎么做了

    每做完一个任务,代码都是可以提交的,按照完整实现一个需求的顺序去安排分解出来的任务

  • 要想写好测试,就要写简单的测试

    为什么你的测试不够好呢? 主要是因为这些测试不够简单。只有将复杂的测试拆分成简单的测试,测试才有可能做好

    把测试写简单,简单到一目了然,不需要证明它的正确性。

    一般测试要具备的四段: 前置准备、执行、断言和清理

    一段旅程(A-TRIP) (编写可测试的代码 )

    • Automatic,自动化;
    • Thorough,全面的; 应该尽可能用测试覆盖各种场景
    • Repeatable,可重复的;
    • Independent,独立的
    • Professional,专业的
  • 想要管理好需求,先把需求拆小

    基本上,闯入你脑海的需求描述是主题(epic),在敏捷开发中,有人称之为主用户故事(master story)。

    绝大多数问题都是由于分解的粒度太大造成的,少有因为粒度太小而出问题的。

    评价用户故事有一个“ INVEST 原则”

    Independent,独立的 、Negotiable,可协商的 、Valuable,有价值的 、Estimatable,可估算的、 Small,小 、Testable,可测试的

    用户故事,之所以是故事,就是要讲,要沟通

    估算的结果是相对的,不是绝对精确的,我们不必像做科研一样,只要给出一个相对估算就好

    一般来说,估算的过程也是大家加深对需求理解的过程

  • 尽量做最重要的事

    按照时间管理的理念,重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情,可以委托别人做。不重要不紧急的事情,尽量少做。

    如果不把精力放在重要的事情上,到最后可能都变成紧急的事情。

    当员工想不明白的事,换成老板的视角就全明白了 。

  • 做好产品开发,最可行的方式是采用MVP

    精益创业就是通过不断地尝试在真实世界中验证产品想法,其中一个重要的实践是最小可行产品(Minimum Viable Product,MVP)。 我们要做的是验证一个想法的可行性,甚至不是为了开发一个软件,开发软件只是一种验证手段

    可行的路径不是一个模块做得有多完整,而一条用户路径是否通畅

    当时间有限时,我们需要学会找到一条可行的路径,在完整用户体验和完整系统之间,找到一个平衡

# 沟通反馈

# 自动化

# 综合运用

评 论: