How do all the different programmers working on the same piece of software arrange all their different lines of code together to form the finished working product?
In: Technology
There are two important factors here:
First, the code is designed to be modular, like puzzle pieces fitting together. Each programmer is responsible for a different part of the code, and they work together to design an interface by which the different components will interact with each other. Then, each programmer can work on their own code separately. Sometimes of course two programmers will be working on the same code together, in which case they will often physically sit together and write the code together (known as [pair programming](https://en.wikipedia.org/wiki/Pair_programming)).
Secondly, source code management (aka version control, aka source control) such as Git. This software lets multiple programmers work on the same code together. Each programmer has their own copy of the code on their computer, and there’s a version of the code on a shared server. Whenever one of the programmers makes a change, they can *push* the change to the main code on the server, and then the rest of the programmers *pull* the changes to their computers. If there is a conflict in the code between the different programmers, then they must *merge* the code before pushing it to the server.
Most teams use what’s called a Version Control system which tracks individual changes to files (called “deltas”). When one programmer makes a change they push it to the VCS, the next programmer then either accepts that delta into their code and merges the two together then pushed the new version, or they ignore and overlay the version in VCS with their version. The exact process of how that happens is dependent on the mechanism of the specific VCS.
With every change pushed to the VCS the code should compile and deploy to a test environment (either a local server/PC, or a remote server/PC) at which point it is tested. Any defects/bugs are reported back to the programming team to fix, then they push the fix to VCS and the process happens again until the software is ready to be deployed/delivered to the customer.
Source: Am a DevOps Engineer
The above answers are good, but to get a little more on the 5 side…
Modern software works like Lego kits: there are some very common pieces, and some really odd and interesting pieces, but they all have specific ways of fitting together so you can build big things out of them.
Like those Lego Death Stars and Star Destroyers can have thousands of pieces, modern software can have thousands of tiny pieces of code.
Because you’re building something big, imagine you make a game out of it. You have a bunch of people helping, so you each take turns: you look at the plans, you figure out which piece makes sense to place next, you place a piece or two, and then you pass to the next person to do the same things. Each person can check the work done by the others, so everyone can see and agree that they’re on the right track. Occasionally people might quibble over which part to build next, or maybe to replace the grey and boring bricks in this section with something more brightly colored and interesting, even if it’s not in the plans. And that’s okay, as long as everyone agrees to it.
As you begin to trust the people you’re working with, you might change the rules of the game a bit. Maybe you have someone go off on their own to build an entire section at a time. When they come back, everyone can look at it to see if it’s close enough to the plans – so they don’t have to waste time checking every brick, but they can see the finished part all at once. And maybe you decide as a team that one component is going to be too hard or too boring to build, so instead you get someone outside of your team to do it for you. Or, if that particular section is sold pre-built on eBay, maybe it’s worth the money to just buy it, so your team can focus on the more fun or interesting parts.
The takeaway here is that while modern software is built of thousands of tiny bricks, you’re never just using the bricks at once. You’re putting together a few bricks at a time and checking your work as you go. So it’s not nearly as big a deal as it seems when you’re looking at the result.
Imagine if multiple people had to write a book together.
First, you would have to agree on the overall theme of the book, and the overarching themes, then you would have to figure out an outline for the book and a table of contents for the different chapters.
Once you agree on the general concepts, then you can split off and different people can write the different chapters.
The key is making sure that two people aren’t writing the same thing at the same time.
This requires coordination and communication.
After the basic stuff is laid out, then minor tweaks and edits can be done by anyone, and it doesn’t matter that much if two people are fixing the same missing comma or whatever.
It becomes a problem if someone wants to move an entire chapter or reorganize the structure of the book. That would require a lot of coordination beforehand.
The easiest way is to divide work into chunks that can be completed separately. Maybe one developer works on one web page and another works on a different page. Or one works on server code while the other does web code. However it is split, we generally make changes on our own and when we’re satisfied with our progress, we get a copy of the other person’s changes and merge everything together.
If everyone’s work is separate enough, you won’t run into conflicts. If there are conflicts, the best way to resolve them is to get a good understanding of the other person’s changes and then collaborate on resolving the conflicts until everything works.
We also use software tools to help us visualize changes and coordinate work into separate efforts on different versions of the code that can be merged together when needed. This is called source control. It’s essential for high-perfoming teams. It also gives us insight into how the code changes over time and who is making what contributions, and gives us the ability to easily go back to earlier versions when fixing bugs.
They all type their code separately on their computers but there’s one big computer that they all connect to. When they finish their individual parts they put their code on the big computer and it checks to make sure it’ll work. When the big computer is done checking, it sends back the combined code to everyone. That way, everything gets updated together. If something won’t work the big computer will ask you to fix it before combining it together.
I like to think of a full program like an encyclopedia. They are filled with many different chapters and sections. Each section will be sent to specific division and each division may ask different people to put up an entry.
So imagine that I’m part of the marine biology department and assigned entries on octopus. I will write my entry and may have to reference other part of encyclopedia. For example I will talk about bones and may have to point you to look at calcium in the chemistry section.
I don’t necessarily know much about calcium but I know how to point you there because they’re part of the encyclopedia.
Software is similar in the way. When you click something, it will run a code written by others. As long as the code within the whole overall program, it will has access to it.
Latest Answers