1

We are building a Game Client and Server, our system is broken into four major projects: (Client and Server, Shared Interfaces, Source Art). In addition, both client and server have a set of libraries where we put shared code for client and server respectively. As you can imagine this leads to a lot of projects, I count 12 projects in the entire source.

My questions are; What are the good rules of thumb regarding when to keep code in one project versus breaking it into sub projects. No one likes a large monolithic project but lots of small projects also add a lot of overhead.

Should all projects be branched and released in lock-step to keep things simple (one current version number for all) or should library projects be branched and released separately only when they change. This will lead to complex map of compatible versions.

I know there is no absolute answer for these questions but what are the known best practices when deciding and/or good reference material to read up on this subject?

| improve this question | | | | |
1

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

This lists the SOLID principals as well as principals for what goes in a package and how packages reference each other.

| improve this answer | | | | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.