今日推荐开源项目：《小游戏 Games》
今日推荐英文原文：《How to Take the Pain Out of Your Software Handoff》
今日推荐开源项目：《小游戏 Games》传送门：GitHub链接
推荐理由：写游戏可以说是成就感满满的事情了，毕竟小时候电子游戏可是说是完全高大上的科技产物，但是现在有了技术就能触手可及。这个项目使用 Python 写了不少简单的小游戏来作为学习的副产物，包括古老的打飞机和坦克大战等等，在拥有足够知识之后再看这些游戏脑海里自然而然就能浮现出实现的思路来，这便是学习最好的收获了。
今日推荐英文原文：《How to Take the Pain Out of Your Software Handoff》作者：Allan Wintersieck
原文链接：https://medium.com/@wintersieck/how-to-take-the-pain-out-of-your-software-handoff-755374a7bba7
推荐理由：当你需要将项目转手交给下一个队伍时……
How to Take the Pain Out of Your Software Handoff
It’s often difficult to hand off of an existing software project to a new development team. Fumbling the handoff can cause delays, downtime, and animosity between the teams or companies involved.Handoffs are an inevitable part of software development (no one works on everything forever!), yet the same hiccups tend to happen time and time again.
Whether or not you’re the old team handing off a project or the new team taking it on, there are a few steps that can be taken to ensure a smooth transition between teams.
Documentation
We all know documentation should be kept up regularly but if we’re honest with ourselves, we know it often gets thrown to the back burner. Documenting code is easy during development, while you remember what’s going on, but it gets harder the longer you wait. It’s usually a simple task and we know it’s important, so why isn’t it prioritized?In my experience, documentation is simply forgotten. During active development, no one needs it right now, so there’s little incentive. Then hand-off time comes and the README on how to boot up the code is 2 years out of date, has old references, or is just plain wrong.
What do you do then? Most likely, you bang your head against the faulty documentation, waste time tracking down errors, and eventually find that one library that was out of date. Guess what, though? The documentation still doesn’t get updated.
It’s a two way street — whether you are handing off the code or getting handed the code — when you learn something new that could be useful to others, make an effort to update those docs.
Coding can be very selfish in this way. If it’s not an immediate problem, you’re probably not going to worry about it. Have the forethought to document now so you can get in those good habits, and set yourself up for success later. Documentation isn’t needed until it’s really needed. So do it now, and your future self will thank you.
Pairing and Co-Working
There’s no better way to learn a code base than to get your hands dirty.Whoever the new team is that’s taking responsibility (even if there aren’t any immediate tickets/needed work), make sure they boot up the code locally as soon as possible. The best case is to have a solid few weeks of overlap where the incoming and outgoing teams work in the code, both individually and side-by-side.
If there’s no time to overlap and work through new issues together, at the very least set some time aside (2–3 hours) to walk through the basics together.
Go over the documentation with the whole team and lean on each other to improve it. Talk about past lessons learned and try to migrate some of the old team’s tribal knowledge to the new team. Without all the original context of the project, you’ll likely come across oddities and inconsistencies — the time to talk about them is during the handoff. The new team should be getting all the information they can at this point so as to not make the same mistakes the old team ran into.
Long Term Plan
If the majority of the feature sets are done, you’ve hopefully gone through a successful release. It could be the case that the main development team is departing and another team has to take over maintenance, hosting, and potential updates.Even without new features, the work is not done. A common pitfall is thinking the hard part is over, and everyone can go on autopilot. While there’s hopefully some stability in the system, the upkeep on any code base can be time consuming. A stagnant code base is a dead code base.
Assume at least 5 hours/month should be attributed to updates (library, security, etc) and double-checking database backups, server health, and the like. You can read another article about why software updates are so important here.
Those 5 hours/month don’t usually account for bugs, though…
A common misconception is that if you go with the very best developers, the code will be perfect and bug free. While we all strive for the very best code, the simple fact is that bugs are a byproduct of software. Assume there are bugs in the system, and have a plan and process in place to track them down and squash them. It’s important to keep your development and staging/test environments up-to-date for this reason alone.
When taking over software, it’s easy to forget the ‘other’ (DevOps) stuff, and it needs some long term planning. It’s no fun to find out later that there’s no true production environment, there are no CI/CD pipelines, or your SSL certificate will soon be out of date. As with most things, the earlier you know something is wrong, the better. So make sure someone is asking the right questions and don’t assume that just because it works now, that it will work for long.
Mindset and Culture
While it seems odd, culture might be the single most important factor in taking over/handing off a software project.It’s very tempting to blame the old team for everything, but you shouldn’t. This can become the de facto excuse for every problem. Bugs? Missed deadlines? All because of the old team’s code, poor architecture decisions, or any number of ‘passing the buck’ excuses.
It is tough to take on new code, and often the best we might say is, “this isn’t the way I would do it.” But remember that you don’t always have all the context on why the original decisions were made, and the original developers may have had good reasons for everything they did.
Be careful of endless refactoring. The new team may want to remake the whole thing however they see fit, but you have to strike a balance between letting them take ownership and not wasting time. This can be the hardest part of the handoff. Stepping outside of your opinions and recognizing that, while this might not be the way you’d do something, it does work fine as-is and therefore there’s no reason to change it.
Both teams should have the same end goal here. The old team should stay in contact over the weeks following the handoff if at all possible. Most questions that might take a developer a few hours to track down could be answered in a few seconds by someone from the old team. Again, have some compassion that this process is difficult, and hopefully the old team will be willing to help.
The Unfortunate Corner Cases:
While we want to always assume that every handoff involves one perfectly solid and reasonable software team taking on code from another perfectly solid and reasonable software team, it’s not always the case. If the code has gotten into a messy state and you find yourself working with a house of cards situation (if you sneeze, the whole thing might explode), we find these steps can help:- Put some quick end-to-end tests in place ASAP as a sanity check. This will help you know when you break existing functionality accidentally.
- Break the code base into chunks: new and old. If you touch the old parts, then you have to bring it up to the quality of the new parts (test coverage, etc.)
- Recognize what can be kept and what still presents risk. A chunk of code that you never touch but works is probably fine. A separate service that nobody knows how to restart if it goes down is not fine.
Conclusion
Communication is key. It’s an easy sentiment, but it can be hard to follow in software development.When handing off a software code base, no matter the situation, over-communicate the action items, the responsibilities, and the process going forward. Ensure everyone is bought in, and start early. Triple check the documentation and work to make it better at all times.
Finally, it can be hard to sync old and new teams, particularly when culture tends to be a behind-the-scenes area of contention. Different teams may have not have the same ideas about what’s important, how the pipelines should be setup, how PRs should work, etc. That’s OK! It all goes back to having empathy, being reasonable about where the other team is coming from (without enforcing your methods and culture on to them), and working through the problems together!
下载开源日报APP：https://openingsource.org/2579/
加入我们：https://openingsource.org/about/join/
关注我们：https://openingsource.org/about/love/
今日项目堪称：Python游戏大全