在成为高效程序员的路上


在成为高效程序员的路上

前言

一个好的程序员的工作效率是普通程序员的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

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

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

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

将任务拆小,越小越好

每个任务完成之后,代码都是可以提交的。

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Automatic,自动化;
  • Thorough,全面的; 应该尽可能用测试覆盖各种场景
  • Repeatable,可重复的;
  • Independent,独立的
  • Professional,专业的

想要管理好需求,先把需求拆小

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

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

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

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

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

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

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

尽量做最重要的事

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

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

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

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

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

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

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

面对不了解的技术,我该如何分解任务?

答案很简单,先把它变成你熟悉的技术。一旦变成了你熟悉的技术,你就可以应用在这个模块中学到的,面对确定性技术的分解方案。 怎么把它变成你熟悉的技术 ,做一次技术 Spike

Spike 的作用就在于消除不确定性,让项目经 理知道这里要用到一项全团队没有人懂的技术,需要花时间弄清楚。

大概了解这项技术是干什么的了,我们要进行技术 Spike 的任务分解

技术最终是要应用到项目中的,本着“以终为始”的原则,我们就应该奔着结果做,整个的Spike 都应该围绕着最终的目标做。
很多程序员见到新技术都容易很兴奋,会把所有的文档通读一遍。如果是技术学习,这种做法无可厚非,但我们的目标是做 Spike,快速地试,没有那么多时间,必须一切围绕结果来。 其目的就是为了防止发散。当时间有限时,我们只能做最重要的事。当你确定要使用这项技术时,请丢弃掉你的原型代码

项目时间紧,该怎么办?

假设现在不忙了,你知道该怎么改进吗?

改进过程:

把测试覆盖率检查加入到工程里,得到现有的测试覆盖率。
将测试覆盖率加入持续集成,设定当前测试覆盖率为初始值。测试覆盖率不达标,不许提交代码。
每周将测试覆盖率调高,比如,5% 或 10%,直到测试覆盖率达到 100%。

SpringBoot项目中简单易用的测试覆盖率检查工具:jacoco

多个功能同时开发,怎么办?

沟通反馈

为什么世界和你的理解不一样

《大富翁》里的沙隆巴斯有句口头禅:人生不如意,十之八九!

我们努力地学习各种知识,为的就是更好地理解这个世界的运作方式,而沟通反馈,就是我们与真实世界互动的最好方式。

香农信息论中的一个通信模型

几个要素 :

  • 信源(Information Source),它负责产生信息(Message)
  • 发送器(Transmitter),它会对信息进行某些操作,也就是对信息编码,产生信号(Signal)
  • 信道(Channel),它是信号传送的媒介
  • 接收器(Receiver),它是对信号执行发送器的逆操作,解码信号,提取出信息
  • 信宿(Destination),它负责接收信息。
  • 噪声(Noise),指的是削弱信号的东西

理解偏差是怎么产生的?

项目经理给你传输的信号是“完成一个需求”,在项目经理脑子中,这个信号的原始信息可能是这样的:编写完成这个功能所需的代码,然后为这段代码写好自动化测试,再将它与现有系统集成好,通过测试人员的验证。你从“完成一个需求”这个信号中解码出来的信息却是:把功能代码写完。这样,问题就出现了。即便这里忽略了噪声的干扰,当编码和解码不是一个版本的时候,无论如何,项目经理的信息都很难准确地传达到你这里。

**信息的传达要经过编码和解码两个过程,无论是编码出现问题,还是解码出现问题,都会造成信息的不准确。因为每个人经历见识的差异,造成了各自编解码器的差异。 **

很多程序员讲东西的通病:讲东西直奔细节,而忽略背景

编解码器算法,也就是怎么协调沟通双方更有效地进行沟通。 通过制定“完成的定义”就可以帮助改善这个过程。这就相当于,沟通的双方都有了一个编解码手册。 通过沟通反馈,不断升级自己的编解码能力

你的代码为谁而写

