This question should be more how do you prepare for passing off a project in the middle of it.
Firstly, you want to have all of your business logic designed and concrete(At least for this iteration). This is honestly the hardest part, typically this is due to how suits navigate devs and the only solution is have a strong willed project manage with nothing to lose, like all of those hard boiled cops you hear about in buddy cop drama movies.
Once you have all your business logic you want to make sure you have tags in your issue queue that are related to each piece of business logic. Who knew metadata was so useful. This applies to all designs, front end pieces, and back end. If you have failed/had a difficult team hand off before, think about these previous two things and ask if it would have been MUCH simpler.
Now that the logic and tickets have been documented and explained (Only had 15 meetings instead of 40!) we move onto the hard part, passing the actual code.
Sometimes things are messy with where code actually lives and what the practice is to get there. Normally there isn't a team hand off in projects so we rarely prepare for this, but you know what you should always prepare for? On-boarding new developers. Essentially a team hand-off. Well, it's just a large on-boarding of developers while kicking out the seasoned ones (Now team hand-offs sound like a bad idea, but that's a different conversation, we can't go back now).
In on-boarding a new developer (Or handing off to a team) you want to show how code is managed, how it is pushed, and of course the actual stack behind it. This can all be done with wikis and git, and if you're using GitHub you get both! It's really simple for each component explain what it does, why it does it, how it does it, and what software/stack it uses to do what it does.
The way you write the wiki is simple, give a list of repos pushed to(In a different wiki talk about how your company maintains branches/versions), then record the steps you take from making a code change to getting it on production (minus the git commit -am "removing extra quote that 500s" part).
This is just a long winded way of saying document, write tests, and if you were hit by a bus tomorrow would your component be rewritten or would someone through your documentation be able to keep on using it and developing it?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
This question should be more how do you prepare for passing off a project in the middle of it.
Firstly, you want to have all of your business logic designed and concrete(At least for this iteration). This is honestly the hardest part, typically this is due to how suits navigate devs and the only solution is have a strong willed project manage with nothing to lose, like all of those hard boiled cops you hear about in buddy cop drama movies.
Once you have all your business logic you want to make sure you have tags in your issue queue that are related to each piece of business logic. Who knew metadata was so useful. This applies to all designs, front end pieces, and back end. If you have failed/had a difficult team hand off before, think about these previous two things and ask if it would have been MUCH simpler.
Now that the logic and tickets have been documented and explained (Only had 15 meetings instead of 40!) we move onto the hard part, passing the actual code.
Sometimes things are messy with where code actually lives and what the practice is to get there. Normally there isn't a team hand off in projects so we rarely prepare for this, but you know what you should always prepare for? On-boarding new developers. Essentially a team hand-off. Well, it's just a large on-boarding of developers while kicking out the seasoned ones (Now team hand-offs sound like a bad idea, but that's a different conversation, we can't go back now).
In on-boarding a new developer (Or handing off to a team) you want to show how code is managed, how it is pushed, and of course the actual stack behind it. This can all be done with wikis and git, and if you're using GitHub you get both! It's really simple for each component explain what it does, why it does it, how it does it, and what software/stack it uses to do what it does.
The way you write the wiki is simple, give a list of repos pushed to(In a different wiki talk about how your company maintains branches/versions), then record the steps you take from making a code change to getting it on production (minus the git commit -am "removing extra quote that 500s" part).
This is just a long winded way of saying document, write tests, and if you were hit by a bus tomorrow would your component be rewritten or would someone through your documentation be able to keep on using it and developing it?