Best way to break down overwhelming code into manageable chunks?

Question

I'm continually becoming overwhelmed by large projects, once they reach a certain level of complexity. Once I reach a certain point in a project, my progress slows to a crawl and I find myself constantly retracing my steps and sorting out all kinds of confusion.

I've gotten really good at refactoring due to this weakness of mine. And I always try to decompose my objects into smaller, more manageable ones. This weakness has also probably caused me to pay too much attention to designing things properly.

I know if I can break my problems down into smaller ones, I'll be able to accomplish smoothly. One strategy that comes to mind is test-driven development. What else can I do?

Answer 1

stop thinking about the code

start thinking about layers, features, modules, services, and other higher-level abstractions

you're getting overwhelmed because you're thinking at too low a level

Answer 2

Making the complex simple is easy; wait think it's the other way around.

Everyone struggles with this, there is no straightforward solution that has extreme effectiveness.

Since you didn't list this in your questions, my suggestion would be to:

Focus on functional cohesion via:

Single responsibility principle states that every object should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

If you Google it among the results on the first page you'll find two great resources:

• "Single Responsibility Principle" by Robert C. Martin (Feb/2002): This principle discusses the need to place things that change for different reasons in different classes.
• "Curly's Law: Do One Thing" by Jeff Atwood (Mar/2007): The Single Responsibility Principle says that a class should have one, and only one, reason to change.

What is cohesion in computer science?

Cohesion is a measure of how strongly-related or focused the responsibilities of a single module are. As applied to object-oriented programming, if the methods that serve the given class tend to be similar in many aspects, then the class is said to have high cohesion. In a highly-cohesive system, code readability and the likelihood of reuse is increased, while complexity is kept manageable.

Cohesion is decreased if: - The functionalities embedded in a class, accessed through its methods, have little in common. - Methods carry out many varied activities, often using coarsely-grained or unrelated sets of data.

Disadvantages of low cohesion (or “weak cohesion”) are: - Increased difficulty in understanding modules. - Increased difficulty in maintaining a system, because logical changes in the domain affect multiple modules, and because changes in one module require changes in related modules. - Increased difficulty in reusing a module because most applications won’t need the random set of operations provided by a module.

If you have any questions, let me know.

Answer 3

Decompose features into the smallest possible item. For example, a single field on a form. Pick the most risky or high priority one and move forward like it's a simple bug fix, not a big project. It's true that you'll end up with some refactoring later on, but at least you'll be moving forward.

Answer 4

From my experience you've answered your own question with the comment about TDD. For me I often felt the same as you, early fast success quickly turned into being bogged down on minor details once the system hit a certain size. I found with TDD it helped because you could tackle each part of the system as small chunks, knowing that the rest of the system would or should continue to work as you left it. I think also, with TDD it helps in making sure your system is clearly split into smaller chunks that are independently testable.

Answer 5

Some people are good at designing modular, easily understandable programs, but the majority of programmers lack this facility, to a lesser or greater extent. I know of know of no book, procedure or practice that can turn one of the first type of programmers into the second, except possibly for lots of experience. But I'm not even sure about that.

The bottom line is that most programmers will struggle to rise above the mediocre, some few will manage to be OK (which is where I would place myself and perhaps 50% of the professional programmers in (say) the IB industry), and a very small minority will be excellent. I should say I have never in my long career met one of these excellent ones :-)

Answer 6

I think a lot of people try to over-engineer solutions. They take the "Adam&Eve" approach when just a slightly more practical one would simplify things by a great deal.

Specialized classes are not evil, they're the natural consequence of sound software design.

Many programmers, in my opinion, fail to understand this and there is no book that I know of which makes this outright clear.

Another thing that certainly helps is TDD, that lets you understand "how" you will be using the class in practice and can in many cases save the day, because it shows eventual problems/limitations early on in the day.

Last, another VERY important thing I would look for if I was you is design patterns. Design patterns are how people smarter than you or me solve programming problems. The idea behind patterns, guess what?, is that they're not to be used as cookbooks, recipes that you just slam there, but thoughtfully and understanding your application domain first and foremost.

A wise use of pattern will reduce greatly the quantity of details you have to manage.

A good design pattern library designed around your very needs, will prove invaluable. Let's see a very simple example just to put things in context:

imagine you have a form where, when a button is pressed, other forms have to update themselves. This is a typical "observer" pattern. You have a subject and several observers, which register them selves with the subject. Why do you need to implement an interface? You can just add the methods, or better yet, use an interface for the observers and a generic list for the subject. Now you got the best of both worlds: independence for the observers and no whuzzy-whazzy things on the subject.

Hope it makes sense to you!

Andrea

Answer 7

The problem of dev speed and readability may come when we overlook the need for abstraction. In some of the large code bases I have worked, the single most common enemy was the umpteen amount of specialized classes that have very similar functionalities that cause the code to bloat. If we take a step back and understand the requirements as a whole not as parts of the application, then lots of abstractions will come to our mind.

Some simple steps which has helped me

• Use similarity analyzer (like Simian) to find duplicate code blocks across the code base. Lots of duplicate code means less abstraction.
• Monitor the size of classes and methods, large classes and methods mean few services or controllers becoming gods.
• Make unit/integration tests mandatory, gives you the confidence to refactor and also acts as a specification.
• Fortnightly retrospective with the business to understand if the technical/business/domain terms they use are reflected in the class names. This helps in understanding and getting names for first class collections instead of representing as simple sets and lists. Some abstractions which we never thought about will also surface when we sit down with the business people.