image-20200909203113799

深入剖析怎样才能写出可维护的代码,这件事就是命名

计算机科学中只有两大难题:缓存失效和命名。
—— Phil Karlton

名字起得是否够好,一个简单的评判标准是,拿着代码给人讲,你需要额外解释多少东西。

任何人都能写出计算机能够理解的代码,只有好程序员才能写出人能够理解的代码。
—— Martin Fowler

我们写代码的目的是与人沟通,因为我们要在一个团队里与人协同工作。人要负责将业务问题和机器执行连接起来,缺少了业务背景是不可能写出好代码的。 虽然只是一个简单的名字修改,但从理解上,这是一步巨大的跨越,缩短了其他人理解这段代码所需填补的鸿沟,工作效率自然会得到提高。

如果了解领域驱动设计(Domain Driven Design,DDD),把不同的概念分解出来,这其实是限界上下文
(Bounded Context)的作用,而在代码里尽可能使用业务语言,这是通用语言(Ubiquitous Language)的作用

轻量级沟通:你总是在开会吗

开会是为了解决问题,但真实情况却是开了会又没有解决多少问题,这真是一个奇特的矛盾。 凡是效果特别好的会议,基本上都是用来做信息同步的。

开会是一种重量级的沟通,几乎是我们日常工作中最重的。它有很强的仪式感,所以,大家相对来说会很重视。而且会议通常会牵扯到很多人,尤其是与这个事情相关度不那么高的人。所以,改善会议的第一个行动项是,减少参与讨论的人数。 相比于会议的形式,面对面沟通因为注意力有限,参与的人数不可能太多。也因为参与的人数相对少一些,每个人的投入也会更多一些。

我们的第二个行动项是,如果你要讨论,找人面对面沟通。

有一种实践叫站会(Standup)

只说三件事:

我昨天做了什么?是为了与其他人同步进展,看事情是否在计划上。一旦偏离计划,请主动
把它提出,这样,项目经理可以过问,因为这会涉及到是否要调整项目计划;
我今天打算做什么?是同步你接下来的工作安排。如果涉及到与其他人协作,也就是告诉大
家,让他们有个配合的心理准备;
我在过程中遇到了什么问题,需要请求帮助。 就是与其他人的协作,表示:我遇到不懂的问题,你们有信息的话,可以给我提供一下

亚马逊的员工会议——拒绝使用 PPT

可视化:一种更为直观的沟通方式

作为一个程序员,在这个技术快速发展的时代,我们唯有不断学习,才能保证自己不为时代所抛弃。那你是怎么跟上技术发展步伐的呢?

ThoughtWorks 技术雷达 是由 ThoughtWorks 技术咨询委员会(Technology AdvisoryBoard)编写的一份技术趋势报告,每 6 个月发布一次。ThoughtWorks 的项目多样性足够丰富,所以它能够发现诸多技术趋势。因此,相比于行业中其它的预测报告,技术雷达更加具体,更具可操作性。

image-20200909214536448

技术雷达用来追踪技术,在雷达图的术语里,每一项技术表示为一个 blip,也就是雷达上的一个光点。然后用两个分类元素组织这些 blip:象限(quadrant)和圆环(ring),其中,象限表示一个 blip 的种类,目前有四个种类:技术、平台、工具,还有语言与框架。 圆环表示技术一个 blip 在技术采纳生命周期中所处的阶段,目前这个生命周期包含四个阶段:采用(Adopt)、试验(Trial)、评估(Assess)和暂缓(Hold)。

“采用”表示强烈推荐,我会去对比一下自己在实际应用中是否用到了,比如,在 2018 年11 月的技术雷达中,事件风暴(Event Storming)放到了“采用”中,如果你还不了解事件风暴 是什么,强烈建议你点击链接了解一下。

“暂缓” 则表示新项目别再用这项技术了,这会给我提个醒,这项技术可能已经有了更优秀的替代品,比如,Java 世界中最常见的构建工具 Maven 很早就放到了“暂缓”项中,但时至今日,很多人启动新项目依然会选择 Maven,多半这些人并不了解技术趋势。

