- 博客(7015)
- 资源 (9)
- 收藏
- 关注
RSS订阅原创 如何管理你的上级？
你好，我是程序员贵哥。在这个模块里，我围绕着“以终为始”这个原则为你进行了详细地讲解，还给你介绍了应用“以终为始”原则的一些行业最佳实践。同学们的留言特别踊跃，很多同学表示有收获的同时，也提出了大量的问题，大家比较关心怎样将这些实践在自己的实际工作中落地，部分问题我已经在留言中回复了。在今天的答疑环节中，我挑选了一些非常典型的问题来更详细地回答一下。
2025-05-20 10:28:57
1
原创 如何分解一个你不了解的技术任务？
你好，我是程序员贵哥。在“任务分解”这个模块，我以测试为核心，讲解了任务分解这个原则，同时也给你介绍了一些最佳实践，帮助你更好地理解任务分解的重要性，以及应该怎样分解任务。同学们对任务分解这个原则大多是表示认同的，但就一些具体应用的场景，还是提出了自己的问题。在今天的答疑中，我选择了几个非常典型的问题来进行深入讨论。
2025-05-20 10:23:02
213
原创 我们应该如何保持竞争力？
你好，我是程序员贵哥。在前面两讲，我结合着两个程序员要直接面对的场景，讨论了如何综合运用前面学习到的知识，这一讲的内容可能不涉及到实际的应用场景，但与每个人的发展息息相关。我想谈谈如何走好程序员这条路。
2025-05-19 10:54:36
609
原创 面对遗留系统，你应该这样做？
你好，我是程序员贵哥。在上一讲中，结合着“新入职一家公司”的场景，我给你讲了如何在具体情况下应用我们前面学到的知识。这一讲，我们再来选择一个典型的实际工作场景，将所学综合应用起来。这个场景就是面对遗留系统。在《》中，我给你讲了代码是会随着时间腐化的，无论是有意，还是无意。即便是最理想的场景，代码设计得很好，维护得也很精心，但随着技术的不断升级进步，系统也需要逐步升级换代。
2025-05-19 10:51:30
768
原创 新入职一家公司，怎么快速进入工作状态？
我给你介绍了怎么把前面学到的知识运用在了解一个项目上，按照业务、技术和团队运作三个方面去了解。大多数程序员习惯的工作方式，往往是从细节入手，很难建立起一个完整的图景，常常是“只见树木不见森林”，而我的方式则是从大到小、由外而内，将要了解的内容层层分解，有了大图景之后，很容易知道自己做的事情到底在整体上处于什么样的位置。我把上面的内容总结了成一份供你参考。附赠一点小技巧：使用“行话”。在交流的过程中，学习一点”行话“。这会让人觉得你懂行，让你很快得到信任，尽早融入团队。了解一个项目，从大图景开始。
2025-05-19 10:47:32
638
原创 先做好DDD再谈微服务吧，那只是一种部署形式
微服务是很多团队的努力方向，然而，现在市面上对于微服务的介绍多半只停留在技术层面上，很多人看到微服务的好，大多数是结果，到自己团队实施起来却困难重重。想要做好微服务，关键在于服务的划分，而划分服务，最好先学习 DDD。Eric Evans 2003年写了《领域驱动设计》，向行业介绍了DDD 这套方法论，立即在行业中引起广泛的关注。但实话说，Eric 在知识传播上的能力着实一般，这本 DDD 的开山之作写作质量难以恭维，想要通过它去学好 DDD，是非常困难的。
2025-05-19 10:43:07
448
原创 为什么总有人觉得5万块钱可以做一个淘宝？
今天，我以淘宝的系统为例，给你介绍了一个系统逐渐由简单变复杂的发展历程，希望你能认清不同业务量级的系统本质上就不是一个系统。一方面，有人会因为对业务量级理解不足，盲目低估其他人系统的复杂度；另一方面，也有人会盲目应用技术，给系统引入不必要的复杂度，让自己陷入泥潭。作为拥有技术能力的程序员，我们都非常在意个人技术能力的提升，但却对在什么样情形下，什么样的技术更加适用考虑得不够。采用恰当的技术，解决当前的问题，是每个程序员都应该仔细考虑的问题。用简单技术解决问题，直到问题变复杂。
2025-05-19 10:39:36
436
原创 总是在说MVC分层架构，但你真的理解分层吗？
你好，我是程序员贵哥。作为程序员，你一定听说过分层，比如，最常见的 Java 服务端应用的三层结构，在《这几乎成为了写 Java 服务的标准模式。但不知道你有没有想过，为什么要分层呢？
2025-05-19 10:30:25
398
原创 你的代码是怎么变混乱的？
你好，我是程序员贵哥。前面几讲，我给你讲了开发过程的各种自动化，从构建、验证到上线部署，这些内容都是站在软件外部看的。从这一讲开始，我准备带领大家进入到软件内部。今天的话题就从写代码开始说起。
2025-05-19 10:23:22
548
原创 如何做好验收测试？
今天我和你分享了自动化验收测试的话题。验收测试（Acceptance Testing），是确认应用是否满足设计规范的测试。验收测试是技术交付必经的环节，只不过，各个团队实践水平有所差异，有的靠人工，有的用简单自动化，一些做得比较好的团队才有完善的自动化。自动化验收测试也是一个逐步发展的过程，从最开始的各自为战，到后来逐渐形成了一个完整的自动化验收测试的体系。今天，我以行为驱动开发（Behavior Driven Development，BDD）为核心，给你介绍了一种自动化验收测试的方式。
2025-05-19 10:17:19
431
原创 持续交付：有持续集成就够了吗？
总结一下今天的内容。我们延续了前两讲的内容，在准备好发布包和部署的基础设施之后，我们顺着持续集成的思路，将部署过程也加了进来，这就是持续交付。持续交付，是一种让软件随时处于可以部署到生产环境的能力。让软件具备部署到生产环境的能力，这里面有两个关键点：验证发布包和部署。验证发布包，不仅是功能上的验证，还包括与环境结合在一起的验证。
2025-05-19 10:12:21
658
原创 程序员怎么学习运维知识
我们今天的关注点在于，将开发过程产生的构建产物部署起来。部署过程要依赖于运维知识，每个程序员都应该学习运维知识，保证我们对软件的运行有更清楚地认识，而且部署工作是非常适合自动化的。但是，对运维工具的学习是非常困难的，因为我们遇到的很多工具是非常零散的，缺乏体系。这里，我给你介绍了一个运维的知识体系，这个体系借鉴自 Java 的知识体系，包括了编程语言、核心库、第三方库、开发框架、单机部署和集群部署等诸多方面。我把今天提到的各种技术整理成一个表格列在下面，你可以参考它更好地理解运维知识。
2025-05-19 10:03:52
601
原创 一个好的项目自动化应该是什么样子的？
总结一下今天的内容。生成 IDE 工程；编译；打包；运行测试；代码风格检查；测试覆盖率；数据库迁移；运行应用。但这就是自动化的全部了吗？显然不是，我这里给出的只是一个最基本的示例。实际上，几乎每个重复的工作或是繁琐的工作，都应该自动化。我们不应该把时间和精力浪费在那些机器可以很好地替我们完成的工作上。今天的基础设施已经让我们的自动化工作变得比以往容易了很多，比如，可执行 JAR 包就比从前部署到应用服务器上简化太多了。Gradle 也让订制构建脚本的难度降低了很多。
2025-05-16 17:13:49
763
原创 “懒惰”应该是所有程序员的骄傲
Perl 语言的发明人 Larry Wall 曾经说过，优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）。想要成为一个优秀的程序员，就要让机器为自己很好地工作，而这需要对自动化有着很好地理解。我们学习自动化，先要知道哪些东西不要自动化，尽最大的努力不做浪费时间的事。一方面，我们要从需求上规避那些没必要做的事；另一方面，我们也从自身防止 NIH 综合症（Not Invented Here Syndrome），争取做一个懒惰的程序员。
2025-05-16 11:40:37
840
原创 结构化：写文档也是一种学习方式
程序员对文档有着一种矛盾的情感，一方面，需要依赖于文档获得知识，另一方面，很少有人愿意写文档。文档在程序员心目中“形象不佳”，主要是传统的流程写了太多无用的文档。但对更多人来说，不愿意写文档，本质上是因为知识不能很好地结构化。有结构的知识会让新知识的学习变得更加容易，今天很多人抱怨新知识层出不穷，就是因为知识过于零散，当知识有结构之后，学习新知识就只是在学习增量，效率自然就会大幅度提升。输出是一种很好的方式，帮助你把知识连接起来，写作和做公开演讲都是很好的输出方式。
2025-05-16 11:37:42
644
原创 尽早暴露问题： 为什么被指责的总是你？
我们今天讨论了一个重要的工作原则，把事情往前做，尽早暴露问题。我们前面讲的很多内容说的都是这个原则，比如，要先确定结果，要在事前做推演等等。越早发现问题，解决的成本就越低，不仅仅是解决问题本身的成本，更多的是对团队整体计划的影响。一方面，事前我们要通过“以终为始”和“任务分解”早点发现问题；另一方面，在做事过程中，一旦在有限时间内搞不定，尽早让其他人知道。这个原则在写程序中的体现就是 Fail Fast，很多程序员因为没有坚持这个原则，不断妥协，造成了程序越来越复杂，团队就陷入了无尽的泥潭。
2025-05-16 11:32:32
853
原创 作为程序员，你也应该聆听用户声音?
今天我们讨论了一个重要的话题：倾听用户声音。这是开发团队普遍欠缺的一种能力，更准确地说，是忽略的一种能力。所以，“吃自家的狗粮”这种听上去本来是理所当然的事情，才被反复强调，成为 IT 行业的经典。在今天这一讲，我给你介绍了“了解用户需求”的不同做法，但其归根结底就是一句话，想办法接近用户。无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。谁离用户近，谁就有发言权，无论你的角色是什么。多走近用户。
2025-05-16 11:29:53
605
原创 开发中的问题一再出现，应该怎么办？
复盘，原本是一个围棋术语，就是对弈者下完一盘棋之后，重新把对弈过程摆一遍，看看哪些地方下得好，哪些下得不好，哪些地方可以有不同甚至是更好的下法等等。这种把过程还原，进行研讨与分析的方式，就是复盘。现如今，复盘的概念已经被人用到了很多方面，比如，股市的复盘、企业管理的复盘，它也成为了许多人最重要的工具，帮助个体和企业不断地提升。这其中最有名的当属联想的创始人柳传志老爷子，他甚至把“复盘”写到了联想的核心价值观里。为什么复盘这么好用呢？在我看来有一个重要的原因，在于客体化。俗话说，当局者迷，旁观者清。
2025-05-16 11:27:21
634
原创 快速反馈：为什么你们公司总是做不好持续集成？
持续集成是软件开发中的重要实践，做好持续集成的关键在于，快速反馈。这里面有两个目标，怎样快速地得到反馈，以及什么样的反馈是有效的。做好快速反馈，要把本地能做好的事情，在本地做好；也要通过小步提交的方式，加快代码开发的节奏。什么是有效的反馈？一是即时的反馈，二是引人注目的反馈。有很多种持续集成相关的工具可以帮助我们达成有效的反馈。只有 CI 服务器处于绿色的状态才能提交代码；CI 服务器一旦检查出错，要立即修复。做好持续集成的关键在于，快速反馈。
2025-05-16 11:23:42
855
原创 可视化：一种更为直观的沟通方式
ThoughtWorks 技术雷达是由 ThoughtWorks 技术咨询委员会（Technology Advisory Board）编写的一份技术趋势报告，每6个月发布一次。ThoughtWorks 的项目多样性足够丰富，所以它能够发现诸多技术趋势。因此，相比于行业中其它的预测报告，技术雷达更加具体，更具可操作性。ThoughtWorks 是我的老东家，所以，我在接触技术雷达的时间很早。我在2013年就已经开始与人讨论微服务，并在项目中尝试使用 Docker，而这一切信息的来源都是技术雷达。
2025-05-16 11:17:30
996
原创 轻量级沟通：你总是在开会吗？
开会是很多程序员的困扰，太多的会议甚至会影响到你工作的进展。开会的本意是为了解决问题，但实际上，大多数会议并不能很好地解决问题。因为会议是一种重量级的沟通方式，很多人参加会议时，并不能很好地参与其中。如果你想用会议的形式与别人讨论问题，最好放弃这种打算，面对面的沟通是最好的方式。因为面对面沟通很轻，人数相对少，每个人参与度就会高很多。基于这种改进，我们可以把大部分会议都改成信息同步的会，效率就会得到提高。我还给你介绍了一种特殊的会议：站会。之所以采用站会的方式，就是要控制时间。我昨天做了什么？
2025-05-16 11:13:35
659
原创 你的代码为谁而写？
代码是程序员与机器沟通的桥梁，写好代码是每个程序员的追求，一个专业程序员，追求的不仅是实现功能，还要追求代码可维护。如果你想详细学习如何写好代码，我推荐你去读 Robert Martin 的《代码整洁之道》（Clean Code），这本书几乎覆盖了把代码写好的方方面面。命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。我以命名为基础，给你解释了写好代码的提升路径。最初的层次是编写可以运行的代码，然后是编写符合代码规范的代码。对于命名，最粗浅的理解是不要起无意义的名字，遵循编码规范。
2025-05-16 11:07:34
821
原创 为什么世界和你的理解不一样？
你好，我是程序员贵哥。如果看到沟通反馈几个字，你就以为我打算在这里教一些谈话技巧，那你还真的想错了。在这个模块里，我打算与你讨论的主题是，生活在真实世界中。沟通反馈和生活在真实世界这两个话题是怎么联系到一起的呢？请听我慢慢道来。《大富翁》里的沙隆巴斯有句口头禅：人生不如意的事，十有八九！但是不知道你有没有想过这样的一个问题，为什么人生如此不如意？如果这是一篇鸡汤文，我应该告诉你世事艰辛。为什么会这样？欢迎来到真实世界，真实世界不是以美好愿望驱动的，它有着自己的运行规律。
2025-05-15 16:27:52
705
原创 如何用最小的代价做产品？
产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品。**想要在实践中运用好最小可行产品的理念，就是要用最小的代价找到一条可行的路径。**最小的代价就是能不做的事就不做，能简化的事情就简化。程序员通常愿意用自己的代码解决问题，而写代码通常是代价非常高的解决方案，它应该成为最后的产品解决方案。
2025-05-15 15:22:05
770
原创 需求管理：太多人给你安排任务，怎么办？
比如，我们放任系统不做升级改造，过多的技术债会让系统的问题越来越多，新需求实现的速度越来越慢，最后几个看起来不大的需求就足以让团队加班加点，天怒人怨。把这个思路带回到我们现实的需求管理中，你会发现，其实团队面临的各种需求所采用的优先级排序方式，基本上都是按照紧急程度排列的，但它们是否真的重要呢？如果你把这个问题抛给需求的提出者，我几乎可以肯定，他们给你的答案是，他们提出的需求就是重要的。一种可能是，他们也分不清重要和紧急的差别，正如有时候我们也糊涂一样。对于这样的场景，我们要做的就是多问一些问题。
2025-05-15 15:18:57
549
原创 程序员也可以“砍”需求吗？
软件开发中，需求管理是非常重要的一环。在需求管理上常见的错误是，需求管理的粒度太大，很多团队几乎是在用一个大主题在管理需求，这就让需求调整的空间变得很小。结合用户故事，我给你讲了一个好的需求管理基本单位是什么样子的，它要符合“INVEST原则”。其中的一个关键点是“小”，只有小的需求才方便管理和调整。什么样的需求才算小呢？我给你介绍了一种需求估算的方式，每个团队都可以根据自己的特点决定在自己的团队里，多大的需求算大。大需求怎么办？只要再进行分解就好了。
2025-05-15 14:11:15
557
原创 为什么你的测试不够好？
你好！我是郑晔。今天是除夕，我在这里给大家拜年了，祝大家在新的一年里，开发越做越顺利！关于测试，我们前面讲了很多，比如：开发者应该写测试；要写可测的代码；要想做好 TDD，先要做好任务分解，我还带你进行了实战操作，完整地分解了一个任务。但有一个关于测试的重要话题，我们始终还没聊，那就是测试应该写成什么样。今天我就来说说怎么把测试写好。你或许会说，这很简单啊，前面不都讲过了吗？不就是用测试框架写代码吗？其实，理论上来说，还真应该就是这么简单，但现实情况却往往相反。
2025-05-15 14:04:41
1021
原创 一起练习：手把手带你分解任务
简单的做法就是加入一个 filter，在请求到达真正的资源代码之前先做一层过滤，在这个 filter 里面，如果待访问的地址是需要登录访问的，我们就看看用户是否已经登录，现在一般的做法是用一个 Token，这个 Token 一般会从 HTTP 头里取出来。另外，有用户登录，一般情况下，还会有一个退出的功能。另外，对比我们在分解过程中的顺序，你会看到这个完整任务清单的顺序是调整过的，你可以按照这个列表中的内容一项一项地做，调整最基本的标准是，按照这些任务的依赖关系以及前面提到的“完整地实现一个需求”的原则。
2025-05-15 10:56:52
913
原创 大师级程序员的工作秘笈
TDD 在很多人眼中是不实用的，一来他们并不理解测试“驱动”开发的含义，但更重要的是，他们很少会做任务分解。而任务分解是做好 TDD 的关键点。只有把任务分解到可以测试的地步，才能够有针对性地写测试。同样听到任务分解这个说法，不同的人理解依然是不一样的。我把任务分解的结果定义成微操作，它远比大多数人理解得小。我们能将任务分解到多小，就决定了我们原子操作的粒度是多大。软件开发中的许多问题正是由于粒度太大造成的，比如，分支策略。将任务拆小，越小越好。
2025-05-15 10:54:23
540
原创 先写测试，就是测试驱动开发吗？
一些优秀的程序员不仅仅在写测试，还在探索写测试的实践。有人尝试着先写测试，于是，有了一种实践叫测试先行开发。还有人更进一步，一边写测试，一边调整代码，这叫做测试驱动开发，也就是 TDD。从步骤上看，关键差别就在，TDD 在测试通过之后，要回到代码上，消除代码的坏味道。测试驱动开发已经是行业中的优秀实践，学习测试驱动开发的第一步是，记住测试驱动开发的节奏：红——绿——重构。把测试放在前面，还带来了视角的转变，要编写可测的代码，为此，我们甚至需要调整设计，所以，有人也把 TDD 称为测试驱动设计。
2025-05-15 10:48:51
1034
原创 测试也是程序员的事吗？
测试是软件开发重要的组成部分，测试应该是软件开发团队中所有人的事，而不仅仅是测试人员的事。因为软件变更成本会随着时间和开发阶段逐步增加，能在早期解决的问题，就不要将它延后至下一个阶段。在测试问题上，程序员有着天生的优势，会写代码，于是，程序员拥有了一个突出的强项，自动化测试。写测试应该是程序员工作完成的重要组成部分。随着人们对于测试理解的加深，各种各样的测试都出现了，也开始有了测试的分类：单元测试、集成测试、系统测试等等。越在底层测试，成本越低，执行越快；越在高层测试，成本越高，执行越慢。
2025-05-15 10:44:48
851
原创 向埃隆·马斯克学习任务分解
我们从外星人探索和马斯克的火星探索入手，介绍了任务分解在人类社会诸多方面的应用，引出了分而治之这个人类面对复杂问题的基本解决方案。接着，我给你讲了这一思想在软件开发领域中的一个常见应用，分而治之的算法。虽然我们很熟悉这一思想，但在日常工作中，我们却没有很好地应用它，这也使得大多数人的工作有很大改进空间。运用这一思想的难点在于，给出一个可执行的分解。一方面，对复杂工作而言，给出一个分解是巨大的挑战；另一方面，面对日常工作，人们更容易忽略的是，分解的任务要可执行。
2025-05-15 10:42:31
657
原创 程序员工作法
本课程共分为六大模块。有效工作的思考框架篇，为你提供一个可套用的思考框架，帮你在遇到问题时梳理自己真正要做的事情。同时还会给你提供践行这套框架所需的几项基本原则。以终为始篇，从完成的定义、需求的完成、代码的完成、产品特性的完成等几个方面，来帮你明确真正的目标。通过跳出角色、数字校验、沙盘推演等方式确保目标的可行性，让你的每一丝努力都不白费。任务分解篇，通过德雷克公式、埃隆·马斯克、“老虎”伍兹等案例，为你分析任务分解的重要性。通过对测试驱动开发进行完整地了解，让你更好地掌握任务分解的“度”。
2025-05-15 10:39:17
394
原创 迭代0： 启动开发之前，你应该准备什么？
在这一讲中，我给你介绍了迭代0的概念，它是在正式开发迭代开始之前，进行一些基础准备的实践。我给了一份我自己的迭代0准备清单，这份清单包含了需求和技术两个大方面，你可以参照它设计你自己的迭代0清单。根据我的经验，对比这个清单，大多数新项目都在一项或几项上准备得不够充分。即便你做的不是一个从头开始的项目，对照这个清单，也会发现项目在某些项上的欠缺，可以有针对性地做一些补充。设计你的迭代0清单，给自己的项目做体检。
2025-05-15 10:37:05
589
原创 你的工作可以用数字衡量吗？
随着智能时代的来临，人类社会开始逐渐认识到数据的重要性。但我们这群 IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。结合着“以终为始”的思考，如果我们可以在一开始，就设计好测量工作有效性的指标，那么就可以更有目的性地去工作了。而如果我们习惯了用数字去思考，就可以在很多方面让数字帮助我们。我举了几个小例子，比如：基于数据进行技术决策、预先设定系统指标，以及发现系统中的问题等等。希望你也可以把数字思维带到你的日常工作中。
2025-05-15 10:33:15
797
原创 为什么说做事之前要先进行推演？
即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。在动手做一件事之前，先推演一番。
2025-05-15 10:23:11
791
原创 解决了很多技术问题，为什么你依然在“坑”里？
程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。不同角色工作真正的差异在于上下文的差异。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。
2025-05-15 10:17:10
578
原创 精益创业：产品经理不靠谱，你该怎么办？
你好，我是程序员贵哥。前面谈到验收标准时，我们说的实际上是确定性需求，也就是说，我们已经知道了这个需求要怎么做，就差把它做出来了。而有时候，我们面对的需求却是不确定的，比如，产品经理有了一个新想法，那我们该如何应对呢？今天，我们从 IT 行业一个极为经典的话题开始：程序员如何面对产品经理。我先给你讲一件发生在我身边的事。有一次，我们一大群人在一个大会议室里做一个产品设计评审，来自产品团队和技术团队的很多人都参与到这个评审中。一个产品经理正对着自己的设计稿，给大家讲解一个新的产品特性。
2025-05-15 10:14:34
470
原创 持续集成：集成本身就是写代码的一个环节
在软件开发中，编写代码是很重要的一环，但程序员的交付物并不应该是代码，而是一个可工作的软件。当我们在一个团队中工作的时候，把不同人的代码放在一起，使之成为一个可工作软件的过程就是集成。在很长一段时间内，集成都是软件行业的难题，改动量和集成时间互相影响。幸运的是，不同的人在不同的方向尝试着改变，结果，同时加大改动量和集成时间的人陷入了泥潭，而调小这两个参数的人看到了曙光。每日构建作为早期的一种“最佳实践”被提了出来，但因为它基本上都是原则，没有得到广泛的应用。
2025-05-15 10:12:52
618
原创 接到需求任务，你要先做哪件事？
需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。而在比较大的团队中，更是会将一个功能分拆到多个小团队中，每个人看到的只是功能碎片。于是，后来产生了其他的需求描述方式，比如用例和用户故事。在实际的开发过程中，大量的分歧来自于对“需求完成”的定义。当我们把“以终为始”的原则应用在需求领域中，就会注意到，用户故事有一个非常重要的组成部分是验收标准。
2025-05-15 10:10:39
890
Linux系统技术可以学习一下
2024-01-26
播为主播提供一站式直播必备工具 包含弹幕助手、屏幕美化、语音播报、弹幕点歌等主播必备核心功能,目前已支持虎牙、斗鱼,抖音等、平台
2023-10-13
TestSyncMethods.java
2021-07-25
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人