Software design methods for Java or any other programming language

What I do is to look if a similar project has already be done. It doesn't need to be exactly the same, but something related to my new project.

I reverse engineer the java code into a model and extract UML diagrams to visualize the code. I try to understand how it works and the logic. Once I understand then I redesign what I need and generate again a new java code.

There is no copyright on the code I get because I don't copy the original code of an other project. I only look at the skeleton and generate code from the model. The generated code is therefore clean with no copyright. It does usually over 80% of the skeleton of the first draft design. I don't think this is a nasty behavior saving time doing that !! I can not only reverse .java but also .class code. Or even mix them if more than one project. I immediately get the big picture of the project and can copy what I need.

Finally I put my personal code into this generated code in order to customize it. I think that using an already stable project is a key factor in order to have a good architecture. I am not a genius but it works really well and save me plenty of time. I have realised that because I used an already project, they have usually done an extendable architecture which is really important if you need to evolve your project. If I did have created a structure for only the first requirements I got then I would have been stuck later.

This is a very broad question and I must first say that every company/developer have different methodologies and design processes. So I will only speak for my own personal experience.

The first step is to ask yourself what all the specifications are. Not only do you have to think about the end product, but also about the process and the life of your application after deployment. Are other programmers working on it? If so, you (and your team) might want to develop the entire framework first so each of you can be working simultaneously on different aspects of the application. Is the application going to be extended in the future? If so, you'll need to ensure that you provide a high enough level of abstraction (proper OOP hierarchy, etc) to enable that. Are there going to be 3rd party developers working on extending your application (via plugins, etc)? If so, you must make sure your application is safe and your users are properly protected (making sure your variables/classes are given the appropriate access modifers).

I assume that the actual application specifications are already laid out clearly. If not, you must do that ASAP. There's nothing worse than having a changing specification while developing a large application. Now while you program, you should keep all these ideas in mind (after all, what's the point in figuring all these questions out if you're not going to pay attention).

Next on the list is choosing your technologies and frameworks (if you're using one at all). You don't want to be stuck with doing a large project from scratch. Do a lot of research on the pros and cons of each and evaluate accordingly. Choosing the right framework can mean the difference between a 10 hour long project and a 100 hour long one.

Google is your best friend. If something subtask requires a significant amount of time to code, look it up. I have saved countless hours just by typing in a simple search query and copying+pasting code. Don't plagiarize though, that's bad ;) But don't blindly use other people's code either. Just because it's publicly on the web doesn't mean it's the most efficient piece of code, or the most safe piece of code. Always carefully review what you find.

Now finally when you can't use and reuse every last piece of code you can, then write your own. Make it clean, concise, and efficient. Satisfy all your requirements while making it the best piece of code you can possibly think of. No one likes reading ugly/inefficient code.

Perhaps this is my own pet peeve (though I'm sure it bothers many others), but please format your code nicely and consistently. Coding can be an art, do me a favor and don't make it look like you typed it up with your hands tied behind your back.

Some of the methodologies I've seen used a lot:

• Code & Fix. You code something. If it doesn't work, you change something. You keep doing this until it works well enough to fool management that it's done. This is "Agile" development at its worst: "what is the minimal amount of work I can get away with?". Needless to say I'm not a fan of this methodology - but you may recognize it from your colleagues or yourself on a bad day! It's very hard to get any productive work done if you don't already know exactly what you are aiming for in the end result.

• Throwaway prototyping. You start by getting your feet wet using the code & fix mentality, with one extremely important difference. From day 0 you know that you will throw away this code & fix prototype once you know enough to do it "right" or at least a lot better than the first time. This is a very useful methodology for very new technologies, algorithms and unknown problems. The biggest difficulty is to have the self-discipline to actually throw away the prototype and start from zero. You might think this method takes twice as long, but it really does not: once you know how to do something you need less time to do it. You still need to know somewhat what you are aiming for, but you can try a few different prototypes just to pin down exactly what works best.

• Big Design Up Front. If you do projects for the army, the government, NASA, the medical field, or organizations in love with CMMI L5, you will recognize this. Everything is specified in minute detail in documents and specifications before any production code is written. This works well if you can get everything right from day 0 and no requirements change. In almost all cases something will change though, so you may find a lot of the big design effort was premature. If you have document for regulatory purposes then obviously you have to, but there are always ways to have "just enough" design and documentation before you start actual coding. Upside: at all times you are able to know exactly what your end goal is, if you can still find it in the piles of paperwork.

• Just enough design up front - my most often used method. A lot of the things I do aren't novel enough to require throwaway prototyping, but I don't want to get stuck in Big Design Up Front and waste a lot of effort, nor do I want to code & fix my way through the day and end up with a cobbled-together "design" that I actually hate. So I take the usually underspecified requirements, and work out some designs on paper, or in some kind of design tool (can be UML diagrams in Enterprise Architect, or just drawings in Paint Shop Pro). I discuss these with the people responsible for the requirements until I get the feeling that I know what they need. Do not focus on what the customer asks, and not even necessarily what they want, figure out what they need and how you can best provide it. Then you write your first version in code - not quite a throwaway prototype (if you are on the money, you'll want to continue working on it), but not polished to total perfection either (because you might still be wrong). Present your version, and poll the reaction of your customer. Either continue polishing, or try another avenue if it's not really going where it needs to.