Slashdot Mirror

← Back to Stories (view on slashdot.org)

Technologies To Improve Group-Written Code?

Posted by ryuzaki0 on from the team-building-and-improvement dept.

iamdjsamba asks: "I've been working at my company as a programmer for about 4 months now, and it's apparent that the working methods could do with a refresh. Practices that we need to start changing are things like: non source-controlled changes that get uploaded to our website when they aren't ready; poor code commenting; and very little in the way of code reuse (if I write a class that could be useful to others, I have no easy way of telling everyone about it). I'm currently looking into ways to change this, and was wondering if anyone on Slashdot had experience of what's good and what's not?"

3 of 74 comments (clear)

  1. Wow. Quit now by BadAnalogyGuy · · Score: 5, Insightful

    You clearly don't have any managers or developers with any experience because the first thing that a bright manager or an experienced developer would do is install a source control system so that you don't end up in the kind of development shithole you've found yourself in.

    I'd recommend leaving for a company that's going to be around for more than a year.

  2. Create simple rules by Bragi+Ragnarson · · Score: 5, Insightful

    Create and enforce simple rules:

    1. Limit access to deployment server - only one or two person can access the server. Even better - create automatic deployment scripts that can be run on the server by those persons.
    2. Create staging server - where you deploy the code from repository. Do not deploy to production until you get a "go" from the client on staged version.
    3. Use Trac - it is a great piece of software that allows sharing information between developers. It provides wiki, ticket handling and repository viewer. And you can subscribe to wiki changes RSS so you can easily publish documentation about your classes.
    4. Use framework - frameworks usually come with a set of coding concepts that ease code reuse.
    5. Communicate findings about bad practices - just talk with your colleagues and tell them how can they write better code, with examples
    6. Introduce unit testing - person that writes unit tests gets a chance to look at own code the second time, which usually means improvements and cleanups.

    And you can always switch to Ruby on Rails. It is a good example of framework that helps doing things the right way and gets in the way when you want to do something wrong.

    --
    Bragi Ragnarson Lawful Good (I change the law when it's not good)
    1. Re:Create simple rules by Anonymous Coward · · Score: 5, Interesting

      7. Code reviews -- I can't tell you how many times I've caught typos or other problems in my own code as I've been explaining it to my code reviewer. I've also caught other coder's typos/problems when I've been a code reviewer. It also makes it less likely for one programmer to make a change in a dark corner somewhere and put it out there for the world to see without at least someone else's eyes having seen it first.

      8. Design reviews -- if you're going to make a major change, after you've done some planning for the change but before you implement it, get other interested parties involved in reviewing your design. They may have other ideas for how to implement the change that may be better/simpler/less expensive/etc. than what you have planned, or they may have questions that will get you thinking about your own design in a new way. The design review process can be formal, in a meeting scheduled for the purpose of reviewing the design, or it can be informal, just you emailing the design to a few people and asking them what they think.