Praise for Tidy First? 对《整洁优先》的赞誉

Kent Beck is always worth listening to, and I have been waiting for the advice in this book for several decades now. This book helps to move the focus in software away from the tools and technology, and firmly onto what really matters, design! Design is about the shapes we paint with our code, and Kent helps us to paint better shapes. This is an important book on an important topic.

肯特-贝克（Kent Beck）总是值得一听，几十年来我一直在等待这本书中的建议。这本书有助于将软件的重点从工具和技术转移到真正重要的设计上！设计关乎我们用代码描绘出的形状，而 Kent 则帮助我们描绘出更好的形状。这是一本关于重要主题的重要著作。

Let’s be honest: 99% of a software engineer’s job involves working on brownfield projects. This can be difficult, especially if the code wasn’t written with readability in mind. In this book, Kent Beck turns things around by prioritizing human relationships through code. He succinctly teaches how to improve software design with small, gradual changes, thereby making the code clearer for both you and your colleagues.

Vlad Khononov, author of Learning Domain-Driven Design

老实说，软件工程师 99% 的工作都涉及到 “棕地 ”项目。这可能很困难，尤其是在代码编写时没有考虑到可读性的情况下。在这本书中，肯特-贝克通过优先考虑代码中的人际关系来扭转局面。他简明扼要地传授了如何通过微小、渐进的改动来改进软件设计，从而让你和你的同事都能更清晰地理解代码。

Vlad Khononov，《学习领域驱动设计》作者

Preface 前言

What Is Tidy First?

“I have to change this code, but it’s messy. What should I do first?”

“Maybe I should tidy the code before I make the change. Maybe. Some. Or maybe not?”

These are questions you might ask yourself, and if there were easy answers, I wouldn’t have felt the need to write a book to address them.

Tidy First? describes:

  • When to tidy messy code before changing what it computes
  • How to tidy messy code safely and efficiently
  • How to stop tidying messy code
  • Why tidying works

Software design is an exercise in human relationships. In Tidy First? we start with the proverbial person in the mirror—​with the programmer’s relationship with themself. Why don’t we take time to care for ourselves? Take time to make our work easier? Why do we go down the rabbit hole of cleaning code to the exclusion of work that would help our users?

Tidy First? is the next step in my mission to help geeks feel safe in the world. It’s also the first step to take when faced with messy code. Software design is a powerful tool to ease pain in the world—​if it is used well. Used badly, it becomes just another instrument of oppression, and a drag on the effectiveness of software development.

Tidy First? is the first of a series of books focusing on software design. I want to make software design approachable and valued, so I’m starting with the kind of software design you can do on your own. Subsequent volumes will apply software design to heal relationships between the programmers on a team, and then address the biggie: the relationship between business and technology. But first, let’s understand and practice software design in ways that benefit our daily work.

什么是 “整洁优先”？

“我必须修改这段代码，但它太乱了。我应该先做什么？”

“也许我应该先整理代码，然后再做修改。也许。有一些。还是不呢？”

这些都是你可能会问自己的问题，如果有简单的答案，我就不会觉得有必要写一本书来解决这些问题了。

先整理？

  • 在改变代码的计算内容之前，何时整理杂乱无章的代码？
  • 如何安全高效地整理杂乱代码？
  • 如何停止整理凌乱的代码？
  • 整理为什么有效？

软件设计是人际关系的练习。在 “先整洁吗？”一书中，我们从众所周知的镜子中的人–程序员与自己的关系入手。我们为什么不花时间关心自己？花时间让我们的工作更轻松？为什么我们只顾着清理代码，而忽略了对用户有帮助的工作？

整洁优先？ 是我帮助极客在世界上获得安全感的下一步任务。这也是面对凌乱代码的第一步。如果使用得当，软件设计是减轻世界痛苦的有力工具。用不好，它就会成为另一种压迫工具，拖累软件开发的效率。

整洁优先？ 是以软件设计为主题的系列丛书的第一本。我想让软件设计变得平易近人并受到重视，因此我将从你自己就能完成的软件设计开始。随后的几卷将把软件设计应用于团队中程序员之间的关系，然后再讨论最重要的问题：业务与技术之间的关系。但首先，让我们以有益于我们日常工作的方式来理解和实践软件设计。

