From past experience, I'd recommend against it. Instead, I'd point you and your Java developers / programmers to Sun's Code Conventions for the Java Programming Language. This guideline has been vetted over many years and the entire JDK mostly follows it. As a result, most Java programmers are familiar with them, and Java code that follows these guidelines is generally readable by all Java programmers.
That being said, I'm going to ignore my own advice and begin writing a Java Coding Guideline for Xpediant. "Why?" you ask...
Well, I believe that Sun's guidelines are good, but incomplete. Remember, Sun's audience was much larger than Xpediant's audience, and therefore, had to be agreed to by a much more diverse group. Being smaller in size, we have the luxury of espousing and enforcing more specific coding practices - hopefully enhancing the quality, consistency, and effectiveness of our services.
So, where should I start? How does one go about crafting such a document?
Well, I believe the first thing that needs to be done is to create a vision - the same thing I would do for any new project.
Yikes.
Hm... Well, we are an integration and consulting company that works with and customizes software products that are Java-based, so it stands to reason that our Java code should be integratable with those products. And our projects generally deploy into enterprise-level production systems so the code should be high quality, production-ready. And since it's very likely we'll eventually turn over the code to the client to support, our code needs to be supportable and maintainable by other programmers.
So, the vision is:
To write a set of Java Coding Guidelines that:
- Enhances Xpediant's ability to write, test, deploy, maintain, and reuse its Java codebase.
- Consistently and seemlessly integrates with the Java codebase of the software products Xpediant's vendor partners create and sell.
- Consistently and seemlessly integrates with Xpediant's clients' existing and new Java codebase.
Posts
2 comments:
# Consistently and seemlessly integrates with the Java codebase of the software products Xpediant's vendor partners create and sell.
# Consistently and seemlessly integrates with Xpediant's clients' existing and new Java codebase.
To consistently and seamlessly integrate with the Vendor's software and the client's existing and new software - Isn't that a tall order Bill? Yes, we can ensure that the initial integration will be successful. But, both the product and the client's application are constantly evolving entities. How do we ensure that our code will work with new java codebase?
Ah...
It is a tall order, but not impossible.
To consistently integrate with the codebase of our partners, we need to establish and facilitate good/better communications with them - particularly their engineering/development & professional services staff. We need to jointly venture and partner with them. Once we do, we can establish a common set of coding practices and manage them going forward. Since we partner with multiple product vendors, we have to allow for vender-specific extensions to our coding guidelines depending upon which product we are working at any given moment.
As for consistently integrating with our clients' codebase, part of our delivery model needs to specifically address coding conduct at the project level. In that I mean, we need to come to the client with our coding guidelines in hand and work with the client to either mesh ours with their own coding guidelines or provide our guidelines as a basis for the project - for all involved. Then, we need to actively manage the coding practices on the project (and any future projects) going forward.
Really, the vision is the same for our partners or for our clients. We need to establish our own internal Java coding practices and then manage the cooperative coding practices as we engage. The easy part is discovering our initial Java coding guidelines. The hard part will be managing the practices situationally by project and delivering coding consistency each time.
Post a Comment