雷达图是一种很好的将知识分类组织的形式,它可以让你一目了然地看到并了解所有知识点,并根据自己的需要,决定是否深入了解。

读书雷达

构建技术雷达

构建雷达的程序库

就人脑的进化而言,处理图像的速度远远快于处理文字 , 将“可视化”应用在工作中的典型案例:看板。看板,是一种项目管理工具,它将我们正在进行的工作变得可视化。

image-20200909215830120

快速反馈:为什么你们公司总是做不好持续集成?

你对持续集成的第一印象是什么?
持续集成?Jenkins?没错,很多人对持续集成第一印象都是持续集成服务器,也就是 CI服务器,当年是 CruiseControl,今天换成了 Jenkins。 很多人就把 CI 服务器理解成了持续集成。我就曾经接触过这样的团队,
他们恨不得把所有的事情都放在 CI 服务器上做:在 CI 服务器上做了编译,跑了代码检查,运行了单元测试,做了测试覆盖率的统计等等。 这种做法是可行的,但它不是最佳实践。我希望你去思考,有没有比这更好的做法呢?

想要做好持续集成,就需要顺应持续集成的本质:尽快得到工作反馈。

持续集成的两个重要目标:

  • 怎样快速地得到反馈
  • 以及什么样的反馈是有效的

执行同样的操作,本地环境会快于 CI 服务器环境。

image-20200910183940158

image-20200910184136058

只有 CI 服务器处于绿色的状态才能提交代码。 所有不能把检查只放到 CI 服务器上执行 。用好本地构建脚本(build script),保证各种各样的检查都可以在本地环境执行

image-20200910184611849

我们一般通过CI监视器来获取有效反馈CI 监视器的示例 projectmonitor
怎么呈现是有效的? 答案很简单:怎么引人注目,怎么呈现
持续集成的纪律:CI 服务器一旦检查出错,要立即修复

image-20200910184930328

开发中的问题一再出现,应该怎么办?

如果在开发过程中,同样的问题反复出现,说明你的团队没有做好复盘。

定期复盘,找准问题根因,不断改善。

什么是复盘?

复盘,原本是一个围棋术语,就是对弈者下完一盘棋之后,重新把对弈过程摆一遍,看看哪些地方下得好,哪些下得不好,哪些地方可以有不同甚至是更好的下法等等。这种把过程还原,进行研讨与分析的方式,就是复盘。

什么是客体化?

为什么复盘这么好用呢?在我看来有一个重要的原因,在于客体化。 用别人的视角看问题,这就是客体化。

回顾会议是一个常见的复盘实践,定期回顾是一个团队自我改善的前提。

先在白板上给出一个主题分类。我常用的是分成三类:“做得好的、做得欠佳的、问题或建议”。 还有不同的主题分类方式,比如海星图,分成了五大类:“继续保持、开始做、停止做、多做一些、少做一些”五类。 给与会者五分钟时间,针对这个开发周期内团队的表现,按照分类在便签上写下一些事实。比如,你认为做得好的是按时交付了,做得不好的是 Bug 太多。 两个重点。一个是写事实,不要写感受。 另外,每张便签只写一条,因为后面我要对便签归类。

所有给出的行动项应该都是可检查的,而不是一些无法验证的内容。 列好了一个个的行动项,接下来就是找责任人了,责任人要对行动项负责。

5个为什么来解决复盘问题

“5 个为什么”中的“5”只是一个参考数字,不是目标。

举个例子。服务器经常返回 504,那我们可以采用“5 个为什么”的方式来问一下。

为什么会出现 504 呢?因为服务器处理时间比较长,超时了。
为什么会超时呢?因为服务器查询后面的 Redis 卡住了。
为什么访问 Redis 会卡住呢?因为另外一个更新 Redis 的服务删除了大批量的数据,然后,重新插入,服务器阻塞了。
为什么它要大批量的删除数据重新插入呢?因为更新算法设计得不合理。
为什么一个设计得不合理的算法就能上线呢?因为这个设计没有按照流程进行评审。

作为程序员,你也应该聆听用户声音

怎么判断产品经理说的产品特性是不是用户真的需要的呢? 采用用户视角,你需要来自真实世界的反馈。

而作为一个程序员,欠缺用户视角,在与产品经理的交流中,你是不可能有机会的,因为他很容易用一句话就把你打败:“这就是用户需求。” 由听产品经理的话,扩大成倾听用户的声音。

不断使用自家的产品,会让你多出一个用户的视角。

尽早暴露问题: 为什么被指责的总是你?

发现问题的是不要选择了继续埋头苦干,直到经理询问,才把问题暴露出来不是所有的问题,都是值得解决的技术难题 遇到问题,最好的解决方案是尽早把问题暴露出来。

写程序有一个重要的原则叫 Fail Fast 意思就是如果遇到问题,尽早报错。 例如:参数校验、配置参数等第一时间抛出异常

结构化:写文档也是一种学习方式

很多人回避写文档的真正原因是,他掌握的内容不能很好地结构化。 将零散的知识结构化,有很多种方式,但输出是非常关键的一环。 输出的过程,本质上就是把知识连接起来的过程。 多输出,让知识更有结构。

金字塔理论

持续集成,一条贯穿诸多实践的主线

单元测试做不好,是否会影响到 CI 的效果?

持续集成的价值在于,它是一条主线,可以将诸多实践贯穿起来。也就是说,想要真正意义上做好持续集成,需要把周边的很多实践都要做好。做好持续集成的关键是,快速反馈。

比如,我们想要做好 CI,需要有一个稳定的开发分支,所以,最好采用主开发分支的方式。想用好主分支开发,最好能够频繁提交;而频繁提交需要你的任务足够小,能够快速完成;将任务拆解的足够小,需要你真正懂得任务分解。要想在一个分支上开发多个功能,那就需要用 Feature Toggle 或者 Branch by Abstraction。

image-20200912142101091

在这条线上,你有很多机会走错路。比如,你选择了分支开发模式,合并速度就不会太快,一旦反馈快不了,CI 的作用就会降低;再者,如果不能频繁提交,每次合并代码的周期就会变长,一旦合并代码的周期变长,人们就会倾向于少做麻烦事,也就会进一步降低提交的频率,恶性循环就此开启。同样,即便你懂得了前面的道理,不懂任务分解,想频繁提交,也是心有余而力不足的。而多功能并行开发,则会让你情不自禁地想考虑使用多分支模型。

想做好 CI,首先要有可检查的东西,什么是可检查的东西,最简单的就是编译、代码风格检查,这些检查可以无条件加入构建脚本。但更重要的检查,应该来自于测试,而要想做好 CI,我们要有测试防护网。

image-20200912142115793

什么叫测试防护网呢?就是你的测试要能给你提供一个足够安全的保障,这也就意味着你要有足够多的测试。换个更技术点的术语来说,就是要有足够高的测试覆盖率。

如果测试覆盖率不够,即便提交了代码,CI 都通过了,你对自己的代码依然是没有信心的,这就会降低 CI 在你的心中的地位。如果想有足够高的测试覆盖率,你就要多写单元测试。我们在前面讲过测试金字塔了,上层测试因为很麻烦,你不会写太多,而且很多边界条件,通过上层测试是覆盖不到的,所以,测试覆盖率在经过了初期的快速提升后,到后期无论如何是提上不去的。要想提升测试覆盖率,唯有多写单元测试。所以,CI 作为一个单独的实践,本身是很简单的,但它可以成为提纲挈领的主线,帮助团队不断改善自己的开发过程。

自动化

“懒惰”应该是所有程序员的骄傲

