今日推薦開源項目：《小遊戲 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遊戲大全