this post was submitted on 28 Oct 2023
13 points (93.3% liked)

Programming Books

300 readers
1 users here now

Links are disabled in this community by default! If you have a resource you feel should be whitelisted feel free to dm a mod (that isnt a bot)

Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 1 year ago
MODERATORS
 

Messy code is a nuisance. "Tidying" code, to make it more readable, requires breaking it up into manageable sections. In this practical guide, author Kent Beck, creator of Extreme Programming and pioneer of software patterns, suggests when and where you might apply tidyings to improve your code while keeping the overall structure of the system in mind.

Instead of trying to master tidying all at once, this book lets you try out a few examples that make sense for your problem. If you have a big function containing many lines of code, you'll learn how to logically divide it into smaller chunks. Along the way, you'll learn the theory behind software design: coupling, cohesion, discounted cash flows, and optionality.

This book helps you:

  • Understand the basic theory of how software design works and the forces that act on it
  • Explore the difference between changes to a system's behavior and changes to its structure
  • Improve your programming experience by sometimes tidying first and sometimes tidying after
  • Learn how to make large changes in small, safe steps
  • Approach software design as an exercise in human relationships
you are viewing a single comment's thread
view the rest of the comments
[–] canpolat@programming.dev 3 points 1 year ago

Kent Beck presents some of the concepts discussed in this book in his conference talk: A Daily Practice of Empirical Software Design (Domain-Driven Design Europe 2023)

I was a bit underwhelmed by the content until part 3 where he delves into the theoretical grounds for planning "tidyings". He leans on economics to discuss when the best time is for making a refactoring. I find making that connection valuable. But the way concepts are explained are not very clear, in my opinion. I didn't think of this book as "well-written" in general. And despite the claims in the beginning of the book, I don't think a senior engineer has much to learn from it (not from the first two parts, anyway). Perhaps, part 3 should have been a separate book. That would be an interesting read with clearer and more detailed explanations, some anecdotes and examples.