Why “Empirical” Software Design?

The loud debates in software design seem to be about what to design:

  • How big should services be?
  • How big should repositories be?
  • Events versus explicit service invocation.
  • Objects versus functions versus imperative code.

These what debates hide a more fundamental disagreement among software designers: when? Here’s a caricature of the poles of this disagreement:

  • Speculative design We know what we want to do next, so let’s design for it today. It will be cheaper to design now. Besides, once the software is in production we will never have the chance to design, so let’s pile it all in today.

  • Reactive design Features are all anyone cares about, so let’s design as little as we can today so we can get back to features. Only when features become nearly impossible to add will we begrudgingly improve the design, and then only just enough to get back to features.

I aspire to answer the question of “when?” with “somewhere in the middle.” When we observe that a certain class of features is hard to add, we design until the pressure is relieved. We start with just enough design to get the feedback cycles going:

  • Features What do users want?

  • Design How can programmers best be supported to deliver those features?

The empirical software design answer to the question of when is contingent. Design some time around when you can take advantage of the design. Answering this question requires taste, negotiation, and judgment. Is requiring taste and judgment a weakness? Sure, but it’s an inevitable weakness. Speculative and reactive design also require judgment, but they give software designers fewer tools to work with.

I like the word empirical to describe this style because it seems to clarify the distinction I’m making with speculative and reactive design timings. “Based on, concerned with, or verifiable by observation or experience rather than theory or pure logic.” Sounds about right.

为什么要进行 “经验型” 软件设计？

软件设计领域的激烈争论似乎是关于设计什么：

  • 服务应该有多大？
  • 资源库应该有多大？
  • 事件与显式服务调用。
  • 对象与函数还是命令式代码。

这些争论掩盖了软件设计师之间更根本的分歧：何时？下面是这一分歧的两极漫画：

  • 投机性设计 我们知道下一步要做什么，所以现在就设计吧。现在设计成本更低。此外，一旦软件投入生产，我们就再也没有机会进行设计了，所以我们今天就把它全部设计出来吧。

  • 反应性设计 功能是所有人都关心的问题，所以我们今天能少设计一点就少设计一点，这样我们就能回到功能上来。只有当功能几乎无法添加时，我们才会勉为其难地改进设计，但也只能改进到足以恢复功能的程度。

我希望用 “中间某处” 来回答 “何时” 这个问题。 当我们发现某一类功能很难添加时，我们就会进行设计，直到压力得到缓解。我们从足够的设计开始，让反馈循环运转起来：

  • 功能 用户想要什么？

  • 设计 如何为程序员提供最好的支持以实现这些功能？

对于 “何时” 这个问题，软件设计的经验答案是 “或然性”。设计时要考虑到何时可以利用设计的优势。回答这个问题需要品味、协商和判断。需要品味和判断力是弱点吗？当然，但这是不可避免的弱点。投机性和反应性设计也需要判断，但它们给软件设计师提供的工具更少。

我喜欢用 “经验” 这个词来形容这种风格，因为它似乎可以澄清我对投机性和反应性设计时间的区分。“以观察或经验而非理论或纯粹逻辑为基础，与之相关，或可通过观察或经验进行验证”。听起来差不多。

How I Came to Write Tidy First?

As an undergraduate I took a course on software design that used the book Structured Design by Ed Yourdon (RIP) and Larry Constantine. I didn’t understand much of the book, mostly because I hadn’t yet encountered the problems it addressed.

Fast-forward 25 years to 2005. I had designed a bunch of software by this time. I felt like I had a pretty good grasp on design. Stephen Fraser organized a panel at OOPSLA (the big object-oriented programming conference) to celebrate the 30th anniversary of the publication of the book. Ed and Larry were to be on the panel, along with Rebecca Wirfs-Brock, Grady Booch, Steve McConnell, and Brian Henderson-Sellers.

If I didn’t want to get blown off the stage, I had some homework to do. So I cracked open my yellowing copy of Structured Design and started reading. Hours later I looked up, absolutely enthralled. Here were Newton’s laws of motion, but for software design. It was all so clear when it came out. How did we as an industry forget that clarity?

