Good practices for handling project over to another developer [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 3 years ago.

Improve this question

What are some good procedures to follow when handing a project 开发者_StackOverflow社区to another developer, in cases of when the original developer will still be around for a couple of months to aid in the transition? Let's assume a medium-sized web application if a concrete example is necessary.

---

As a junior developer, I have gotten several projects assigned to me for maintainance that were written by others. I believe the easiest projects to continue are the ones where the code is clean and well documented (meaningful var names and formatting as well), the archetecture is relatively strightfoward, and the developer took some time to write some notes on the use of his components. In Java this would include class-level javadoc; in other languages it may include a header at the top of the source code.

Also, if the original developer is available and open to questions, it makes learning the archetecture much simpler - no puzzling out what he was thinking.

---

I've been on both ends. Taking over a code base and handing it off.

You should:

• Identify areas that aren't completely obvious. So, if you have a directory called "xml" but all your flash object get their data from "flash/swfs/xml" you should document that.
• Identify parts of the database which are no longer in use. If there are tables that simply have no use anymore.
• Identify areas of concern such as speed/performance of certain pages.
• If you have some really backwards logic on certain pages, explain why, if it's not been commented in the code directly.
• Any third party vendors should be identified along with their cost and use on the site. So if you're using a delivery network to stream your flash videos, definitely let that be known.
• If you have pages still in the project, but aren't being used anymore, identify them, or simply remove them.
• If you know for a fact that your database was poorly designed, contains no constraints or indexes and has no primary keys on many tables, mention it. It will let the new developer know they need to optimize the database.
• If you hardcoded e-mail addresses within the code and didn't put them in .config files, identify that as well.

I'm sure there are more but there are things I wish were brought to my attention on a project I had taken over at one point.

---

If you have written your code from the start so that it is sensibly architected and fairly simple to understand, and provided adequate documentation, transitional problems should be minimal.

But training is always nice.

---

For anything that requires a build environment (certain compiler, 3rd-party libraries, opensource libraries, paths, etc.,), have the original developer sit down with the new developer, at the new developer's workstation, and walk through the process of making a simple change, committing to the source control, building, smoke test, etc.. Lots of times projects that are out of the mainstream may have odd procedures for testing, or they may come from an unfamiliar repository branch, may need a specific compiler version, libraries, etc.. Bugs may be tracked differently, it may require specific logins or endpoints for testing, etc.. By walking the new dev through the process, on their workstation, you'll uncover all of those issues, saving the new dev lots of frustration.