This is a pretty generic question but one I've been wondering about for a while: is there a standardized, generally accepted, or even just systematic way that people write code as a group?
For example, in a project written in C++, does one developer write one class, which he passes off to the next developer with a quick explanation of what each method does?
I've never seen a formalised, standardised way to do this - but I've seen two common patterns.
Feature Ownership - each developer takes exclusive responsibility for a particular feature of the system, and implements this through all appropriate layers.
Key Advantage: one developer, with a full understanding of the entire feature, can work through all layers in a consistent fashion.
Key disadvantage: Because many different developers end up working on the each component, you can end up with a distinct lack of consistency unless you have good conventions in place.
Component Ownership - each developer takes exclusive responsibility for a specific component/layer (UI, services, data access, data schema etc). Features are implemented by collaboration between devs.
Key Advantage: each component is written by a single developer, ensuring it has a consistent style and "unity of vision".
Key disadvantage: There are always some components requiring more development than others - resulting in an unbalanced load on certain developers.
Though, these are exclusive - even if a particular team subscribes primarily to one, some things tend to be done the other way.
In my experience, feature ownership has been more successful in the long term than component ownership, primarily because system knowledge is more spread out, helping to address key person risk. But, that's just my experience.
in Agile, the answer is however the team wants it to work
could be features, could be stories, could be tests, could be tasks, could be paired, could be...whatever.
some dev shops transfer code ownership at shift change and use three shifts in time zones 8 hours apart for continuous development
some dev shops assign entire subsystems to one person
there are many ways...
I'm making this a separate answer because while it has some of Bevan's answer at its core, I'm expanding on it a bit. I, too, have never seen a formalized way of doing this.
Mine is an Agile shop building a SaaS app, with a team of 4 developers and a tester, working on 2-weeks sprints. When the team decomposes stories, we create a parent ticket and children tickets that roughly work out to be model changes, view changes, and controller changes (broadly speaking) to achieve the goals of that story.
When it comes time to work, one developer grabs the parent ticket, and for the life of that work within the sprint, they become the "owner" of the code that goes into realizing that story. However, it is quite common that other people on the team work on the child stories depending on personal strengths (e.g. UI, database, an extra dose of business logic knowledge). The "owner" of the parent ticket is the go-to for questions about that feature or component (whatever the case may be) until all the children are completed and the owner works through the whole item at the parent level and is ready to send it as a bundle to the code review status.
When items go through code review, they do so at the individual child level as well, and the only rule is that no one reviews their own code (obviously). So, while Developer A might be the owner of the parent ticket, he could have worked on Piece 1, 2, 3 while Developer B worked on Piece 4, 5, and Developer C on piece 6, 7. Developer A would be able to code review 4, 5, 6, 7, Developer B could code review 1, 2, 3, 6, 7, Developer C could code review 1, 2, 3, 4, 5. When the code makes it through Code Review, it goes to test.
The tester tests each child independently if it has its own acceptance criteria, and the parent as a whole (which definitely has its own acceptance criteria). Here's where "ownership" comes into play again -- the owner of the parent is responsible for any fixes in the parent or its children. "Responsible" in this case may mean "having a conversation with whomever worked on a problematic child" but it is the parent owner's to get right.
The thought with all of this, and it's worked ridiculously and shockingly well with my team, is that everyone is always both an owner and a helper, everyone practices collaboration and communication constantly, and everyone is then familiar enough with every piece of the system that after the release anyone can be an owner of anything for the short period of time that owners have a role (e.g. within a sprint).
The short answer - No, there are no standard ways of doing anything, but one thing which nearly all projects start out with in common is that almost everything will be 'unknown' near the beginning.
With reference specifically to your question about delegating responsibility for individual classes (or any other implementation details for that matter) - those kinds of decisions can't always be made up-front because developers often don't have enough information at the time the work is divided. It's fairly common to have no idea what classes are going to be created until development has begun and there exists some kind of working baseline/prototype.
More typically, developers might just agree upon periphery details for whichever part of the system they are responsible for, so that other developers have an idea of how the bits will integrate together, without worrying about how it's actually going to work.
In practice, it usually means defining communication boundaries (internal or external) which will be used to connect the features/components/modules - e.g. interface types, message structures, data formats, input/output streams, shared data types etc. The final split of responsibility may or may not mean that multiple developers work on the same classes/functions; it may also mean that classes which featured in the original design are scrapped and overall architecture is later changed (but hopefully the basic interfaces and communication mechanisms will still be largely usable)
