185: Refactoring for Clearer Design and Single Responsibility Methods

Refactoring, TDD and the relationship with Object-Oriented Design

Thank you for reading Snippets of Text. Snippets from media about tech, programming, parenting, and more. This is a preview of a post available exclusively to paying subscribers. You can get unlimited access to all articles by purchasing a subscription.

Unrelated: How to Balance Design and Development

The Design Stamina Hypothesis compares teams' productivity with and without design work. It consists of two axes: cumulative functionality on the vertical axis and time on the horizontal axis. Investing more time in design early on may be beneficial to ensure a clear understanding of the app's purpose. Yet, the hypothesis assumes developers know when to stop designing and start building, which is a flaw. Developers focus on finishing projects instead of considering future changes. The Design Stamina Hypothesis should focus on setting clear goals for when to focus on design. It's important to note that developers are designing whether and the cost of quality should be considered.

The cost of Object-Oriented Design can increase due to a need for more information and writing to support future guesses. Indirection is the mechanism by which we reduce the complexity of interdependence—the most impactful code changes. Tools like Code Climate can highlight these areas in our code base, analyzing and comparing churns and quality. Business priorities often cause the most strain on engineering teams. To increase profits, we should simplify the business's most significant aspects. Thus, to keep an application healthy is essential always to refactor and apply design when introducing new changes. 

[^]: Practical Object-Oriented Design: An Agile Primer Using Ruby

Off Topic: TDD's Advantage in Experimentation

Every line of code we write is a decision we make. TDD helps us confirm those decisions by providing feedback. We make design decisions, and TDD allows us to get feedback. Testing is about confirmation, not affirmation. 

The focus should be on achieving business outcomes rather than writing elegant code. Thus, the time spent writing a test should be proportional to confirming information about a particular problem. TDD has an advantage over other approaches because it allows us to experiment with many solutions for the same problem in less time. Yet, it's important to consider the trade-off of testing only essential application pieces. This trade-off is not worth it, as the business's success depends on being flexible and accommodating to customers' needs. For ambiguous problems, by confirming our decisions one step at a time. This helps us gather evidence to support our conclusions as we write them. TDD allows us to explore different scenarios and clarifies our thinking about what is essential and workable. I prefer an inductive approach that moves from specific examples to generalizations. The benefit of this workflow is its ability to divide and conquer. Working on smaller sections of code is much easier than tackling a large amount of code or an entire system. The approach's robustness comes from confirming intermediate steps toward a solution. 

[^]: Clean Agile: Back to Basics

Current Work: Refactoring for Clearer Design and Single Responsibility Methods

Ruby provides an easy way to differentiate between data structure and meaning. You can wrap an instance variable using a method or the Struct class to wrap a structure. The official Ruby documentation (http://ruby-doc.org/core/classes/Struct.html) suggests that Struct is useful for bundling several attributes and creating accessor methods without writing a separate class. It's essential to ensure that methods have a single responsibility, making them easy to change and reuse. This involves asking questions about their job and summarizing their duties in a single sentence. It's also recommended to hide data from oneself to protect the code from unexpected changes. Data often have behavior that may not yet be known, so it's best to send messages to access variables instead of thinking of them as data; it's best to keep this knowledge in one place.

I appreciate you taking the time to preview Snippets of Text. If you find my work useful, subscribe to the paid version. This will enable me to continue generating fresh and innovative ideas for your benefit.