What are the qualities you want in a design architecture such that it is easy to implement by a team of coders?

I was currently given a couple of documents (class diagram, some collaboration diagrams and sequence diagrams) of a small game, being the task at hand rate how easy would it be to give this coding job not to one programmer, but to a team of them.

What are the fundamental points that I should look at? Here is what I've thought of:

• Looking just at the class diagr开发者_JAVA技巧am, I can see a big problem in it. 95% of the classes are dependent on concrete classes, so you have to basically first create stub classes for the whole system even before puting any logic in it.

• There isn't any kind of package diagram in it, so it might not be that obvious to see how to decompose this system in different teams. Had I a way to see the way the different modules are packaged in a package/namespace system, I could more easily see what are the dependencies at a higher level and more easily divide my team members on different tasks.

I have zero experience in working in teams, so I'm just basically blind guessing. What other factors should I look for?

Thanks

In order to divvy up work you have to be able to slice up the codebase in some way. Depending on the team, some might be comfortable working in horizontal slices (DB dev, server dev, UI dev) while other teams are more comfortable with vertical slices (feature 1, feature 2).

If you're rating a code base, you'll be looking for modularity, cohesiveness and separation of concerns. So for a game, is there a physics module? Does it have a well-defined interface? Is it well encapsulated? Can it be used for multiple types of things (characters, boxes, balls, bombs, etc)?

Make a requirements/feature list. Could feature 1 and feature 2 be worked on concurrently by different devs/pairs given the architecture at hand?

If you have never worked in a team, I suggest you to read Scrum and XP from Trenches. Its a very easy read and make a lot of sense. Its good to know what problems would be there before hand. That is the reason I am recommending this.

Further, there are many other concerns,

• Knowledge and experience of your team
• Task break down in a manner that all can work in the same time
• Continuous integration
• Communication; communicate early and frequently to avoid any miscommunication/assumptions
• Its not that important to come out with the complete UML diagrams upfront. It should be lean and agile

These are few things I can suggest from the top of my head.