I want to know the approach in developing big complex application regardless of which programming language to use. I want to know how developers make such big applications such as internet banking, API's and big database management application. How should one approach to make such applications. I have only 1 year programming experience so far and I work as a freelancer so when I saw such applications lots of questions came in my mind. How to understand the basic need of information technology. What actually it is? How it can be useful for common people of small towns. I want everyone to make use of technology no matter they are educated or not, rich or not. Please post some suggestions.
In one word: Modularity.
You build large software systems by composing them from smaller building blocks. You do that by using techniques such as Object Orientation. Each object is a complete, testable software unit in its own right. When combined, each of these objects communicates messages between itself and other objects, creating a complete, coherent system.
Getting good at this takes awhile, because you have to figure out what each object is responsible for, and how it fits in with the rest of the system.
Think about how a car is built. A car is a system, composed of smaller subsystems like the engine, the electrical and fuel systems. The engine, in turn, is built up from components like the pistons, crankshaft and valves, and it is supported by an ignition system, a cooling system and a lubrication system. The ignition system has spark plugs, wires, a coil, etc. While the entire system is enormously complex, nothing is particularly difficult to understand if you look at its components, and how they work together.
Software works the same way. You have methods, variables and keywords inside classes. You instantiate objects from these classes. You have objects that are factories that can create other objects, objects that manipulate collections of other objects, object that act as proxies, and so forth.
You learn how to build these larger systems by learning how to write smaller programs (or smaller parts of larger systems) first, and then combining those smaller parts into larger systems.
What you're talking about are the concepts of Software Engineering. It's difficult to really condense all you need to know into a single SO comment, when there are series of books written on the subject and it is indeed a field of its own. Here's some books you can look into to get you started, and coupled with your education should set you on the right path:
First of all you should Ignore Coding until you fully understand the Requirements.
The phases of software development
Requirement Analysis : is the very first phase of project development and the most important one. You need to write down what is the requirement of the client, the users and the project itself. Take as much time as you want before proceeding to the later stages. Because if this phase is misunderstood, you might need to run back and from between phases
Design & Architecture : This is the phase where you put your requirements at work. Draw sketches of application flow, pen down the algorithms for carrying out functions. Make a nice wireframe or outlining as to how the application will look. In short consider how every requirement will be met and foreseen. Also, a good designer or architect will take into account the future expansion so you should consider that too
Coding : The part where the results can be seen. Choose any language you are comfortable with and start coding. Coding is not the hardest part and need not take as much time as Analysis or designing but this is the part you, your users and clients are concerned with. Write code as neat as possible applying different coding practices and make sure your leave less spots for the testing phase to clean up
Testing : Last but not the least important phase. Testing mostly takes more time than coding because you test your code against all circumstance ranging from user input to load performance. A thorough testing will always lead to a better product
This is a very wide question, with no one ready-made answer. I'll try to answer nonetheless, but my answer will be as vague as the question. I'll assume nonetheless that you are asking about how to build a large app on your own or with a colleague. Large teams are something totally different.
- Careful Planning: List everything the app needs to do, trim the unneeded. Then trim gain. Keep trimming. Also, list all the tasks you have to do and break them in sub-tasks
- Plan everything in different sections. I do it in this order:
- I list all the main "objects" of my app. For example, books, pages, authors, users, with their properties, relations, and actions
- I do the database design
- I design the roles of the users, implement this in my "objects" sheet and my "database design" sheet
- I describe all the main classes I will need, in quick pseudo-code
- I wireframe the design (quick sketches)
- I create a quick mockup with as little code as possible, as functional as possible
- If you are on your own, you will want to keep the whole process loose and sketchy. Allow for changes, specially early on. You will NOT think of everything, so leave room for all the things unplanned that you will stumble on on the way.
- To that effect, create you app in a modular way, with components as decoupled as possible. This makes it easier to maintain, debug, and test. I learned this the hard way as I was creating a monolithic framework, stopped working on it for a few weeks, then was totally lost in my own code. So think "plugins"
- Begin with the bare essential, test, let your friends use it, see what's needed, analyze, dig out the few essential features, implement. Rinse and repeat.
- Read getting real by 32 signals.
- Have some sort of version control. I personally like mercurial, but whatever is fine. Just have one.
- Test different languages, don't get stuck on one. Pick one functional, one object-oriented language, you will learn from each.
- Stick to a language until you master it completely (contradictory yeah I know). When you will want to create mockups, begin with this language, at least you will be able to work fast.
Above all, read, read, read, and apply, apply, apply, create your own stuff and push forward for more optimized code, better standards, and whatever the language you choose, try to push it to the max. And don't listen to the "don't reinvent the wheel" thing. DO reinvent the wheel, just not when you are working for a client. If you are on a professional project, use whatever you can to make it work. But on your personal projects, build everything from the ground up. Then look up the source of similar projects and see how they did it.
Then throw everything away because what you did is most likely going to be crap the first 100 times. Rinse and repeat.
Practice makes somewhat better, after a few years (2 to 4), you should be able to manage even a very large project by yourself. But you have to be wanting to do it from day one. If you only try to build little stuff for 4 years, you won't get there.
Try to manage to have a life beside all that, because fresh air, friends and going out make it all better.
There are different kind of complexity, usually two types, a complexity caused by the addition of stuff that doesn't strictly belongs to our purpose or the nature of what are you doing ( like when you add some lines of code later on just to add some functionality that you didn't have planned to give to your app ), and what is usually called "the complexity of engineering" that means that the system that you have to design probably requires a lots of elements and many connections between those just to run.
The thing is that you can't really face this kind of problems without a solid base that only a college degree can give to you. We are talking about an intensive use of the math, basic and high level notions about both the hardware and the software.
What you can easily understand is the use of some good companion like the UML language that is really useful and powerfull especially during the design process, without talking about any specific languages you just can have a big picture in front of you. Other good things are the versioning systems like Mercurial and Git that are especially used when you are working in team with other people, you can also browse every IDE is made for your language and decide what is the most appropriate for your needs.
But this are only tips, you have to build your know-how reading some books and applying something in the real world, a good book for a start can be one about algorithms and data structure.
A good language to start from is Java, a good Java project with a good design can be Android with its own system classes; try to learn Java and analyze the design of this big project in UML to begin to understand what it's like to design a very big project and what you have to care about. The design it's all about how different languages can have the same business logic and what the user is allowed to know and do, and with some languages you also have to care about some performance issues but this is something that you can learn in a college not on the internet.
I would have a look to an existing similar project and see if it works well. You do't need the full code but java executable jar file could also be reversed. Be aware you are not allowed to reverse jar file in US, but you can do it in Europe and other countries so..
If the architecture is ok, then copy the static architecture (e.g. package, classes etc....) and then just code the business rules. A good start is to reverse engineer the existing project into an UML model and then generate again the code in java. There is no more code copyright if you do that.
Once you have a static architecture you check if the requirements are possible and add new classes at class diagram level. You show your class diagram to the project manager and talk about the architecture. Once this is validated then you start codding. After the first stage codding you show the class diagrams and a small demo and ask the project manager if it is ok. You take into consideration his demands. You always use a graphical representation of your code in order to get all the team involved in decisions and possible changes.
One more iteratiion, class diagrams updated with a code merge and manager demo. Change again and again. After few week it will almost be perfect and everybody will be happy :-)
Your question is a big question include many aspect. But I think the first you should be understand good and bad which each language and what`s situation best of this language using. And then according to business requirement to decide which language you could use. And next you should be understand this language about detail.