程序员工作法
文章平均质量分 90
程序员工作法
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
特别加餐 | ChatGPT来了,你的编程效率提高了吗?
今天,我们讨论了程序员在开发效率上的提升是怎样一路走过来的,我们从命令行和脚本,谈到了编辑器和 IDE 上的操作,再进一步谈到 AI 时代的开发工具。其实,AI 时代的开发工具并不是只有 Github Copilot,亚马逊为我们提供了类似于 Github Copilot 的,用法上大同小异,而且号称免费。我也见到了很多人编码的时候,屏幕的一角放在 ChatGPT 或者是 New Bing,随时随地与它们进行交流,让它们协助写代码或者改 Bug。原创 2024-03-20 11:29:26 · 638 阅读 · 0 评论 -
结束语 | 少做事,才能更有效地工作
在这个专栏里,讲过很多东西,几乎涉及到软件开发的方方面面,但有一个重要的方面,我却从来没有说过,那就是算法。因为一直把它当做不言而喻的基本功,认为每个程序员都应该掌握。在我们专栏的结束语中,就用这个没有涉及过的话题来开篇吧!原创 2024-03-20 11:28:34 · 721 阅读 · 0 评论 -
总复习 | 重新审视“最佳实践”
相关阅读:《03 | DoD 价值:你完成了工作,为什么他们还不满意?原创 2024-03-20 11:07:50 · 434 阅读 · 0 评论 -
划重点 | “综合运用”主题内容的全盘回顾
又到了我们划重点的时间了,因为篇幅关系,“综合运用”这个模块最为短小精悍。在这个模块中,我们把前面学到的各种知识综合起来,运用在实际的工作场景中,让你知道这些内容并不是一个个孤立的实践,在实际工作中,唯有将它们结合起来,才能发挥最大功效。原创 2024-03-20 10:36:07 · 474 阅读 · 0 评论 -
答疑解惑 | 如何在实际工作中推行新观念?
在整个专栏的最后一个大模块"综合运用"中,我们把前面学到的各种原则和知识穿插在一起应用在了不同的场景中。在这个模块的答疑中,我们也综合汇总一次,把整个专栏中出现的一些有趣却还没有来得及讨论的问题放在一起。原创 2024-03-20 10:02:34 · 541 阅读 · 0 评论 -
40 | 我们应该如何保持竞争力?
程序员是一个充满焦虑的群体,焦虑的本质是对未来的不确定。工作在这个时代的程序员是一个特殊的群体,一方面,这个大时代为我们创造了无数的机会,另一方面,因为程序员是一个新的行业,所以,很多人不知道未来是什么样子的,焦虑颇深。从目前的发展来看,IT 行业依然是一个非常有前景的行业,但想在这条路上走好,需要我们成为 “T ”型人才,也就是“一专多能”。一专多能的前提是“一专”,让自己成为某个方面的专家。这个专家要放在行业的标准去看,这才能降低因为一个公司的波动而造成的影响。原创 2024-03-20 08:57:13 · 851 阅读 · 0 评论 -
39 | 面对遗留系统,你应该这样做
在上一讲中,结合着“新入职一家公司”的场景,我给你讲了如何在具体情况下应用我们前面学到的知识。这一讲,我们再来选择一个典型的实际工作场景,将所学综合应用起来。这个场景就是面对遗留系统。在《34 | 你的代码是怎么变混乱的?》中,讲了代码是会随着时间腐化的,无论是有意,还是无意。即便是最理想的场景,代码设计得很好,维护得也很精心,但随着技术的不断升级进步,系统也需要逐步升级换代。比如,我们一直认为电信是一个独特的领域,与 IT 技术是完全独立的,学好 CT(Communication Technolo原创 2024-03-19 21:03:38 · 972 阅读 · 0 评论 -
38 | 新入职一家公司,怎么快速进入工作状态?
介绍了怎么把前面学到的知识运用在了解一个项目上,按照业务、技术和团队运作三个方面去了解。大多数程序员习惯的工作方式,往往是从细节入手,很难建立起一个完整的图景,常常是“只见树木不见森林”,而我的方式则是从大到小、由外而内,将要了解的内容层层分解,有了大图景之后,很容易知道自己做的事情到底在整体上处于什么样的位置。把上面的内容总结了成一份供你参考。附赠一点小技巧:使用“行话”。在交流的过程中,学习一点”行话“。这会让人觉得你懂行,让你很快得到信任,尽早融入团队。了解一个项目,从大图景开始。原创 2024-03-19 19:44:40 · 921 阅读 · 0 评论 -
划重点 | “自动化”主题的重点内容回顾汇总
自动化”模块终于全部更新完毕。至此,四个工作原则已经全部介绍了一遍,相对而言,这个模块的内容比较“硬”,也竭尽全力帮你串起更多知识的脉络,所以,信息量也是非常大的。希望你能够找到自己接下来努力的方向,不断提升自己的“硬实力”。原创 2024-03-19 19:04:48 · 454 阅读 · 0 评论 -
答疑解惑 | 持续集成、持续交付,然后呢?
自动化”模块落下了帷幕,这是四个工作原则中最为“技术化”的一个,也应该是程序员们最熟悉的主题。从软件外部的自动化——工作流程讲起,让你能够把注意力专注于写好代码;讲到了软件内部的自动化——软件设计,选择恰当的做法,不贪图一时痛快,为后续的工作挖下深坑。既然是一个大家都熟悉的话题,同学们自然也有很多经验分享,也有很多人看到了与自己不同的做法,提出了各种各样的问题。在今天的答疑中,选出了几个很有意思的问题,让大家可以在已有内容上再进一步延伸。原创 2024-03-19 18:06:43 · 870 阅读 · 0 评论 -
37 | 先做好DDD再谈微服务吧,那只是一种部署形式
微服务是很多团队的努力方向,然而,现在市面上对于微服务的介绍多半只停留在技术层面上,很多人看到微服务的好,大多数是结果,到自己团队实施起来却困难重重。想要做好微服务,关键在于服务的划分,而划分服务,最好先学习 DDD。Eric Evans 2003 年写了《领域驱动设计》,向行业介绍了 DDD 这套方法论,立即在行业中引起广泛的关注。但实话说,Eric 在知识传播上的能力着实一般,这本 DDD 的开山之作写作质量难以恭维,想要通过它去学好 DDD,是非常困难的。原创 2024-03-19 17:29:02 · 871 阅读 · 0 评论 -
36 | 为什么总有人觉得5万块钱可以做一个淘宝?
今天,我以淘宝的系统为例,给你介绍了一个系统逐渐由简单变复杂的发展历程,希望你能认清不同业务量级的系统本质上就不是一个系统。一方面,有人会因为对业务量级理解不足,盲目低估其他人系统的复杂度;另一方面,也有人会盲目应用技术,给系统引入不必要的复杂度,让自己陷入泥潭。作为拥有技术能力的程序员,我们都非常在意个人技术能力的提升,但却对在什么样情形下,什么样的技术更加适用考虑得不够。采用恰当的技术,解决当前的问题,是每个程序员都应该仔细考虑的问题。用简单技术解决问题,直到问题变复杂。原创 2024-03-19 16:46:42 · 816 阅读 · 0 评论 -
35 | 总是在说MVC分层架构,但你真的理解分层吗?
从最常见的服务端三层架构入手,讲了它们的来龙去脉。分层架构实际是一种设计上的分解,将不同的内容放在不同的地方,降低软件开发和维护的成本。分层,更关键的是,提供抽象。这种分层抽象在计算机领域无处不在,无论是编程语言,还是网络协议,都体现着分层抽象的价值。有了分层抽象,人们才能更好地在抽象的基础上构建更复杂的东西。构建好你的领域模型。原创 2024-03-19 15:57:11 · 633 阅读 · 0 评论 -
34 | 你的代码是怎么变混乱的?
今天,讲的内容是软件设计,很多代码的问题就是因为对设计思考得不足导致的。许多程序员学习设计是从设计模式起步的,但这种学法往往会因为缺乏结构,很难有效掌握。设计原则,是一个更好的体系,掌握设计原则之后,才能更好地理解设计模式这些招式。Robert Martin 总结出的“SOLID”是一套相对完整易学的设计原则。以“SOLID” 中的单一职责原则为例,给你稍做展开,更多的内容可以去看 Robert Martin 的书。原创 2024-03-19 14:51:58 · 966 阅读 · 0 评论 -
33 | 如何做好验收测试?
今天分享了自动化验收测试的话题。验收测试(Acceptance Testing),是确认应用是否满足设计规范的测试。验收测试是技术交付必经的环节,只不过,各个团队实践水平有所差异,有的靠人工,有的用简单自动化,一些做得比较好的团队才有完善的自动化。自动化验收测试也是一个逐步发展的过程,从最开始的各自为战,到后来逐渐形成了一个完整的自动化验收测试的体系。今天,以行为驱动开发(Behavior Driven Development,BDD)为核心,给你介绍了一种自动化验收测试的方式。原创 2024-03-19 14:16:56 · 750 阅读 · 0 评论 -
32 | 持续交付:有持续集成就够了吗?
总结一下今天的内容。我们延续了前两讲的内容,在准备好发布包和部署的基础设施之后,我们顺着持续集成的思路,将部署过程也加了进来,这就是持续交付。持续交付,是一种让软件随时处于可以部署到生产环境的能力。让软件具备部署到生产环境的能力,这里面有两个关键点:验证发布包和部署。验证发布包,不仅是功能上的验证,还包括与环境结合在一起的验证。原创 2024-03-19 11:59:20 · 807 阅读 · 0 评论 -
31 | 程序员怎么学习运维知识?
我们今天的关注点在于,将开发过程产生的构建产物部署起来。部署过程要依赖于运维知识,每个程序员都应该学习运维知识,保证我们对软件的运行有更清楚地认识,而且部署工作是非常适合自动化的。但是,对运维工具的学习是非常困难的,因为我们遇到的很多工具是非常零散的,缺乏体系。这里,介绍了一个运维的知识体系,这个体系借鉴自 Java 的知识体系,包括了编程语言、核心库、第三方库、开发框架、单机部署和集群部署等诸多方面。把今天提到的各种技术整理成一个表格列在下面,你可以参考它更好地理解运维知识。有体系地学习运维知识。原创 2024-03-19 11:27:38 · 866 阅读 · 0 评论 -
30 | 一个好的项目自动化应该是什么样子的?
总结一下今天的内容。今天我们通过一个具体的例子,展示了一个最基本的项目自动化过程,包括了:生成 IDE 工程;编译;打包;运行测试;代码风格检查;测试覆盖率;数据库迁移;运行应用。但这就是自动化的全部了吗?显然不是,我这里给出的只是一个最基本的示例。实际上,几乎每个重复的工作或是繁琐的工作,都应该自动化。我们不应该把时间和精力浪费在那些机器可以很好地替我们完成的工作上。今天的基础设施已经让我们的自动化工作变得比以往容易了很多,比如,可执行 JAR 包就比从前部署到应用服务器上简化太多了。原创 2024-03-19 10:40:01 · 723 阅读 · 0 评论 -
29 | “懒惰”应该是所有程序员的骄傲
Perl 语言的发明人 Larry Wall 曾经说过,优秀程序员应该有三大美德:懒惰、急躁和傲慢(Laziness, Impatience and hubris)。想要成为一个优秀的程序员,就要让机器为自己很好地工作,而这需要对自动化有着很好地理解。我们学习自动化,先要知道哪些东西不要自动化,尽最大的努力不做浪费时间的事。一方面,我们要从需求上规避那些没必要做的事;另一方面,我们也从自身防止 NIH 综合症(Not Invented Here Syndrome),争取做一个懒惰的程序员。原创 2024-03-19 10:07:00 · 734 阅读 · 0 评论 -
| 你真的了解重构吗?
总结一下今天的内容。今天我介绍了一个大家耳熟能详的概念:重构。不过,这实在是一个让人误解太多的概念,大家经常认为调整代码就是在做重构。重构,本质上就是一堆微操作。重构这个实践的核心,就是将调整代码的动作分解成一个一个的小动作,如果不能理解这一点,你就很难理解重构本身的价值。不过,对于我们专栏的读者而言,因为大家已经学过了“任务分解”模块,理解起这个概念,难度应该降低了很多。既然重构的核心也是分解,它就需要大量的锤炼。原创 2024-03-19 09:05:50 · 835 阅读 · 0 评论 -
划重点 | 一次关于“沟通反馈”主题内容的复盘
在“沟通反馈”这个模块中,与你探讨了与人打交道的一些方法,只不过,这并非是传统意义上的谈话技巧。而是希望你能克服自己的心理障碍,主动与真实世界进行沟通,获取反馈,让自己对信息的编解码能力不断得到提升。原创 2024-03-18 20:56:19 · 782 阅读 · 0 评论 -
答疑解惑 | 持续集成,一条贯穿诸多实践的主线
沟通反馈”模块又告一段落了,在这个模块中,我们把自己与真实世界的距离又拉近了一步。一方面,我们强调主动沟通,把自身的信息更有效地传达出去;另一方面,我们也重视反馈,让真实世界的信息,更多地回到我们身边。同学们分享了很多经验,也提出了不少的问题。在今天的答疑中,选择了几个非常好的问题,从不同的角度丰富一下之前讲解的内容。原创 2024-03-18 20:35:29 · 742 阅读 · 0 评论 -
28 | 结构化:写文档也是一种学习方式
程序员对文档有着一种矛盾的情感,一方面,需要依赖于文档获得知识,另一方面,很少有人愿意写文档。文档在程序员心目中“形象不佳”,主要是传统的流程写了太多无用的文档。但对更多人来说,不愿意写文档,本质上是因为知识不能很好地结构化。有结构的知识会让新知识的学习变得更加容易,今天很多人抱怨新知识层出不穷,就是因为知识过于零散,当知识有结构之后,学习新知识就只是在学习增量,效率自然就会大幅度提升。输出是一种很好的方式,帮助你把知识连接起来,写作和做公开演讲都是很好的输出方式。原创 2024-03-18 19:46:35 · 852 阅读 · 0 评论 -
答疑解惑 | 如何分解一个你不了解的技术任务?
在“任务分解”这个模块,以测试为核心,讲解了任务分解这个原则,同时也介绍了一些最佳实践,帮助你更好地理解任务分解的重要性,以及应该怎样分解任务。同学们对任务分解这个原则大多是表示认同的,但就一些具体应用的场景,还是提出了自己的问题。在今天的答疑中,选择了几个非常典型的问题来进行深入讨论。原创 2024-03-18 18:58:46 · 803 阅读 · 0 评论 -
27 | 尽早暴露问题: 为什么被指责的总是你?
我们今天讨论了一个重要的工作原则,把事情往前做,尽早暴露问题。我们前面讲的很多内容说的都是这个原则,比如,要先确定结果,要在事前做推演等等。越早发现问题,解决的成本就越低,不仅仅是解决问题本身的成本,更多的是对团队整体计划的影响。一方面,事前我们要通过“以终为始”和“任务分解”早点发现问题;另一方面,在做事过程中,一旦在有限时间内搞不定,尽早让其他人知道。这个原则在写程序中的体现就是 Fail Fast,很多程序员因为没有坚持这个原则,不断妥协,造成了程序越来越复杂,团队就陷入了无尽的泥潭。原创 2024-03-18 18:12:16 · 1094 阅读 · 0 评论 -
26 | 作为程序员,你也应该聆听用户声音
今天我们讨论了一个重要的话题:倾听用户声音。这是开发团队普遍欠缺的一种能力,更准确地说,是忽略的一种能力。所以,“吃自家的狗粮”这种听上去本来是理所当然的事情,才被反复强调,成为 IT 行业的经典。在今天这一讲,介绍了“了解用户需求”的不同做法,但其归根结底就是一句话,想办法接近用户。无论是自己做用户,还是找机会接触已有用户,亦或是没有用户创造用户。只有多多听取来自真实用户的声音,我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近,谁就有发言权,无论你的角色是什么。多走近用户。原创 2024-03-18 17:10:09 · 913 阅读 · 0 评论 -
25 | 开发中的问题一再出现,应该怎么办?
复盘,原本是一个围棋术语,就是对弈者下完一盘棋之后,重新把对弈过程摆一遍,看看哪些地方下得好,哪些下得不好,哪些地方可以有不同甚至是更好的下法等等。这种把过程还原,进行研讨与分析的方式,就是复盘。现如今,复盘的概念已经被人用到了很多方面,比如,股市的复盘、企业管理的复盘,它也成为了许多人最重要的工具,帮助个体和企业不断地提升。这其中最有名的当属联想的创始人柳传志老爷子,他甚至把“复盘”写到了联想的核心价值观里。为什么复盘这么好用呢?在我看来有一个重要的原因,在于客体化。俗话说,当局者迷,旁观者清。原创 2024-03-18 16:28:56 · 759 阅读 · 0 评论 -
24 | 快速反馈:为什么你们公司总是做不好持续集成?
持续集成是软件开发中的重要实践,做好持续集成的关键在于,快速反馈。这里面有两个目标,怎样快速地得到反馈,以及什么样的反馈是有效的。做好快速反馈,要把本地能做好的事情,在本地做好;也要通过小步提交的方式,加快代码开发的节奏。什么是有效的反馈?一是即时的反馈,二是引人注目的反馈。有很多种持续集成相关的工具可以帮助我们达成有效的反馈。想要做好持续集成,还要有一些纪律要遵循:只有 CI 服务器处于绿色的状态才能提交代码;CI 服务器一旦检查出错,要立即修复。做好持续集成的关键在于,快速反馈。原创 2024-03-18 15:58:39 · 769 阅读 · 0 评论 -
23 | 可视化:一种更为直观的沟通方式
ThoughtWorks 技术雷达是由 ThoughtWorks 技术咨询委员会(Technology Advisory Board)编写的一份技术趋势报告,每 6 个月发布一次。ThoughtWorks 的项目多样性足够丰富,所以它能够发现诸多技术趋势。因此,相比于行业中其它的预测报告,技术雷达更加具体,更具可操作性。在接触技术雷达的时间很早。在 2013 年就已经开始与人讨论微服务,并在项目中尝试使用 Docker,而这一切信息的来源都是技术雷达。原创 2024-03-18 15:04:09 · 874 阅读 · 0 评论 -
22 | 轻量级沟通:你总是在开会吗?
开会是很多程序员的困扰,太多的会议甚至会影响到你工作的进展。开会的本意是为了解决问题,但实际上,大多数会议并不能很好地解决问题。因为会议是一种重量级的沟通方式,很多人参加会议时,并不能很好地参与其中。如果你想用会议的形式与别人讨论问题,最好放弃这种打算,面对面的沟通是最好的方式。因为面对面沟通很轻,人数相对少,每个人参与度就会高很多。基于这种改进,我们可以把大部分会议都改成信息同步的会,效率就会得到提高。还介绍了一种特殊的会议:站会。之所以采用站会的方式,就是要控制时间。原创 2024-03-18 14:51:30 · 1221 阅读 · 0 评论 -
21 | 你的代码为谁而写?
代码是程序员与机器沟通的桥梁,写好代码是每个程序员的追求,一个专业程序员,追求的不仅是实现功能,还要追求代码可维护。如果你想详细学习如何写好代码,我推荐你去读 Robert Martin 的《代码整洁之道》(Clean Code),这本书几乎覆盖了把代码写好的方方面面。命名,是写程序中最基础,也是一个程序员从业余走向专业的门槛。我以命名为基础,给你解释了写好代码的提升路径。最初的层次是编写可以运行的代码,然后是编写符合代码规范的代码。对于命名,最粗浅的理解是不要起无意义的名字,遵循编码规范。原创 2024-03-18 14:20:09 · 827 阅读 · 0 评论 -
20 | 为什么世界和你的理解不一样?
人生不如意之事,十有八九,之所以很多人有如此多的不如意,很大原因在于我们对真实世界有着很多不切实际的幻想,美好的愿望并不能驱动这个世界,在软件开发中也是如此。虽然人和人生活在一个世界中,但对世界的理解却是千差万别的。我们借用了信息论的一个通信模型解释为什么每个人看到的世界会有如此大的差异,其核心就在于,人和人拥有不同的编解码器。想要在这个真实世界中生活得更幸福一些,需要我们不断地改善自己的编解码器。改善编解码,需要从几个角度着手,分别是:编码器,让信息能输出更准确;解码器,减少信号过滤,改善解码能力;原创 2024-03-18 11:54:37 · 930 阅读 · 0 评论 -
划重点 | 关于“任务分解”,你要重点掌握哪些事?
在这个模块中,主要讲解的是“任务分解”这个知易行难的工作原则。普通人与高手之间的差异,很大程度上取决于任务分解的粒度大小。但真正理解并应用好“任务分解”的原则并不容易,希望你能勤于练习,将知识内化成为你的能力。原创 2024-03-18 11:31:22 · 904 阅读 · 0 评论 -
19 | 如何用最小的代价做产品?
产品同样需要分解,目前在探索产品的不确定性上的最佳实践是精益创业,而精益创业就包含了将庞大的产品分而治之的方式:最小可行产品(Minimum Viable Product,MVP)。最小可行产品就是“刚刚好”满足客户需求的产品。想要在实践中运用好最小可行产品的理念,就是要用最小的代价找到一条可行的路径。最小的代价就是能不做的事就不做,能简化的事情就简化。程序员通常愿意用自己的代码解决问题,而写代码通常是代价非常高的解决方案,它应该成为最后的产品解决方案。原创 2024-03-18 10:30:33 · 748 阅读 · 0 评论 -
18 | 需求管理:太多人给你安排任务,怎么办?
需求分解之后,最重要的是,排列需求的优先级。优先级的排列方式有很多,我们可以借鉴时间管理的方法,把事情按照重要和紧急的维度进行划分,得到了四个象限。我们要尽可能把精力放在重要的事情上,而不是把紧急的事情当成优先级排序的方式。需求分解成一个个小块,其实也分解了原本合一的上下文。如果想要有效地管理需求,尤其是确定事情的重要程度,一种方式是找回丢失的上下文。如果我们自己无法判断上下文,一种好的办法是,引入外部更大的上下文。尽量做最重要的事。原创 2024-03-18 09:26:03 · 969 阅读 · 0 评论 -
17 | 程序员也可以“砍”需求吗?
软件开发中,需求管理是非常重要的一环。在需求管理上常见的错误是,需求管理的粒度太大,很多团队几乎是在用一个大主题在管理需求,这就让需求调整的空间变得很小。结合用户故事,我给你讲了一个好的需求管理基本单位是什么样子的,它要符合“INVEST 原则”。其中的一个关键点是“小”,只有小的需求才方便管理和调整。什么样的需求才算小呢?给你介绍了一种需求估算的方式,每个团队都可以根据自己的特点决定在自己的团队里,多大的需求算大。大需求怎么办?只要再进行分解就好了。原创 2024-03-17 23:51:54 · 799 阅读 · 0 评论 -
16 | 为什么你的测试不够好?
测试是一个说起来很简单,但很不容易写好的东西。在实际工作中,很多人都会遇到关于测试的各种各样问题。之所以出现问题,主要是因为这些测试写得太复杂了。测试一旦复杂了,我们就很难保证测试的正确性,何谈用测试保证代码的正确性。讲了测试的基本结构:前置准备、执行、断言和清理,还介绍了一些常见的测试“坏味道”:做了太多事的测试,没有断言的测试,还有一种看一眼就知道有问题的“坏味道”,测试里有判断语句。怎么衡量测试是否做好了呢?原创 2024-03-17 23:35:08 · 851 阅读 · 0 评论 -
15 | 一起练习:手把手带你分解任务
简单的做法就是加入一个 filter,在请求到达真正的资源代码之前先做一层过滤,在这个 filter 里面,如果待访问的地址是需要登录访问的,我们就看看用户是否已经登录,现在一般的做法是用一个 Token,这个 Token 一般会从 HTTP 头里取出来。另外,有用户登录,一般情况下,还会有一个退出的功能。另外,对比我们在分解过程中的顺序,你会看到这个完整任务清单的顺序是调整过的,你可以按照这个列表中的内容一项一项地做,调整最基本的标准是,按照这些任务的依赖关系以及前面提到的“完整地实现一个需求”的原则。原创 2024-03-17 22:47:37 · 879 阅读 · 0 评论 -
14 | 大师级程序员的工作秘笈
TDD 在很多人眼中是不实用的,一来他们并不理解测试“驱动”开发的含义,但更重要的是,他们很少会做任务分解。而任务分解是做好 TDD 的关键点。只有把任务分解到可以测试的地步,才能够有针对性地写测试。同样听到任务分解这个说法,不同的人理解依然是不一样的。我把任务分解的结果定义成微操作,它远比大多数人理解得小。我们能将任务分解到多小,就决定了我们原子操作的粒度是多大。软件开发中的许多问题正是由于粒度太大造成的,比如,分支策略。将任务拆小,越小越好。原创 2024-03-17 22:16:11 · 840 阅读 · 0 评论 -
13 | 先写测试,就是测试驱动开发吗?
一些优秀的程序员不仅仅在写测试,还在探索写测试的实践。有人尝试着先写测试,于是,有了一种实践叫测试先行开发。还有人更进一步,一边写测试,一边调整代码,这叫做测试驱动开发,也就是 TDD。从步骤上看,关键差别就在,TDD 在测试通过之后,要回到代码上,消除代码的坏味道。测试驱动开发已经是行业中的优秀实践,学习测试驱动开发的第一步是,记住测试驱动开发的节奏:红——绿——重构。把测试放在前面,还带来了视角的转变,要编写可测的代码,为此,我们甚至需要调整设计,所以,有人也把 TDD 称为测试驱动设计。原创 2024-03-17 19:27:06 · 895 阅读 · 0 评论