Project Transfer

Question

I would like to know your experience when you need to take on someone else's software project - especially when the original software developer has already resigned.

Answer 1

The cases when the original developers came out before the transfer of the project are always the most interesting: you are stuck with the code base in an unknown state. What I always find intriguing is how the new developers do their best to comment on how poorly designed the code is: they forget about the limitations that the old developers might have, shortcuts that they could make them do. The saying has always been the old dev == bad dev. What do you think: I would even call it official bad practice: the bad words of those who were before us.

I try to use the most pragmatic approach possible: study the code base, wander a little. Try to understand the relationship between requirements and code; there is not even a clear source relationship at all. There will always be a “moment of aha" when you understand why they did something anyway. If you are still sure that something is not implemented correctly, do your refactoring, if possible. And highlight the code snippets that you cannot change: unit test them using a mocking structure.

Welcome to the service developer.

Answer 2

The biggest success we have had with this is the wiki. During the notification period, ask the outgoing developer to help you document everything on the wiki team / company and see if you can use it with a code review and add comments to the code when performing reviews explaining the sections. It is best for the developer to "take over" write comments in the code under the supervision of a leader.

Answer 3

Once I joined a team that was handed over by a bunch of paired crap from outsourcing. Initial project - Java-based multimedia content manager, Struts, Hibernate | Oracle - was well structured (it seems that this is the work of several people, programming for a couple, the reasonable use of design patterns, some unit tests). Then someone else inherited the project and endlessly copied the nested functions, loosened the business rules, fixed it, forked it until it became a huge spaghetti monster with a thin processed part of such codes as:

List<Stuff> stuff = null; if (LOG.isDebugEnabled()) { stuff = findStuff(); LOG.debug("Yeah, I'm a smart guy!"); for (Stuff stu : stuff) { LOG.debug("I've got this stuff: " + stu); } } methodThatUsesStuff(stuff); 

hidden among other brilliant ingenuity.

I tamed the beast through patient refactoring (extraction methods and classes more time), commenting on the code from time to time, reorganizing everything until the code base decreases by 30%, over time it becomes more and more manageable.

Answer 4

I had to intercept some kind of elses code of varying degrees of quality several times. Therefore, tips:

• Try to collect structured notes of any important information from the first minute: names of stakeholders, business rules, codes and locations of documents, etc. It’s best to dedicate a new spiral notebook so you can tear pages if you need to.

• Use one of the best free desktop indexing and search tools available on the market (Google Desktop Search, MS Windows Search). Add to it all documents, email addresses, codes.

• Before you develop a document analysis: find everything that you can get electronically on the network and print documents, make an effort by simply reading it. Surprisingly a lot of useful information, even in incomplete drafts.

• What is the map, architecture, etc. when you go.

• When using less documented and supported systems, you will inevitably have moments of despair that can lead you into a delayed mode. Especially in the early days or the week when the amount of new information that your mind needs to digest is staggering. At these times, it's nice to have someone to remind you (or just do it yourself), to calm down, first focus on important things and return to taking small steps, trying to gain understanding, rather than trying to leap forward.

• Continue taking notes, creating charts, drawing rich pictures, and displaying data. It really helps to digest a copious amount of new information, mostly disorganized.

Hi, good luck!

Answer 5

In fact, we have a specific set of “Outcomes” that must be present for us to take on the project.

If we have a chance, we will try to involve one of our people in the group developing the project at the beginning. Thus, we receive first-hand information before our group takes over the code. (in the line of what @Guy wrote)

Saying the most important part for me:

• Some kind of high-level (drawing?) Of what the code does.
• Easy access to ask questions to people who have actually written the code.

For me it's alpha omega when you accept code and projects