Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I'm programming in Java, in a very OO style, by myself. Never had the chance to work with other programmers (I'm not a professional, at least yet).
Out of curiosity, I wanted to ask: How does working with a team on a project work, especially when working on an OO project?
How does splitting tasks work? How do you develop something that will succesfully work with something another programmer developed? How and when do programmers communicate?
Thanks
Hopefully I can help you a little, or at least point you in the right direction!
As a bit of a disclaimer though, it's a huge topic - and one that I really think takes "getting thrown in" to get a deep understanding of. That said, I'll give a quick run down of the two major issues:
Regarding OOP projects specifically - I honestly can't see too many issues specific to OOP that aren't present elsewhere.
In fact, I think OOP-style programming is incredibly suited to team development. One key ethos of OOP is that I shouldn't know all the details about every object I interact with: I just need to know what it can do, and how I can get it to do that.
The abstractions that OOP can provide are awesome in a team.
There needs to be a central place for the project to be stored, and one which allows multiple developers to access the codebase at any one time. This is where systems such as Git (or SVN) come in to play.
I can only speak specifically about Git, as I've never used SVN - however I gather they are similar but with different terminology.
Using Git I can create a repository with all the source code for a given project, and then allow my team to access to the repository. For every feature or bug fix that is then made, individual developers can create their own "branch" which means development can happen on parallel tracks.
Once a feature or fix is completed, it can then be "merged" back in to the main project's codebase. Any "conflicts" can then be detected by Git and resolved at the source level by the developer responsible.
I'm not sure if you'll have used Git before, but it can seem quite complex at first - but thanks to its recent popularity (in part to Github) there is a whole wealth of tutorials and resources out there.
If you haven't used it before, then I recommend signing up to GitHub and getting a feel for it that way! (Alternatively, Bitbucket is a similar alternative, but it allows you to have private repositories for free.)
Git Flow is an excellent Git based work flow that is incredibly useful for teams. Like Git in general, once you work with it for a while it gets difficult to imagine working in a team without it!
Once you get past all the technical barriers, you really come down to the fundamental issue that plagues most projects (technical or not) - and that's communication.
The whole team needs to be aware of who is doing what, when they're doing it and what it affects.
This is obvious, but most projects will use some form of ticketing system - where any feature requests or bugs are logged, and then subsequently assigned to a specific member of staff. (JIRA, Unfuddle etc.) Often these are built in to the source control system which makes life a little simpler. (BitBucket and GitHub both provide issue tracking for Git repositories hosted with them.)
This stops, or helps prevent at least, developers accidentally working on the same issues.
This isn't a complete fix though; you still need to ensure developers are aware about other developers responsibilities. I know in the past that I've fixed other issues that I've stumbled across in the course of fixing a specific bug, purely because it makes sense. ("Well, I'm already here. This could do with a refactor and perhaps I can check for any other issues.") Then I've had to apologise to other developers as they were working on those other issues that I've fixed - wasting both of our time.
In general those, these issues can be fixed by...
Some project management/development methodologies dictate specific communication methods or meeting intervals. In general, the most productive systems I have seen have been morning stand-up meetings where everyone in a team will give a quick run down of what they're doing - if you limit this to development team members only and have clear guidelines about what to communicate then these can be incredibly effective. I've always tried to stick to:
I am working on X,
To achieve/fix Y,
Which involves modifying/amending Z.
Other team members can immediately take in that "Fergus is working on fixing that bug which was logged the other day, however that means he's working on some code that I need to look at - I'll check with him before I make any changes.".
I recently worked with a great team that had a fortnightly "tech chat", where bigger/architectural issues would be discussed. Every member of the team had time to understand the bigger issues facing the project and could discuss potential fixes.
I personally loved this, I didn't contribute much as I was quite new to the project - but being able to listen to the discussions gave me a lot of insight; pretty soon I could understand the project as well as individual thinking styles.
Communication is the one issue that can bring any team down. Technical or not, if people aren't aware of the bigger picture then there is a greater chance that they will fail.
It's good to ensure everyone has the same configuration or style when working in a team. What do I mean?
If you're working on a Java project - then perhaps ensuring (for development environments at least, certainly not for testing.) JVM versions are common amongst the team may be a good idea? Then IDEs. It helps majorly if the whole team is using Eclipse or NetBeans or your IDE of choice.
On a web project it might be that all the developers need a specific stack; with specific Apache or PHP versions.
Thinking of factors like this just allow the team to "gel" a bit quicker in my mind.
Tabs vs spaces? CamelCase or spacing_with_underscores? As small as these questions may be when you're working alone, when you're working with a bigger team you really want to strive towards a common style.
In fact, you shouldn't really be able to tell who wrote a specific section of code - you should just know that it belongs.
This is why many open source projects openly publish source code format guidelines/styleguides - for an idea of what these contain, take a look at the Google StyleGuides for their own open source projects.
This isn't limited to teams, but I'm going to quickly touch upon this for one reason in particular: it makes team life a lot easier.
If you have a complex workflow with lots of dependencies, or a long build process - then often it's useful to automate this using a task runner. For web projects GruntJS is awesome, although coming from Java I guess Apache Ant may be quite similar.
As an individual I use GruntJS to build my site before I deploy it to my FTP server - one Grunt command is all I need for my CSS/Sass to be compiled and minified, my assets to be compressed and then my files to be uploaded.
As a team member though, I can use GruntJS to check that I haven't broken any tests - and that I haven't introduced any bugs by not being fully aware about other parts of the project. This is of course, additional to the benefits that it affords me as an individual developer.
I can also use it so that I can clone a project using my fancy source control package (Git) - and run one command to install all my dependencies. This is a big plus, as the time spent getting a new developer in to the position where they can actually begin developing can be quite large - without even considering the time it takes to get used to an unfamiliar codebase.
The best projects I have seen have had documentation (and often quite excessive.) aimed at developers. These kind of documents may explain things like:
1. The development environment:
"We're currently deploying to a server running a LAMP stack, as such developers should be targeting the versions outlined in.."
2. Work flow
"All features are to be developed on a 'feature/*' branch and merged in to the 'testing' branch prior to being considered as release ready."
3. Responsibilities in the team:
"For database issues, talk to Steve. For platform issues, talk to David."
4. A "pipeline" for the future
"When developing new code remember that as of June 2014 we wish to implement x - legacy code may need to be reviewed before this occurs."
It may be worth looking at the work flow of an open source project to get a feel for how it works - whether that be an established one with their own workflow (often heavily documented), or one of the many examples on GitHub.
If you find yourself working in a team that manages to do all of this right.. you'll hate being anywhere else..! Take it from me, once you've experience a good team then suddenly issues elsewhere can really drag you down. (That's a story for another post however!)