Larry Wall 一个经典叙述:优秀程序员应该有三大美德:懒惰、急躁和傲慢(Laziness, Impatience and hubris)。

做有价值的事是重要的,这里面的有价值,不仅仅是“做”了什么,通过“不做”节省时间和成本也是有价值的

NIH 综合症(Not Invented Here Syndrome)。就是有人特别看不上别人做的东西,非要自己做出一套来,原因只是因为那个东西不是我做的,可能存在各种问题。

你的日常工作是给别人打造自动化,但你自己的工作够自动化吗? 你要懂得软件设计,大多数人都是混淆了设计和实现。**在软件开发中,其它的东西都是易变的,唯有设计的可变性是你可以控制的。**

一个好的项目自动化应该是什么样子的?

这里我采用的 Java 技术中最为常见的 Spring Boot 作为基础框架,而构建工具,我选择了 Gradle

我们先来了解一点 Gradle 的配置文件,它也是我们做项目自动化的重点。(分模块构建项目)

  • build.gradle,它是 Gradle 的配置文件。因为 Gradle 是由 Groovy 编写而成,build.gradle 本质上就是一个 Groovy 的脚本,其中的配置就是 Groovy 代码,这也是 Gradle 能够灵活订制的基础。
  • settings.gradle,这也是一个 Gradle 配置文件,用以支持多模块。如果说一个项目的每个模块都可以有一个 build.gradle,那整个项目只有一个 settings.gradle。

在自动化过程中,一个最基本的工作是检查。检查的工作在我们的项目中通过一个 check 任务来执行。

  • 最基本的代码风格检查要放在构建脚本中,你只要应用 Checkstyle 插件即可。可以做一些订制,比如,指定某些文件可以不做检查。
  • 测试覆盖率也应该加入到构建脚本中,只要应用 JaCoCo 插件即可。可以做一些订制,比如,生成结果的 HTML 报表,还有可以忽略某些文件不做检查。

我还提到了数据库迁移,也就是怎样修改数据库。我选择的数据库迁移工具是Flyway

做好了最基本的检查,数据库也准备就绪,接下来,我们就应该构建我们的应用了

一个最基本的项目自动化,包括了:

  • 生成 IDE 工程;
  • 编译;
  • 打包;
  • 运行测试;
  • 代码风格检查;
  • 测试覆盖率;
  • 数据库迁移;
  • 运行应用。

程序员怎么学习运维知识?

有体系地学习运维知识

image-20200912145306066

持续交付:有持续集成就够了吗?

持续交付

DevOps

如何做好验收测试?

验收测试

行为驱动开发

写好验收测试用例

你的代码是怎么变混乱的?

逐步腐化的代码

SOLID 原则

单一职责原则

编写短函数

总是在说MVC分层架构,但你真的理解分层吗?

设计上的分解

无处不在的分层

有抽象有发展

构建你的抽象

为什么总有人觉得5万块钱可以做一个淘宝?

淘宝的发展历程

同样的业务,不同的系统

你用对技术了吗?

先做好DDD再谈微服务吧,那只是一种部署形式

微服务

领域驱动设计

走向微服务

综合运用


文章作者: 韩思远
版权声明: 本博客所有文章除特別声明外,均采用 CC BY 4.0 许可协议。转载请注明来源 韩思远 !
评论
 上一篇
MySQL实战-基础篇 MySQL实战-基础篇
MySQL实战-基础篇一、一条SQL查询语句是如何执行的?执行如下SQL,我们看到的只是输入一条语句,返回一个结果,却不知道这条语句在 MySQL 内部的执行过程。 select * from T where ID=10; 我们一起来看
2020-09-08
下一篇 
技术基础 技术基础
技术基础 洞悉技术的本质,享受科技的乐趣 https://coolshell.cn/ 程序员如何用技术变现 程序员用自己的技术变现,其实是一件天经地义的事儿。写程序是一门“手艺活儿”,那么作为手艺人,程序员当然可以做到靠自己的手艺和技能养
2020-08-31
  目录