How should I plan out my code base? [closed]

Question

I'm currently working on a project that's about to reach over 5,000 lines of code, but I never really completely thought out the design. What methods should I use to structure and organize my code? Paper and pen? UML diagrams? Something else?

Answer 1

You probably get about as many different views as there will be answers. But here is my perspective.

For starters, 5000+ lines of code is very very small project. Now, how do you go about designing projects that grow. Firstly, you design your system and not a code. Code is actually secondary to the architecture. Start with supporting minimum current requirements. Put some simplistic drawing of components involved. I personally like UML, but anything visual will be good. Ideally, you want to adhere to good design practices here (interfaces, separation of concerns etc).

Once you support minimal requirements in your design, code it. Again, try to adhere to good coding practices.

After that, iteratively add more functionality as new requirements arise. Ideally you want to update your design as well.

What is important, based on my experience, is not to design your system in anticipation of non existing requirements. Otherwise your project will grow very quickly and will get very complex in a short time. Again - adhere to good practices and starts with concrete current requirements.

Answer 2

Flow Diagram, Class Diagram, Use Case Diagram are the must-have diagrams for big projects. Search and select which external libraries you need, and search for any similar open source codes you can use ( to learn & to reduce the time of development ).

I suggest you to buy a whiteboard & some colorful magnets & Post-It. It will help you identifying your tasks.

p.s. 5000+ lines of codes are not "big", though. A CMS / Forum software has way more than 5000+ lines of codes.

Answer 3

I would create package and class diagrams. In the package diagram I would be interested to group classes and interfaces in a logical manner. I would also like to create inner packages etc...

But first you need to think what the program should do . You can create usecase diagrams or do it manually. I do it manually with the class diagram because I prefer to get the code immediately and it is easier to swap to package class diagrams later. Using the class diagram gives me my java. If I don't like it then I manually change it. The new code is automatically updated into my diagrams. I have a visual high level updated representation of my code. Really helpful because even if I code I can always take few minutes to look at the way my project is going in a graphical manner. I just drag and drop entities in the right package manually in order to organize it. I think that my code is better using higher level of abstraction package and class diagrams.

_{(source: ejb3.org)}

some of my colleagues said my way of working is crap.... but I like it :-)

Answer 4

Definitely. I have a small "tablet" dry-erase board to use for this sort of thing, but use whatever you're comfortable with. The important thing is that you can get your thoughts down easily and see the big picture of how everything fits together.

Some people prefer more formal plans, like UML diagrams, but I feel that it's too easy to get caught up micromanaging what each method should look like. Once again, though, use whatever you're comfortable with.

---

EDIT: You might also be interested in literate programming. The idea is that you can plan it all out and gradually get more specific. For example, you might say that your program consists of:

1. Getting text from the user
2. Converting the text into an image
3. Saving the resulting image to the disk

Then you might refine your idea of converting the text into an image. So that might look like:

1. Determine the number of lines the text should take up
2. Pick random colors for the text and background
3. Process it in a suitable format

Then you might refine the idea of picking random colors, and soon you're just writing regular code.

Answer 5

For me, the activity of software development is a series of progressively finer-grained designs to solve a particular problem. When you just have a high-level idea of what you are building, your design might be something very high level, like "there will be a web application that talks to a SQL database and multiple web services" or something like that. Then, as you drill into the details of each piece you get finer-grained in the design. Depending on the complexity of the solution there will be more or fewer iterations of the design effort. The final iteration involves creating the actual code that implements the higher levels of the design.

For me, the difference between architecture and design is minimal, and they are just different iterations of the process I describe above. The line between the two is fuzzy, and different for different people.

There is an art to deciding what level of design detail to go into, for which parts of the application, and at which points in the project lifecycle. For high risk, high complexity projects you may want to have a very detailed design before you ever write a line of code. For smaller projects, you can get away with doing very little up front design and just banging out some code and then seeing what doesn't work and redesigning those areas. There's not just one write answer here. Usually it is somewhere in between those two extremes.

I have a blog post that talks about some of the principles I use when approaching architecture. It might be helpful to you when thinking along these lines. Some of the article is specific to .NET but most of it isn't.

Answer 6

I used to ask myself the very same question. Now I just practice test-driven development, and don't worry about it. I don't "plan out" the code at all, except to follow the standards for the chosen architecture. When I start a project, I do have some idea of what is going to be needed, but as development proceeds I try to keep an open mind. By following test-driven development, and continuously refactoring the code, I don't have to "plan out" the code. I just satisfy one test case after another, and the design emerges from the refactoring. This is always a better design than any plans I could have made before coding.