If the driving force behind this question is too much traffic, have you looked into caching frequently used objects? For example: AFter you get the Employee and Department and Supervisor objects, maybe it would a good idea to add them a cache so that if they are requested again in the near future, they are already in cache and don't need to be retrieved again. Of course, the cache will need to let rarely used objects expire out, and also needs to be able to remove objects that have been modified by the application and saved back to the database.
Depending on what language and frameworks you're using, there might already be a caching framework that can do some (or most) of what you need. If you use Java, you could look into the Apache Commons-Cache (I haven't used it for a while, and while it looks dormant, it is still available to use and it was pretty decent the last time I used it).
I work with a team that grew from 2 developers to 10 in less than a year. I was number 3, and the first to raise a coding standards issue. The two original developers had been working side by side for a few years and they'd adopted a common standard that seemed alien to me. We had exactly the same problems you are describing.
What we did was:
Research coding standards
We spent a few days checking out established open source projects. We knew the team would expand rapidly and we were looking for real solutions based on real projects not some generic guidelines. Also we didn't care for the optimal coding standards, but for a set of rules and guidelines that would make sense and not call for the refactoring of all of our codebase. We were looking for a coding standards hack if you will.
The three of us decided that the best coding standards out there for an established PHP project were those followed by Zend Framework. Fortunately the Zend Framework people provide a very comprehensive coding standards document.
Creating our own coding standards
Of course applying another project's coding standards on our project as is didn't make sense. We use the Zend Framework document as a template:
- First we removed everything that didn't apply to our project
- Then we changed everything that we perceived as a matter of style to our style
- And finally we wrote everything down
So we had a fairly large document at our hands, stored in our fancy wiki, it was a nice read, agreed upon by all of us. And completely useless on its own.
Staying true to our promise
Our codebase at the time was about 1*10^6 sloc. We knew that since we adopted formal coding standards we had to start refactoring our code, but at the time we were pressed with other issues. So we decided to just refactor our very core libraries, a mere 5*10^3 sloc.
We assigned one of us to be the coding standards master (we used local profanity in place of master) with the responsibility of checking and enforcing the standards. We recycle the role every few sprints. I was the first, and it was a lot of work, as I had to monitor almost every commit.
We had several new discussions and small addendums to the original document during my tenure, and finally we had a somewhat stable document. We change it every now and then but most of these changes are on new features of the language, as PHP 5.3 was a major release in all but name.
Dealing with the new guy
When the next new guy arrived, it was time to put our coding standards to the test. After a small introduction to our codebase, we asked him to evaluate our coding standards document. He almost cried. It appeared that he did everything differently.
As I was the coding standards master at the time, it was up to me to evaluate his input and revise the document accordingly. His proposals were:
- Matters of personal style (summarily dismissed)
- Standards that made sense to his Java background but no so much with PHP (dismissed)
- Conventions that he carried from his brief exposure with PHP (some were dismissed, but a lot proved to be popular conventions that we never thought of or found out in our initial research)
For the next couple of weeks he was assigned a simple task: Bring several parts of our codebase up to date with the standards. I had to carefully choose those parts based on a few rules:
- Code should be relatively easy for someone unfamiliar with our codebase (and PHP in general)
- Code should be on what he was hired to do
I monitored his process and he did a fine job. We identified several parts of code that was impossible to fit our document and revised accordingly (code and / or standards, whichever made more sense)
And then another new guy arrived. We repeated the process (different master this time), and it worked again. And again.
In conclusion
- Create a coding standards document, but make sure that your standards are not exclusively your own but do reflect common standards in the wider community of your platform.
- Assign a similar role to our coding standards master. Someone to monitor at least new code, and especially new code from new members. Recycle the role, as it's extremely boring.
- Always evaluate input from a new member. Always revise your standards if it makes sense. Your coding standards document should be evolving, but slowly. You don't want to re-refactor your codebase at each iteration.
- Allow for some time for each new member to learn and adapt to your standards and conventions. Learn by doing works best in these situations.
- Wiki works wonders for such documents.
- Code reviews work wonders for any situation!
At some point in the process it was suggested that we use a pre-commit hook to automate checking of the standards. We decided against it for a variety of reasons, there are some interesting discussions on StackOverflow on the issue:
Some are PHP specific, but the answers apply to all platforms.
Best Answer
No, you will need to make a standard. If you have team member B change (either with an automated IDE tool, or manually) a whole heap of code team member A wrote, that will be committed and show as a change.
This is something almost every team faces and standards are "forced" for this very reason. I would suggest you follow the language authorities standards as a baseline and adopt them to suit your team.
Having a consistent coding style will also help in the maintainability of the project and reduce the barrier to entry for new people working on the code.