Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re: code-sharing at work.

by dragonchild (Archbishop)
on Mar 23, 2005 at 20:56 UTC ( #441883=note: print w/ replies, xml ) Need Help??


in reply to code-sharing at work.

In no particular order and with no particular emphasis:

  • Don't "share" code - reuse code. Create a set of infrastructure modules that everyone reuses.
  • Document APIs - you can't reuse what you don't understand how to use
  • Tests - most people rewrite the wheel because they don't trust the other code. Seeing 1000 tests pass goes a long way to giving someone confidence.
  • Source Control - everyone checks their stuff in and can see the latest versions.
  • Managerial dictates - sometimes you need a whip to get out of your rut.

Ultimately, you need to soft-sell them on the benefits. If you and a coworker started to reuse each other's code, you can demonstrate how you found a bug in his code that he'd been trying to fix for months (and vice versa). Two heads working together are better than three heads apart, and all that jazz.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.


Comment on Re: code-sharing at work.
Re^2: code-sharing at work.
by Joost (Canon) on Mar 23, 2005 at 21:21 UTC
    I agree, especially concerning tests and documentation.

    Documentation is good. Tests are good. If they are done right, it's even better. But hardly anyone wants to spend a lot of time writing tests or documentation, so even just some people documenting and testing bits of the same code will make it better than having everyone go out and re-invent the wheel.

    Make sure you make it easy to adapt, test and document the code. That's where revision-control comes into play. I'm using CVS at the moment for most of my projects, but subversion is looking to be the best thing since CVS. I've only used it on 2 projects, yet, but as soon as I've got the time, I'm planning on switching my CVS repository to subversion.

    I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project) - just because it's easy to change will mean that people will actually update the docs. Remember, programmers should be lazy :-) If it's easier to write a new plain text-file in some obscure subdirectory than to update a word-document in the project-document system, guess what they'll do. Avoid wordprocessors for documentation as much as you can. Programmers hate them: they're big, slow and you can't write code in them. A good Wiki is much easier.

    updated: spelling.

      I would also recommend using some sort of Wiki for "general" documentation (introduction to a module, giving an overview of the whole code library/project)
      Where I work they have recently installed Trac, which is, to quote from the home page, "an enhanced wiki and issue tracking system for software development projects". Personally I find it quite handy, effective and useful both as a web-based interface to svn and as a wiki and I particularly appreciate its terse and clear, minimalistic, look & feel.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://441883]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (7)
As of 2014-09-30 22:12 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (385 votes), past polls