• 开源镜像
  • 开源沙龙
  • 媛宝
  • 猿帅
  • 注册
  • 登录
  • 息壤开源生活方式平台
  • 加入我们

开源日报

  • 开源日报第642期:《没有人 sense-hat-devilman》

    17 12 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《没有人 sense-hat-devilman》
    今日推荐英文原文:《Pearls of Wisdom for the Junior Developer》

    今日推荐开源项目:《没有人 sense-hat-devilman》传送门:GitHub链接
    推荐理由:看视频的时候,不管再怎么模糊,是什么样还是能看个大概的。因为分辨率再怎么低好歹也有个三位数乘三位数,但是再缩小一点会怎么样呢?这个项目用一块板子上的 8×8 分辨率播放了恶魔人的视频,如果没有对比图甚至看不出来这是什么样子,完美阐释了只可意会不可眼观的低分辨率真理……

    今日推荐英文原文:《Pearls of Wisdom for the Junior Developer》作者:Jamie Morris
    原文链接:https://medium.com/better-programming/pearls-of-wisdom-for-the-junior-developer-a906e708d4e6
    推荐理由:作者分享的经验之谈

    Pearls of Wisdom for the Junior Developer

    50+ Things I wish someone had told me back then

    I recently had the pleasure of sitting on a panel of experts providing guidance to a room full of “emerging talent” (a fancy term for junior developers).

    It was basically a Q&A in which we were supposed to provide pearls of wisdom drawn from our careers and experiences. I’m not sure what the hell I was doing there, but I’ve always said that everyone has an opinion, and everyone is entitled to mine.

    Anyone who knows me knows that I’m quite verbose. You may have noticed it in how I write, but until you’ve spoken to me in person, you don’t know the half of it.

    So, with limited time and four other people to share the stage with, I was unable to share all of my nuggets of knowledge with the audience.

    I resolved to set it down in writing for the sake of future generations, who may hopefully look back on these words as some kind of Sun-Tzu for career development in the world of software… development.

    Here goes nothin’.
    1. A little arrogance goes a long way, but a lot of arrogance gets you nowhere. Don’t overestimate your ability, but don’t undersell it either.
    2. Ignorance is not a crime, and you will impress people more with humility and an eagerness to learn than you will by trying to be aloof. One of the best developers I ever worked with readily admitted when they didn’t know how to do something.
    3. You don’t get a pay rise just for breathing — you have to earn it by growing.
    4. That said, if you did a good job, don’t walk out of your yearly review without something to show for it.
    5. If you didn’t learn anything new in the last year, it’s time to move on.
    6. Try working at an agency at least once — the pace of work will hone your raw skills quickly.
    7. Try working at a startup at least once — the thirst to innovate will serve you well and the culture is second-to-none.
    8. Try working at a big corporate at least once —they will have unique opportunities and room to grow.
    9. Try working for yourself at least once — you’ll learn to appreciate what sales guys do for your product.
    10. Find something that your team isn’t doing and become an expert. It might not even be technical.
    11. Don’t underestimate the value of soft skills — the ability to speak in front of an audience is a rare treasure in the software development community. Couple it with technical know-how and you will go far.
    12. Learn to love keyboard shortcuts. If you had to use the mouse, you failed.
    13. Always look for ways to automate your work. One of the best developers I know, before he even became a developer, managed to automate his job down to a single button press.
    14. Pair-programming is hard, but worth it. It makes you feel vulnerable and tires your brain faster than working alone. But the quality of your work will grow beyond your individual boundaries.
    15. Everyone feels like an imposter sometimes. It’s OK to feel like that, and it’s OK to talk about it openly.
    16. I’ve been calling myself a senior developer for much longer than I actually was one.
    17. Don’t believe in the myth of the rockstar developer. Everyone wants to be one, but it’s a backhanded compliment. Axl Rose is a rock star, but notoriously difficult to work with.
    18. Teach. Coach. Mentor. If you have a small amount of skill, share it. Don’t hoard it. You will hone your skill more by teaching than by any other means.
    19. Respect your user. They might not be technical, but their opinions are more valid than yours because they know the problem you need to solve, even if they can’t always articulate it.
    20. Beware your user. Sometimes, they will ask for thing they don’t really need. It’s your job to help them find the true value in the requests they make.
    21. Believe in your principles, but be willing to let them go when you need to. I believe in TDD, but learned that doing it in a one-day Hackathon is a recipe for failure.
    22. Don’t become tribal — as soon as you start thinking about “us” and “them” you forget that you are flawed, too. Empathy is as critical to development as technical ability.
    23. I’ve often openly cursed the quality of other peoples’ code, only to discover that I wrote it six months ago. There are better ways to learn humility than looking like an idiot.
    24. Don’t leap to conclusions. It can be tempting to run off half-cocked if you think you know the answer to something, but make sure you are right before you make a bad impression.
    25. Figure out early how you learn best. Some people like to read, some people like to listen, to watch, to do. Find your favorite and utilize it.
    26. The best career move I ever made was to take a pay cut in order to learn from the best team I could find.
    27. If you are lucky enough to be offered training at work, don’t turn it down. How many industries pay you to be educated?
    28. But don’t forget that you have a day job. Don’t sign up for every training course — pick the ones that you need and leave yourself time to put your new skills into practice.
    29. Learn to say: “No.” Your time is precious, and at larger companies you will be invited to more meetings than you possibly need to be in.
    30. Sometimes, you will want to say: “Yes,” because you are genuinely enthusiastic about what you are being asked to do. Even so, there are only so many hours in the day. Pick the things you want to say yes to.
    31. Don’t wear long hours like a badge of honor. If you have to work overtime every week, something is wrong. Work smarter, not harder.
    32. Be willing to learn something new while it is still new. Don’t wait for everyone else to get ahead of you.
    33. Don’t learn every new thing — if you already have a good tool for the job, learning to use a different tool for the same job won’t give you as much as you think.
    34. Then again, sometimes you don’t know a tool is broken until you find a better one.
    35. Stop arguing about Angular vs. React or Java vs. C# or Android vs. iOS. They are all valuable, and nobody is impressed by your slavish dedication to a cause.
    36. Learn regular expressions — they will make your life easier, eventually.
    37. Even if it takes you a week to set up your development environment just the way you like it, you will be using it for years to come. Get it right and don’t settle for things that will piss you off 50 times a day.
    38. Keep your C.V./resume up to date, even when you aren’t looking for a job. You never know when an opportunity will come up.
    39. A personal letter from you to a company is much more effective than an introduction via a recruitment agency. Remember that recruiters charge a fee to the company, so it may just not be economical to hire you that way.
    40. Don’t stop when you see an obstacle in the distance. Go and push against it to find out if it has substance — you may find the obstacle is paper-thin. Trying to overcome the obstacle is often easier than you think it will be.
    41. Working from home requires a lot of discipline. Be honest with yourself before you decide that office life isn’t for you.
    42. Dress for the job you want. That doesn’t mean you should come to work as an astronaut, but there’s nothing wrong with a shirt. I wear a waistcoat to work so that people remember me even when they don’t know my name. Build your personal brand.
    43. Beware of hard and fast rules. In my experience, most people who think in black and white don’t understand why the rule exists. If you understand why, you will spot the grey areas immediately.
    44. It’s often tempting to complain, but try to remember the good things about your job. If you forget, then write them down. Not everyone is as lucky as you are to have such a great industry to work in.
    45. If you do feel the need to complain, try to affect change instead. It is much healthier and much more impressive than whining.
    46. Practice your written and verbal communication. These are important skills that will set you apart.
    47. Test-driven development isn’t just a pie in the sky idea — people actually write tests first and reap the benefits. I see lots of people who never got around to writing tests because implementation is more fun.
    48. Lack of automated tests will paralyze your ability to maintain a project further down the line. Don’t fall into that trap.
    49. Testing code after the fact is hard, because you often need to refactor to make the code testable. Refactoring without tests is risky, so I will say it again — practice TDD.
    50. Not all great opportunities pay well, and not all well-paid opportunities are great.
    51. It’s OK to feel intimidated by people who seem smarter than you, but remember that most people only show you what they want you to see. Inside, they might feel intimidated by you.
    52. Find clever people and stick to them.
    53. Find friendly people and stick to them.
    54. If you can find people who are friendly and clever, don’t let them out of your sight.
    55. Look after your health. You are lucky enough to work in an industry that doesn’t punish you physically, but that’s no excuse to neglect physical fitness. It will make you feel better.
    56. Don’t go home every night and code. Take a night off once in a while. Don’t spend your life looking at a screen. Take the dog for a walk.
    57. Look up from your phone when you are on the bus or the train. Make eye contact. Smile.
    58. Try to remember the names of people you interact with infrequently. People love the sound of their own name spoken by someone else.
    59. If you can solve another person’s two-hour problem in five minutes, do it. Their time is precious too, and you never know when you might need help from someone else.
    60. When you do need help from someone else, be sure that you gave it a decent shot first. You will learn a lot by having a go first.
    61. Don’t slave away at a problem forever if you can ask for help. Know when you are beaten.
    62. You might love your career, but if you hate your job, find another one. Life is too short to spend half of it being unhappy.
    63. Don’t put off paying into a pension — you’ll need it one day.
    64. Start designing your application as close to the user as possible. It will be easier to validate that you’re doing the right thing.
    65. Be honest in your job interview. The interviewer has heard the same old answers to every question, including all the bullshit reasons why you want to work there. “What attracted me about this job? The salary and the tech stack.”
    You know what? I’m just going to keep adding to this ever-growing, sometimes contradicting and repetitive, mess. Maybe some of it will actually be useful.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第641期:《只狼 Sekiro》

    16 12 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《只狼 Sekiro》
    今日推荐英文原文:《What It’s Like to Write Software on a Team》

    今日推荐开源项目:《只狼 Sekiro》传送门:GitHub链接
    推荐理由:年度游戏不出所料的落到了只狼手上,那么这个时候自然也要趁着热闹入坑……然后看着屏幕中间那个大大的死字。这个项目列出了玩只狼的备忘清单,大概把流程里需要注意的道具等都列了出来用于备忘,对于收集要素不少而且能够提升实力的游戏来说扫一眼备忘自然是好事,但是有一说一,不死个几十次该打不过的还是打不过……

    今日推荐英文原文:《What It’s Like to Write Software on a Team》作者:Obaid Farooqui
    原文链接:https://medium.com/@obaidfarooqui/what-its-like-to-write-software-on-a-team-ccb6a70a1eaa
    推荐理由:写软件和写小说

    What It’s Like to Write Software on a Team

    Imagine you are on a team tasked with writing a novel.

    At first you all huddle together and figure out what it’s about. Who is the intended audience? What will readers take away from the book? You hash out the arc of the story, the characters, how they’ll interact with each other to drive the plot forward.

    Your team starts to storyboard, passionately debating each other as you bring this story to life on the whiteboard. You squiggle, you erase, you draw diagrams and write a few paragraphs here and there to show that this story can work. You align on a vision of what this novel will be.

    And then, the real work starts. You open up a shared Google Doc, and each person takes a chapter, or a portion of a chapter, and starts writing, at the same time. Some people take on characters instead of chapters; others focus on a specific event in the story, perhaps the climax or a scene of rising action. This is fine- it takes some planning, but you can write your part as your teammates write theirs, as long as you all know what everyone is working on and how your part interfaces with everyone else’s.

    Sometimes someone has a brilliant idea to change how their part reads: maybe they want to end their chapter on a cliffhanger, or engage in a little foreshadowing. What they do in their section affects the sections before and after as well, and so they must communicate to ensure the novel flows logically.

    Then there’s the question of voice. You want the novel to read smoothly and consistently, and not vary wildly from chapter to chapter. Not only does this make it pleasant for the reader, it also makes it easier for someone to come in and make edits in the future. So teams must agree on what that voice is, and must edit each other’s work to iron out the differences in style. This means agreeing on mundane things like whether to use oxford commas, as well as on more subjective things like how funny or formal you want the characters to sound.

    Now let’s throw in some illustrators and designers into the mix too. They’ll play with fonts and sizes and colors, as the Google Doc continually unfolds. They’ll design a book jacket, and maybe add some drawings or graphs or photos. Ideally, they make their designs bespoke for what you’ve written and it’s exactly what your team wants. But sometimes they may draw something that doesn’t fit the tone you’re setting, or illustrate a scene that has changed given the latest edits. You need to work with them to modify those artifacts, as your team continues to write this book.

    Sometimes people from outside of your team will want to have a say in what you write. Marketing might come to you and tell you that your novel needs a vampire to be commercially viable with teenagers. Sometimes legal wants you to take something out- maybe you can’t call your villain Vuelo de Muerte because it’s too close to someone Who Must Not Be Named. You have to negotiate how you write those things in, and sometimes you’ll win your battles but other times you just have to throw in a werewolf because the folks upstairs want one. All this while the Google Doc is continually evolving.

    Writing a sizable novel in this manner will take some time, and as a result, maybe the team grows or churns as well. The original storyboarding must be clear and instructive enough, and the writing in the Google Doc must be consistent and cohesive enough, that a new person can walk onto the team, spend some time familiarizing themselves with the story, and begin editing and writing where someone else left off, without any noticeable difference to anyone reading.

    Finally, at the end of all of this, your team produces this book. It is a work of art. You know how much effort went into it, and you are more astounded than anyone that it is a cohesive, comprehensible, dare you say enjoyable piece of literature.

    And that, in a nutshell, is what it’s like to write software on a team.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第640期:《三语精通之四 less.js》

    15 12 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《三语精通之四 less.js》
    今日推荐英文原文:《Developers Should Be (a Little Bit) Reckless》

    今日推荐开源项目:《三语精通之四 less.js》传送门:GitHub链接
    推荐理由:虽然不管是在现实世界还是虚拟世界里同时掌握中日英这样三种现实语言的人并不多,但是 web 开发里掌握 html+js+css 也算是一种三语精通——虽然在这之上还有第四第五种。这个项目是一种动态样式表语言,为 css 引入了基本编程语言里常见的变量和计算等,尽管在这之上需要额外的配置和编译,但是以此为代价换来了免去的重复作业和更好的可读性,在诸如样式表层层叠叠过于细致等等的时候可以换来不少好处。

    今日推荐英文原文:《Developers Should Be (a Little Bit) Reckless》作者:Tom Feron
    原文链接:https://medium.com/better-programming/developers-should-be-a-little-bit-reckless-3d2521ad9641
    推荐理由:所谓系统,总归有要出问题的时候,预防它和修好它都一样重要

    Developers Should Be (a Little Bit) Reckless

    Why you should embrace and plan for chaos

    Any software project has to make a trade-off between building new features and making the current system more resilient and easier to maintain.

    Too often, management pushes for new features and, before you know it, you end up with a big ball of mud where any change takes ages due to the accidental complexity that gathered over time.

    Complexity leads to bugs and soon enough, changes become risky. Developers get terrified at the idea of shipping anything but trivial things. Badly needed improvements to the codebase are too involved and, therefore, don’t get done. This is a vicious circle you don’t want to get into.

    The key to solving this issue is building resilient systems.

    Resilient systems allow for innovation to happen. If services are unlikely to crash or even perform badly when mistakes are made, the risk associated with code changes is reduced and, therefore, new features and refactoring are easier to ship so you can escape the vicious circle.

    There are two ways of making software development more resilient: putting the responsibility onto people or relying on machines.

    The first approach requires developers to follow guidelines and procedures, to double-check everything before they merge something new. This can put a lot of pressure on them.

    You might have seen or experienced this yourself: someone avoids making a big change for fear of breaking something and being blamed for it.

    Alternatively, you can see bugs and outages as things that were allowed by the systems in place. It is not the responsibility of the person who shipped it anymore. Your system is the one that needs to change.

    Virtuous and vicious circles are two sides of the same coin. The situation gets a lot more enviable when computers are responsible for making sure the services are running properly.

    As the confidence in the ability of the system to prevent or fix errors grows, developers and other people in the company will become more reckless.

    This is a good thing. Having a safety net allows you to be bold and experiment with new things. It fosters innovation and increases the speed at which improvements can be shipped.

    Sure, it might break now and then but overall resilience increases as a result.

    Antifragile Systems

    In his book Antifragile, Nassim Taleb develops the concept of antifragility as being different from resilience. Antifragile systems gain from shocks.

    A software project throughout its lifetime is an evolving creature. New features come in, bugs are introduced and others are fixed, the code is refactored.

    In that sense, we should aim to build antifragile systems. That is, problems should lead us to improve the resiliency of the system over time.

    Trying to eliminate the problems upfront by requiring developers to be disciplined and meticulous is doing the project a disservice since it does not lead to improvements to prevent these mistakes in the first place.

    Embrace the chaos and build antifragile systems.

    How Do I Start?

    If the project is brand new, it’s easy. Allow yourself and others to be reckless by not blaming anyone and by treating problems in production as learning experiences to improve resilience.

    But what about projects that are already there? They might be brittle and any downtime is expensive.

    In that case, start by establishing a list of all the ways production can break. Look back at the past and see if there have been problems that could happen again.

    This should be a living document where new problems are added as they arise. If a potential issue is caught during code review, it should be added to that document as well.

    The next step is to decide what the best way is for you to prevent these things from happening and to prioritize them.

    If you don’t know what to prioritize, try assigning a value from one to three to each item on your list for severity — how much it would impact the company and how hard it is to solve — and likelihood — how likely it is to happen.

    The product of the two determines which ones to tackle first.

    And finally, stop blaming people for outages and phrase post-mortems in terms of why the system allowed it to happen in the first place and how they should be fixed.

    How Do I Avoid (Too Much) Chaos?

    Being reckless increases the probability of breaking something. Even if it helps pointing you to what needs to be fixed, it certainly should not happen too much.

    In their books (available for free), Google’s SRE team introduces the concept of an error budget. In its simplest form, it could be the acceptable downtime over a week. The chapter Service Level Objectives is particularly interesting.

    After the error budget has been consumed, changes to production should be postponed unless urgent. That way, you limit the amount of chaos you introduce.

    Also worth noting is that Kubernetes has disruption budgets that can be leveraged for that purpose.

    Chaos Engineering

    The previous section was about limiting chaos, but what about increasing it a little bit?

    In addition to discovering new ways in which things can break you didn’t think of, it can help to set expectations for other teams and customers. This might be counter-intuitive but too stable a system is not necessarily good from a commercial point-of-view either.

    What happens when you have a serious outage that lasts a couple of hours? If other teams and customers expect your service to always be up and responsive because it always has been so far, they probably haven’t catered for this scenario. It means trouble for them and, by extension, for you as well.

    On the other hand, if they expect your service not to respond sometimes or for some requests to be slow, maybe they would have implemented a cache or better exception handling.

    Taking the opposite point-of-view, you might have expectations about services that you consume which are not going to hold forever. Deliberately dropping or slowing down packages to and from a third-party service can force you to make your code more resilient to problems on their side.

    Chaos engineering, introduced by Greg Orzell when he was working at Netflix, is:
    “The discipline of experimenting on a system in order to build confidence in the system’s capability to withstand turbulent conditions in production.”
    The most notable tool for chaos engineering is ChaosMonkey which randomly kills virtual machines and containers in your environment.

    If you are a service mesh or something similar, you might want to look into introducing errors and delays in the network. For example, Istio provides support for fault injection.

    Conclusion

    To keep momentum and foster innovation, developers should be free to explore new areas instead of stressing about breaking things.

    They should be allowed to be bold and reckless thanks to the safety nets provided by automated controls. This (limited) chaos, in turn, makes the system stronger over time.

    This can only happen if everyone involved agrees on prioritizing work required to prevent problems from happening again when they do occur.
    下载开源日报APP:https://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
  • 开源日报第639期:《小游戏 Games》

    14 12 月, 2019
    开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文,坚持阅读《开源日报》,保持每日学习的好习惯。
    今日推荐开源项目:《小游戏 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://opensourcedaily.org/2579/
    加入我们:https://opensourcedaily.org/about/join/
    关注我们:https://opensourcedaily.org/about/love/
←上一页
1 … 98 99 100 101 102 … 262
下一页→

Proudly powered by WordPress