Forgot your password?
typodupeerror
Programming Software

Learning and Maintaining a Large Inherited Codebase? 532

Posted by timothy
from the bequeathed-and-devised dept.
An anonymous reader writes "A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't. I spend a huge amount of time finding the right place to make a change, far more than I do changing anything. How would you learn such a big hunk of code? And how discouraged should I be that I can't seem to 'get' this code as well as the original developers?"
This discussion has been archived. No new comments can be posted.

Learning and Maintaining a Large Inherited Codebase?

Comments Filter:
  • Time (Score:5, Interesting)

    by wmbetts (1306001) on Friday February 12, 2010 @08:12PM (#31122206)
    If you don't have access to the original developers and they didn't document it you're going to just have to spend a lot of time reading the code. =\
    • by dintech (998802)

      You might want to come up with a few good reasons (other than just the ones you stated above) for doing a clean-room re-write of the damn thing. This might give you a chance to give the users something better than they already have or that interfaces better with other systems in your enterprise. It's a long shot but doing the requirements gathering and developing it yourself might be more fun than just learning it through reading. Good luck!

      • Re:Time (Score:5, Insightful)

        by Anonymous Coward on Friday February 12, 2010 @09:32PM (#31123122)

        Everyone, including me, always wants to go for the clean rewrite. But in my experience it almost never turns out for the best. There's a reason for all that messy code. Much of it was bug fixes that real-world users needed. Other complexities were needed in the first place to make the user experience simple (natural, giving it that "hey, it's just works like I expected" feeling).

        The reason you don't understand the code is that you weren't part of the original design discussions, in which weeks or months were spent learning, debating, arguing, etc., about many different design decisions at many different levels of abstraction. You don't know why the trade-offs were made. You just see the finished product.

        Rewriting the code won't give you insight into any of this. Learning the code the hard way, fixing bugs, rewriting *small* pieces and seeing what breaks the regression tests, etc. will eventually help you to understand it.

        There is no point in rewriting it before you fully understand it. Attempting that can kill a product. Conversely, by the time you fully understand it, there won't be any need to rewrite it, because you'll own the code.

        • Re: (Score:3, Insightful)

          by ztransform (929641)

          There is no point in rewriting it before you fully understand it.

          I fully support this statement.

          I recently worked with a guy new to contracting. He came onboard to a project that had a lot of problems. He argued for re-writing it thinking he could do it quickly and simply; I didn't dispute that the system could use significant changes, and I asked him to read through and understand the existing code.

          He never did.

          Consequently I suggested to senior managers that he should be let go. Reading other people's code, particularly undocumented code, is painful - even for ex

    • If both the original developers and the knowledge they had have been lost, then it is probably already too late to perform any major maintenance on this code base. The project has already entered its “servicing” stage.

      At that point, you basically have two possible approaches that actually work: you can restrict maintenance to small-scale changes, which may be sufficient if the goal is just to keep the project ticking over for a while, or you can accept The Big Rewrite (which isn’t so big i

  • by RCL (891376) <rcl DOT rs DOT vvg AT gmail DOT com> on Friday February 12, 2010 @08:13PM (#31122210) Homepage
    Try to single-step it in debugger from the beginning up to main loop.
    • Re: (Score:3, Insightful)

      by robot256 (1635039)
      I didn't get this one until I switched to my alter ego, the assembler programmer.
  • by iggymanz (596061) on Friday February 12, 2010 @08:14PM (#31122234)

    So you have been handed the steamin' pile o' code, it is great that you are very cautious and deliberate when modifying it. Make a set of regression tests, that is, make a set of test data and procedures and expected results to ensure original functionality that is still desirable is still working and no other errors introduced. It is hard, much more tedious than just creating new code with few constraints.

    • by kaiser423 (828989) on Friday February 12, 2010 @09:45PM (#31123232)
      Definitely what parent said. Also:

      I have inherited huge code bases. I actually kind of like it. Lots of people whom I thought were idiots, and cursed their code, I later found out that they were quite smart. Others, I found that they just thought about problems vastly different than I, and learning how they tackled problems gave me many more tools in my personal arsenal.

      That said, find a big wall or something. Use a debugger or code analysis tool to find the main execution paths (what calls what and when, etc). Diagram that up on the wall really large. Then use the tools to determine when and why certain auxiliary functions get called. Diagram that up, and you'll start getting a spider on your wall. Go from there using your new understanding to re-arrange the program flow not in terms that make sense to you, but rather seem to be how they are programmed (functional, objective, some pattern). Rinse and repeat until you know pretty much what the code is trying to accomplish in 90+% of the situations, and it's general plan for attack.

      With that diagram, dive in! There's tons of little details in every function that look useless but are usually bug fixes. Use a scalpel, not a hatchet.

      I was deployed remotely with no way for the main programmer to get at me. We had prepared 9 months to collect 4 minutes of data, and the test wouldn't wait for us. I found an odd bug hidden somewhere in ~22k lines of code. I did this over a weekend, and found about 4-5 nasty bugs that were combining to produce what I was seeing, and fixed them. I did this with zero input or help, over a weekend in code I had never seen spread around about 60 files. I spent the first half day just diving in and trying things, and nearly shot myself. That's when I went high-level and dug in from there.

      When that was done, I the took over code maintenance and updates on that project. The other guy had wrote it 100% himself, but because after that exercise I knew the code better him. Sometimes being new is good; you don't have all that cruft of implementations that didn't work, etc, but still linger in the original programmer's head.
  • Use Doxygen (Score:5, Insightful)

    by gbrandt (113294) on Friday February 12, 2010 @08:14PM (#31122238)

    Doxygen is your friend. run it over the source code and keep the HTML handy for searches and cross references.

    • Re: (Score:2, Informative)

      by eggy78 (1227698)
      I have found that equally useful to Doxygen's standard documentation are the caller/callee graphs (and the source browser as well!). These features are invaluable but they don't get used when you generate documentation with a more-or-less default config.
  • by $RANDOMLUSER (804576) on Friday February 12, 2010 @08:15PM (#31122256)
    If it's Perl or VB, you might want to consider self-immolation as a first step.
    • Simply running out of the room screaming "No!!!!!!" should suffice. There IS life after programming, believe it or not.

      • by martin-boundary (547041) on Friday February 12, 2010 @08:37PM (#31122538)
        No, he meant that as an actual offering to the Perl God, Quetzal$@[&shift]L. It's a bloodthirsty god, who never sends the Divine Debugger without at least two pints of the red stuff. I would have immolated a coworker, but the parent poster seems to have been alone in the room :-/
        • by chill (34294) on Friday February 12, 2010 @09:58PM (#31123338) Journal

          No, he meant that as an actual offering to the Perl God, Quetzal$@[&shift]L. It's a bloodthirsty god, who never sends the Divine Debugger without at least two pints of the red stuff. I would have immolated a coworker, but the parent poster seems to have been alone in the room :-/

          The fact the above comment is +5 Informative and not +5 Funny makes me very glad I stopped programming in Perl when I did.

    • I was on fire once you insensitive clod.

    • VB6's actually very easy to understand when you have the code...

      1. You can control-break at any point in program and be shown exactly the line you're executing and step through with F8 or resume at full speed with F5.
      2. You've got a rather nice project-wide search tool to find functions and subs that the old programmer wrote.
      3. You've got an immediate pane for simulating "What if X was set to..." situations.
      4. The previous programmer likely left behind date-stamps in the OS so if a user can tell you when th

    • Re: (Score:3, Informative)

      by BerntB (584621)

      Funny you should say that.,,

      I quite like this reference from the Perl world about understanding large systems: http://www.perlmonks.org/?node_id=788328 [perlmonks.org]

  • Not lots of code (Score:5, Insightful)

    by www.sorehands.com (142825) on Friday February 12, 2010 @08:16PM (#31122260) Homepage

    First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.

    To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such. Run some sort of profiler or flowchart type program on it to get a high level view of the code and how it fits together. If you can get the person(s) who worked on it before you to give you an idea of it fits together.

    • by Coryoth (254751) on Friday February 12, 2010 @08:49PM (#31122696) Homepage Journal

      First of all, 30-40,000 lines of code is not lots of code. Try, 250,000 of code.

      To start, use a good programming editor/environment (Xcode, Vslick, Visual Studio, etc.) that gives you the ability to easily go to definition or references to variables, functions, structs and such.

      30-40,000 lines can be lots of code, it really depends on how maintainably it is written. I've had to pick up codebases that were somewhat smaller but were still diabolical ... good programming environments don't buy you much when the code consists of functions that are many thousands of lines long making little or no use of typedefs or structs (arrays and lots of variables should be enough right?) and convenient variable names like 'e', 'ee', and 'eee'. Even small codebases can become practically incomprehensible if written with little thought given to long term maintenance.

      • by dgatwood (11270)

        Fair enough. On the other hand, badly written code is self-limiting in size. It almost never gets particularly large because if it is that hard to maintain, it will also be extremely hard to expand in any useful way. Usually by the time it gets past about 10-15,000 LOC, it has to be at least somewhat sensible.

        I tend to agree that 30,000 LOC is not at all large. My trivial little web photo gallery is 8k lines of code. At work, I maintain and periodically enhance a relatively small tool that's about 37k

      • Re: (Score:3, Funny)

        by snowgirl (978879)

        so like... perl?

        More percisely 30-40,000 lines of code is 29,999-39,999 times more lines than one needs to write shitty code...

    • Re: (Score:3, Insightful)

      by greg1104 (461138)

      Sure, if you only have a trivial 250K lines of code, I guess you can use crappy tools like Xcode and Visual Studio to maintain your project. The rest of us have to use grown-up tools that look like this:

      src$ find . -print | xargs wc | tail -n 1
      1950894 7085675 56777966

      There's only one way to learn your way around a new codebase, and the worst thing you can do is use a tool that aims to help with the job. Want to know how stuff flows through the program? Find where the program starts and draw the

  • by Anonymous Coward on Friday February 12, 2010 @08:16PM (#31122276)

    (And then shoot him.)

  • Not at all. (Score:5, Insightful)

    by hemorex (1013427) on Friday February 12, 2010 @08:17PM (#31122286)
    I find that if the other programmer wrote it in such a way where it's too complex for me to follow, I'm not the one who's a moron.
    • Re:Not at all. (Score:5, Insightful)

      by tsm_sf (545316) on Friday February 12, 2010 @08:43PM (#31122620) Journal

      Man, always when I run out of mod points.

      Nothing like being handed a steaming plate of spaghetti and hearing about how much of a "genius" its creator was.

      • Re:Not at all. (Score:4, Insightful)

        by CorporateSuit (1319461) on Friday February 12, 2010 @09:22PM (#31123028)
        Yes, but there's also when you hire the new guy, fresh from college, and he sits down at his work station. After a few days of getting absolutely no work done, he comes to you and tells you he wants to rewrite the core 50K lines of tested, trusted company code because he thinks it's not written "by the book". To which, the only sane reply is "You touch that code, and I will set you on fire."
      • Re: (Score:3, Insightful)

        by ajlisows (768780)

        Then again, the creator MAY have been a genius. Perhaps he was told "Put this enormous program together in one month or the company is screwed." In cases like that, poorly thought out algorithms, bloated classes, using variables with names like "x", "y", "z" with no comments, nothing really works except for the absolute bare minimum required and other coding no-nos probably do not seem that important. Given appropriate time and resources, perhaps he could have written the greatest code EVAR! Given a ver

    • To add to that:

      What language is it in? That could make a big difference in our answers. But in general, if it is very old code it should at least contain comments. If it was written in the last few years, the code should be in discrete sections that are organized in a logical manner. If not, then they were either seriously old-school programmers, or hacks.
  • Visualisation (Score:5, Informative)

    by gilleain (1310105) on Friday February 12, 2010 @08:17PM (#31122290)

    Anything ranging from just sketching out some informal package diagrams on some paper (I quite like using an A3 sketchpad) to something more like Code City [inf.usi.ch] which can work with code in smalltalk, java, and c++. There are UML diagram makers, of course, but automated diagrams like that probably need to be edited.

    In fact, it is not the finished diagram that helps so much as the drawing of it, which is why paper and pencil is so good. Or a vector graphics package.

  • The only way to learn the code is to work with it. Simply reading through it won't help, you have to go try to change things and see what works and what doesn't.

    The main thing that bothers me when working with other peoples code is the sheer number of variables they use. I tend not to declare a new variable unless it is absolutely necessary (and in object oriented programming variables other than pointers are almost never necessary). It seems like code written this way is easier to read and understand

    • Re: (Score:2, Interesting)

      by EvanED (569694)

      Am I off base here? What do you think about intermediate variables that are not strictly necessary?

      I can't say you're off base per se (I don't have nearly enough production dev experience to make statements like that, and even if I did, I couldn't speak for everyone), but my personal style is not quite the complete opposite of yours.

      I pretty heavily use intermediate variables. Why? A couple big reasons. One, if you give the temporary variables decent names, they serve as additional documentation. Two, if yo

      • by mosb1000 (710161)

        From a documentation standpoint, I have never found descriptive variable names to be good enough. The problem is that while the programmer may have a good idea what he means when we chooses a name, and indeed that name may make a lot of sense if you already have a good understanding of how the code works, someone new who is unfamiliar with the program will not understand it because they do not know how the code works. In the mean time, it's a lot of work to track back through intermediate variables (espec

    • Re:Use it (Score:4, Insightful)

      by phantomfive (622387) on Friday February 12, 2010 @09:45PM (#31123230) Journal

      What do you think about intermediate variables that are not strictly necessary?

      Use them if they make things clearer for someone reading the code, otherwise don't. For example, you can write:

      screen.displayName = user.firstName + user.lastName;

      or you can write

      String fullName = user.FirstName + user.lastName;
      screen.displayName = fullName;


      Thus making it more clear to someone reading that you are trying to use the full name. That is probably not the best example because anyone would probably understand that user.firstName + user.lastName is the full name, but I think you can see the main point, that sometimes it can be easier to read a few meaningfully named intermediate variables than a long equation. If it isn't easier to read, don't do it. But really when I read code, or even write it, I am willing to conform to either way of doing it if someone else feels strongly about it, because that is far less important than things like flexibility of major structures in the code.

    • Re:Use it (Score:5, Informative)

      by ciggieposeur (715798) on Friday February 12, 2010 @10:37PM (#31123616)

      What do you think about intermediate variables that are not strictly necessary?

      My general rules of thumb:

      1) I don't care how many variables are declared, so long as each makes sense on its own. Like another poster's example, 'fullName' is perfectly acceptable (especially for i18n/l10n aware code that may have different rules for generating a name).

      2) I ABSOLUTELY HATE clever arithmetic / pointer arithmetic / expressions all crunched into one line that can be split out. Example: in C-like languages that support pre- and post-increment, I expect the code to use only one or the other consistently, and never mix it with another expression. So this is fine:

      i++;
      j = i + 4; ...but this I can't stand:

      j = ++i + 4;

      #2 I picked up from a very experienced developer who pointed out that making the code harder to read is never worth it, the compiler produces the same code as the easy-to-read version. And that making code that looks 'too easy to be clever' is quite a bit harder than making code that looks 'too clever to always work'.

  • I wouldn't try too hard with a codebase as small as 30-40k lines, but for an actually large codebase, there are a bunch of different things that can help: - examine a class or function hierarchy and call graph. If you have tools to do so and the codebase is set up for it, go ahead. If not, set up the tools and codebase to be processed for this - you'll learn stuff about the code just by hooking these tools up. - pick medium-level routines in the code base that you are interested and run the applicaiton
  • by oldhack (1037484) on Friday February 12, 2010 @08:22PM (#31122354)

    I'll echo some earlier comments.

    Set up an execution environment with debugger, and run several typical scenarios and trace them with debugger. Get the feel of the big-picture execution scenarios/paths.

    It will take time for your brains to get comfortable with it, though. And the details, when you look into them, will throw odd stuff at you. But that's the nature of our work.

  • Tried and True (Score:3, Insightful)

    by cosm (1072588) <thecosm3NO@SPAMgmail.com> on Friday February 12, 2010 @08:22PM (#31122356)
    For culinary folks...
    The time and money you spend tracing and inserting noodles in the spaghetti will end up being larger than the time it takes to cook a new batch (no pun intended).

    For auto folks...
    The time and money you spend bondo-ing, welding, rewiring, duct-taping, and C'n'Cing parts for the car will end up being larger than the time it takes to design and build a new car. (Although restoring an old/vintage car for the sake of nostalgia is a much more pleasing experience than buying a new one).

    Gain an understanding of the purpose of each pivotal region. Know what your desired result should be, then begin the rewriting endeavor.
  • PL/SQL or cobol or whatever they throw at me I poke, prod, and play with it in a test environment. Someone up above mentioned pencil and paper to draw out how everything relates and that is a very good practice I've found to just get to know things. It's not instant but it helps more then you initially think. Also I use Open Office Draw to map out things as well. :P
  • 2000 lines can be enough to throw you off!

    I think it is just like learning anything. Keep at it.

    The most important thing is whether you have an efficient way to
    look at what effect any changes have that you may make. Any effort you put into
    that is probably not going to be wasted. (Might be unit tests? Sounds like they did not come with the code)

    Stephan

  • Seriously... if there is a lack of documentation, then you just have to start reading the source code, starting at main(). Then look at each object and read its constructors.

    And start documenting it. Add comments in the code, create inheritance diagrams and sequence diagrams.

    It will be tedious but you will come out of it a better programmer.

  • by Colin Smith (2679) on Friday February 12, 2010 @08:36PM (#31122520)

    And then you re-implement it in the latest language.

     

    • by mikelieman (35628)

      Good luck with that. There a business rules implemented by people who aren't there anymore for people who aren't there anymore. And it's all tied to whether $variable_1 is an "A" or "B" and $variable_2 being 999.

  • by syntap (242090) on Friday February 12, 2010 @08:37PM (#31122536)

    I have inherited projects and do my best to convince management that a pause is needed to document the code. Personally I try to flowchart the functionality and cover a couple of office walls with Visio printouts. Later on I can use such work to add detail and further documentation.

    I inherited some code where the developer used names of girlfriends in variable names, it was just dumb and completely unprofessional. I didn't worry so much about keeping track of those, I was more worried about a change in one spot having unintended (and perhaps unknown until too late) consequences. Rather than spend time fixing problems, I thought it best to do some up-front documenting to at least provide a path to successful maintenance.

    When I left the project, the manager had a binder of documentation and almost cried.

    • I inherited a Web site that was not only done in a goofy manner, nothing was documented at all. The customer didn't know who the host was, what the passwords were, and so on and so on. Nothing.

      My philosophy was that since the customer is footing the bill, nothing should be secret. I spent a bit of time hunting down host, account info, domain name info, contact info, etc, etc... writing it all down in an organized format, and gave it to the customer, rather proud of myself for being professional when the
    • Re: (Score:3, Funny)

      by greg1104 (461138)

      I inherited some code where the developer used names of girlfriends in variable names, it was just dumb and completely unprofessional.

      I once inherited a coding project where the naming conventions involved anti-depressant, anti-anxiety, and sleeping drugs. Let me tell you, that's a fun preview of how one's future working on the project might turn out.

  • by phantomfive (622387) on Friday February 12, 2010 @08:39PM (#31122558) Journal
    I had an English professor who always said, "Structure is the key to understanding." He was talking about literature, but I think the same is true for programs as well.

    Try to understand the structure of the program. What is the basic flow? It should have an initialization routine, a main loop, and a shutdown routine. Find out roughly where they are, then focus on the main loop. Usually there will be one piece of code that is central, and it will occasionally pass control into other large pieces of the program. Sometimes there will be more than one main loop, and control switches back and forth between the various main loops. If the program is event drive, this will make a difference in the structure.

    If you are just trying to make a small change, try to find the sequence of events that will lead up to where that change needs to be made. Follow the sequence of execution until you get to the line you need to change. If you are changing a single variable, sometimes it's helpful to do a search and find all the places that variable is used, to make sure your change won't have any side effects. This may seem time consuming, but it can save 10 times more in debugging.

    Learn to follow code execution with your eyes, without running a debugger. One thing that separates good coders from not so good coders is the ability to follow code that isn't being executed.
    • Re: (Score:3, Interesting)

      by Trepidity (597)

      Depending on the language and domain, one way to speed up learning the structure can be to see if you can match it to some set of programming idioms, and then read up on those idioms if it's not a style of programming you're familiar with. For example, if it's C++, can you figure out by looking at the code's layout whether it was written by someone big into C++ design patterns? If so, it might be easier to reverse-engineer what it's doing if you read a C++ design-patterns book, and then match large segments

  • There is a tool called grep which is very useful.

  • Done that.. (Score:3, Funny)

    by spasm (79260) on Friday February 12, 2010 @08:53PM (#31122746) Homepage

    As someone who recently passed off a pile of code of about that size in poorly written and poorly documented php to someone.. All I can say is I'm very very sorry, and I had *no idea* my personal side project would work better than the original commercial offering and be declared 'mission critical' three months before I left for greener pastures..

  • by codepunk (167897)

    I just took the easy way out and quit. I had inherited about 30K lines of php code
    that was written by my boss. Shortly after inheriting this spagetti mess I ran a grep
    across the source the word "function" did not occur a single time in the entire source
    tree. To top it all off I was not to rework any of it only maintain it as it was going
    away. I did end up installing it on about 5 new machines so going away anytime soon
    was not going to happen. On top of all that I would run into about 20 blocks of if
    statemen

  • Divide and Conquer (Score:4, Informative)

    by Whomp-Ass (135351) on Friday February 12, 2010 @08:57PM (#31122788)

    Identify each major portion of functionality. If you are working with a sales/billing system you would probably end up with : Orders, Invoices, Payments, Admin.

    Go through each of those portions and identify the major portions. Orders: Order headers, Order details, business logic, ui logic, reports, datalayer, etc. Repeat until reduced into easily consumable units.

    Pick and stick to an SDLC. Use whatever fits the situation and the resources. For a small project (under 100k lines of code) you should be good by yourself. Anything more and you'll have to involve at least 1 other person for testing. For medium (100k-500k lines) you'll need an additional dev...For large projects (500K-5M lines) you'll need a project manager, lead dev, 2 devs, 1 test, and a UAT team...For larger projects you'll have something unique and frightening to the specifics of the software project and corporation/agency making it...anyway, I digress...

    Go through each subdivision line-by-line and re-write it yourself (even if you aren't going to put your re-written version into production); the only way you're going to truly understand what is going on is if you do it yourself. Use whatever language you are most comfortable with or is most appropriate to the task (or languages), it does not need to be the same as the original.

    Verify that for a given input, your version produces an exact output.

    Take a deep breath. It's not a race. It's a one-to-one functional mapping of your software (your mindspace) and the original software (the other developer(s) mindspace(s)). The code probably will not be straight forward. It has also been battle-scarred and will be warty. Changes of initial requirements through time and feature enhancements (feature creep) will have taken it's toll on what may have originally been something simple or even elegant. It's something of a niche mindset and if it is not for you, there exist many other exciting things to be programming.

    Ultimately, if you do as outlined above, you'll solve many problems, be able to make whatever changes you like, and in so doing have a way to present your design as a replacement if you want...Or not, if you don't; for 30-40k lines parallel development makes sense, in a way, for one person.

  • That's small (Score:3, Interesting)

    by ameline (771895) <ian.ameline@gmailMOSCOW.com minus city> on Friday February 12, 2010 @09:02PM (#31122846) Homepage Journal

    Medium size is 250 to 750 thousand lines of code (one person can still understand how it all works). Big is 1 to 10 million lines of code. Really big is >10 million.

    I have worked on code bases of all of those sizes, and I like the medium size the best -- it's big enough to be interesting, and small enough that you can understand it all.

    One that I've worked on (over 25 million lines) is just too big for my tastes -- over 3 hours to do a clean recompile is excessive.

  • Don't be discouraged. It's not like English where everyone writes in a familiar way. Everyone writes code a little differently and it is hard to go through it. Even with good commenting it can be difficult. Just persist and hope that you can contact one of the original authors.
  • When I was programming we did every project in 5 lines of code, or less, period. Anything more than that was just fancy stuff!
    • by Surt (22457)

      Sure, but the medical policy must have been ridiculous to cover all the RSIs from the scrolling.

  • I have been given projects of this nature and the best approach is to document what is obvious and then use bug fixing as a way in to the code. While it won't give you a complete picture, it should help you understand what is immediately important, and serve as guide posts for knowing more in the future. Generally I try not to spend too much time trying to understand everything, since its a waste of time, unless that knowledge is guaranteed to serve you - sometimes the client just wants it be tweaked once i

  • "A couple of times in my career, I've inherited a fairly large (30-40 thousand lines) collection of code. The original authors knew it because they wrote it; I didn't, and I don't."

    A couple of times in your career? You must be lucky. Most jobs you can get coding will always involve taking over someone else's code.

    In my experience, design patterns are your best friend, bearing in mind that most of the code base will always remain a black box to you.

    For example, when I was doing some health insurance work,

  • by npsimons (32752) * on Friday February 12, 2010 @09:42PM (#31123202) Homepage Journal

    As someone who has done probably 90% of his work in maintenance programming, let me give you my tips:

    • Snapshot what you get - don't change it, don't even look at it. As soon as you get it, check it in, binaries and all, to a change tracking system (eg, CVS, SVN, etc).
    • Now that you know what they gave you, and you can get back to it at any time, your options are seemingly limitless, but for the quickest way to get up to speed, I would recommend writing unit tests for the software. This will be long and tedious, but by writing unit tests you will a) learn what to expect out of the software, b) be able to tell when you break something and c) truly learn the software.
    • Automate, automate, automate! It's a close call as to whether you should start right away on your first unit test, or get the build system automated, but let me just say that it will save you a ton of time to have a "one button push" way to build, run and test the software. From there, you should be having your machine build and run the unit tests automatically, preferably nightly, from a clean checkout of the repository, just in case you forget to run a test after you change something or you forget to check something in.
    • Run the software (including unit tests) through the gauntlet - valgrind's memcheck, electric fence, fuzz, bfbtester, rats, gcc's -fstack-protector-all flag, libc's MALLOC_CHECK_=3, gcc's _FORTIFY_SOURCE=2 define, gcc's -fmudflap flag, gcc's -Wall -Wextra and -pedantic flags; any way you can think to flush out bugs, do it, and start fixing them; you will learn much, not just about the code, but about the thought process of the original coder(s) this way. Change tools as appropriate for your programming language and environment (including compiler/interpreter, libs, OS, etc). As you can tell, I do a lot of C and C++ programming.

    BTW, the fact that you have a hard time understanding this code may be more a reflection on the original authors' coding skills than on your abilities; any idiot can write code that "just works"; it takes a lot of thought, time and effort to write code that is maintainable, and more often than not, the original coders were short on at least one of those (if not all three). Here's hoping you have the time to follow my above tips; they take a lot of time, but can be worth it if you really need to maintain the code. It's funny to note that apart from the first one, most of those tips apply equally well to developing software from scratch. If the code already has a change tracking system, unit tests, a build/run/test system, *and* automated testing, consider yourself lucky and just start picking apart the unit tests.

    • Re: (Score:3, Informative)

      by bill_mcgonigle (4333) *

      truly learn the software.

      And then if your unit tests work you'll know enough to comment the code correctly for the next time you or your successor comes back to it.

  • by BlueBoxSW.com (745855) on Friday February 12, 2010 @10:16PM (#31123466) Homepage

    Really. A guy asks a question for help and all of these people keep telling him 30-40,000 lines of code isn't much.

    That's a lot of code to get your arms around if you didn't write it. It's not the end of the world, but it is a sizeable task, and is the type of topic that few professional journals or books will ever be written about.

    Having been in similar situations, I my advice would be:

    1) Try to get an understanding of the history of the code. Who wrote it? Why? How many developers? How long has it been around? Do people love it or hate it? Is there a version control system in place you can use for information?

    2) Look at it from a technical viewpoint. Is is complete? Does it compile and run? How many languages are used? Are there interfaces with other systems you need to know about? What dependancies are there? How easy is it to setup a test server? What parts are well coded? What parts stink up the joint?

    3) Dig for functional documentation. What does it do? For whom does it do it? What business needs does it support? How mission critical is it?

    4) Meet with the business owners. Seriously. This helps you do two things: #1-- Define the real business need (which may be different than what was understood by the previous developers), and #2-- Set appropriate expectations about maintenance. You'll work hard to maintain and keep it working, but you are working from a disadvantaged position. It is important they know this and support you in your efforts, rather than complain loudly when something doesn't work.

    5) Plan to remove the dead weight. There's always a lot of dead weight in these near-abandonded projects. Get an idea how to simplify things and plan your work in phases.

    6) Setup real test and development servers. Yeah, you know that wasn't already done.

    7) Use version control. But you know this. It's 2010, and no developer worth his/her salt would code a paying project without version control. Right?

    8) All fixes will take much longer than if you wrote the code, so be careful with estimating time.

Don't steal; thou'lt never thus compete successfully in business. Cheat. -- Ambrose Bierce

Working...