I remember the panel going well. A highlight of the conference was breakfast with Ed and Larry, two extremely bright guys completely comfortable with themselves and each other. Figure P-1 shows the signatures they left in my textbook long ago.

我是如何写出《Tidy First》的？

本科时，我选修了一门软件设计课程，使用的是 Ed Yourdon (RIP) 和 Larry Constantine 合著的《结构化设计》一书。我不太理解书中的内容，主要是因为我还没有遇到过书中提到的问题。

时间快进 25 年后的 2005 年。此时我已经设计了很多软件。我觉得自己对设计已经有了很好的掌握。斯蒂芬-弗雷泽（Stephen Fraser）在 OOPSLA（大型面向对象编程会议）上组织了一个小组，庆祝这本书出版 30 周年。Ed 和 Larry 将与 Rebecca Wirfs-Brock、Grady Booch、Steve McConnell 和 Brian Henderson-Sellers 一起参加讨论会。

如果我不想被轰下台，我还有一些功课要做。于是，我翻开泛黄的《结构化设计》开始阅读。几个小时后，我抬起头，完全被吸引住了。这里有牛顿的运动定律，但却是针对软件设计的。当这本书问世时，一切都如此清晰。作为一个行业，我们怎么会忘记这种清晰性呢？

我记得小组讨论进行得很顺利。会议的一大亮点是与 Ed 和 Larry 共进早餐，他们是两个非常聪明的人，对自己和对方都非常自在。图 P-1 是他们很久以前在我的教科书上留下的签名。

Inscriptions by Ed Yourdon (“Don’t believe anything you read in this book!”) and Larry Constantine (“…​including the above!”)

Ed Yourdon（“不要相信你在这本书里读到的任何东西！”）和 Larry Constantine（“……包括以上内容！”）的题词

The book was showing its age by that time. Examples using paper tape and magnetic tape were no longer relevant. Nor was the discussion of assembly language versus the new higher-level languages. The basics, though, were spot on. I vowed that I would bring that material to today’s audience.

I made several abortive attempts to write a software design book in the intervening years (search for “Kent Beck Responsive Design” if you want to see what I was up to). It wasn’t until 2019 that I unexpectedly had two weeks of completely unscheduled time. I decided to see how much of the book I could write in those two weeks.

当时，这本书已显老态。使用纸带和磁带的例子已不再适用。关于汇编语言与新的高级语言的讨论也不再适用。不过，书中的基础知识还是很到位的。我发誓要把这些材料带给今天的读者。

在那之后的几年里，我曾多次尝试编写一本软件设计书籍，但都以失败告终（如果你想知道我当时在做什么，请搜索 “Kent Beck Responsive Design”）。直到 2019 年，我意外地拥有了两周完全计划外的时间。我决定看看在这两周里我能写多少书。

Ten thousand words later, I had learned an important lesson—​I wasn’t going to be able to tackle all of software design in one book. One scenario that kept coming up in what I had drafted was this moment of small-scale design: I have some messy code—​do I change it or do I tidy it first?

My book-writing experience has always been like this. Take a topic that seems too small for a book. Write. Discover the topic is way too large for a book. Take a tiny, too-small slice. Write. Discover the slice is too large. Repeat.

And so here you hold (virtually or for real) the first fruits of that now nearly 20-year-old vow. I found that in discussing that hourly question, “Should I tidy first?” I have been able to touch on many of the topics dear to my designer heart. I look forward to your feedback and to continuing to deepen my understanding of all that makes software design fun and valuable.

一万字之后，我学到了一个重要的教训–我无法在一本书中解决所有的软件设计问题。在我起草的过程中，有一个场景不断出现，那就是小规模设计的时刻： 我有一些乱七八糟的代码，是先修改还是先整理？

我写书的经历总是这样。选一个对一本书来说似乎太小的主题。写。发现这个主题对一本书来说太大了。取一个太小太小的片段。写。发现切口太大。重复。

现在，你手里拿着的是（虚拟的或真实的）这个近 20 年誓言的第一批成果。我发现，在讨论 “我应该先整理吗？”这个每小时都会提出的问题时，我能够触及很多问题。我已经触及了我设计师内心深处的许多话题。我期待着您的反馈，期待着继续加深我对软件设计的乐趣和价值的理解。

本文由笔记整理发布