I've found in the past that the ability to be able to reuse code depends on
a number of organizational factors:
- do you disseminate information about the shared code through:
- design reviews
- code reviews
- peer programming
- do you perform automated builds so that:
- failing tests in shared code gets identified quickly and dealt with.
- documentation gets automatically generated and published on a web
server
- code and documentation are indexed (through tools like Lucene, or
other search engines).
- do you treat shared code like it was its own open source project? --
complete with project plans, bug reports, deadlines, branches for different
dependent releases, etc
- do you document your code? People often document the classes and
interfaces, but forget to document the packages. You can use package
documentation to help explain the design and usage of a framework.
- do you share people between groups so that knowledge spreads
organically through the organization?
These are all ideas that make the process of sharing code easier, but
ultimately it's up to the development organization (both management &
developers) to determine the priority for sharing code.
Mark
On Mon, Oct 13, 2008 at 3:40 PM, Alexey Zinger <[EMAIL PROTECTED]>wrote:
>
> I am currently contracting for a major US corporation. This is my first
> gig working in a development environment of this scale and their answer is
> basically to have each team responsible for their own code base, but most
> teams' code is visible to most other teams. Due to huge variations in
> underlying technologies, developer skills and experience, and other factors,
> it's not uncommon for a team to treat another team's code as though it's a
> rabid dog. That said, the company employs a number of tactics to improve
> developer productivity through certain tools that allow easy customization
> and creation of very high level apps. I do wish we had a better maintained
> library index (library library?). Part of the problem with most people's
> dislike for adoption of other people's code is lack of documentation, not to
> mention lack of abstraction. I try to do my part to rectify those in my own
> code, but it's hard to do since there's no immediate incentive for any
> team to make their output attractive to another team.
>
> Alexey
> 2001 Honda CBR600F4i (CCS)
> 1992 Kawasaki EX500
> http://azinger.blogspot.com
> http://bsheet.sourceforge.net
> http://wcollage.sourceforge.net
>
>
>
> --- On Mon, 10/13/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > Subject: [The Java Posse] Have we given up on the idea of code reuse?
> > To: "The Java Posse" <javaposse@googlegroups.com>
> > Date: Monday, October 13, 2008, 3:45 PM
> > A couple of years ago the media was rife with all sorts of
> > articles on
> > how the idea of code reuse was simple way to improve
> > productivity and
> > code quality.
> >
> > From the blogs and sites I check on a regular basis it
> > seems as though
> > the idea of "code reuse" has gone out of fashion.
> > Perhaps the code
> > reuse advocates have all joined the SOA crowed?
> >
> > Interestingly enough when you search for code reuse in
> > Google the
> > second result title is:
> >
> > "Internal Code Reuse Considered Dangerous!!
> >
> > To me the idea of code reuse is just common sense, after
> > all look at
> > the success of the apache commons project!
> >
> > What I want to know is?
> >
> >
> >
> >
> >
>
>
>
> >
>
--
Mark Fortner
blog: http://feeds.feedburner.com/jroller/ideafactory
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
