I'm junior programmer and I would like to know how professionals write their code or which steps they follow when they are creating new software. I mean, which steps they follow, which programming methodology, software architecture design application software, etc. I would like to find a tutorial where they explain from the beginning which steps I have to follow from The Idea I have in my mind to the final version of the application in any language. Or perhaps how is your programming steps or rules that you used to follow. Because everytime I want to create the an application I spend few time on the design and a lot of time coding (I know, that's not good).
I would recommend reading a few books to get started.
A general book about the art, craft, and engineering behind software development is The Pragmatic Programmer: From Journeyman to Master. This book talks about everything from dealing with people to tool support for your development. It covers a lot of ground in a very small package, and I even reread this book from time to time. The advice is applicable to everyone in software development, from the programmer through the project manager.
Rapid Development: Taming Wild Software Schedules. It's the book used in the process and project management course that I took, and it covers a number of major process models and methodologies, when they apply, and commonly accepted best practices for managing projects. However, like most work, it focuses on team projects as opposed to individuals.
On the coding side, Code Complete: A Practical Handbook of Software Construction is a recommended read. It focuses on how to write good, clean code, with concepts that apply to a number of languages. The emphasis is on procedural and object-oriented programming, but the advice can be applied to any language or paradigm.
For designing object-oriented software, the classic texts include Design Patterns: Elements of Reusable Object-Oriented Software and Refactoring: Improving the Design of Existing Code. There are a number of books and resources in this field, and a lot of design decisions are driven by the technologies you are using and the requirements of your project. For software system architecture, a classic text is Software Architecture in Practice which discusses topics ranging from architectural views to product line development. That was the book used in my software architectures course, but some professors were using Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives in its place.
However, you can't just read these books. The important thing is to apply what you have read to your projects at work, school, and at home. You can read all you want, but if you don't apply your knowledge, it's meaningless.
On my projects, a lot of what I do is driven by my goals, either in terms of personal development or the requirements of the project. You aren't going to find a one-size-fits-all methodology or process, so the best bet is to look at commonly used best practices, find out what works for you and your team, and learn from mistakes for future projects.
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: