git团队开发流程
Recently I’ve been thinking a lot about how a developer grows their skills and how the work processes a team maintains contributes to that growth. I think it’s important to establish that the skills I’m talking about aren’t just purely technical ones. ”Soft” skills, especially communication, are just as vital as the “hard” skills.
最近，我一直在思考开发人员如何提高自己的技能以及团队维护工作流程的方式如何促进这种增长。 我认为，重要的是要确定我所谈论的技能不仅仅是纯粹的技术技能。 “软”技能，特别是沟通技巧，与“硬”技能一样重要。
It’s something that I have a strong interest in, having come through a graduate program which has a big focus on helping grads build their skills. In the graduate program, grads had mentors to help you out during the first few months in the company and teach them a lot of core skills. Grads then got to rotate through the business and experience different teams/tech stacks/ways of working before joining a team permanently. In a structure like that, a developer has multiple chances to grow and build up their skillset. But once you’re out of that system, it’s a much different dynamic. Now instead of being in an environment which the key focus is “skill development”, the focus shifts to “delivering features”. This isn’t inherently bad, but it can be difficult to focus on building your skills, especially as a junior developer who’s still got a lot to learn.
这是我非常感兴趣的，因为我完成了一个研究生课程，该课程主要致力于帮助毕业生建立技能。 在研究生课程中，应届毕业生在公司的最初几个月中会提供导师帮助您，并教给他们很多核心技能。 然后，毕业生必须在整个公司中轮流工作，并在永久加入团队之前经历不同的团队/技术堆栈/工作方式。 在这样的结构中，开发人员有很多机会发展和建立自己的技能。 但是，一旦您退出该系统，它就会变得完全不同。 现在，重点不再是“技能开发”，而是重点转移到了“交付功能”。 这并不是天生的坏事，但是要专注于培养您的技能可能会很困难，尤其是作为一个仍然需要学习很多知识的初级开发人员。
So how do you go about growing? The obvious answer is to work on more cards and then you’ll start to get better. They say the fastest way to pick up a language is to go to the country and speak it right? Learning by doing can be a pretty valid way of learning, but this isn’t the most helpful approach, especially when you’re unfamiliar with the codebase. Toiling by yourself when you have features to deliver isn’t productive, and the skills of a developer aren’t only the ability to write code that works.
那么，您如何成长？ 显而易见的答案是使用更多的卡，然后您会变得更好。 他们说最快的学习语言的方法就是去乡下说正确的话？ 边做边学可能是一种非常有效的学习方法，但这并不是最有用的方法，尤其是当您不熟悉代码库时。 当您拥有要交付的功能时，独自劳碌是徒劳的，开发人员的技能不仅是编写有效代码的能力。
So how else are you to build your skills by yourself? Trick question, you don’t have to build them by yourself, your team can help you build them up. It takes a village to raise a child and it takes a team to grow a developer. But it’s not as simple as being in a team and learning by osmosis. The way the team works directly impacts the growth of a developer. Thus, a team should strive to have collaborative processes that help facilitate engaging conversations and critical thought, which in turn will help build a developer’s skills.
那么，您还如何独自建立自己的技能？ 技巧问题，您不必自己构建它们，您的团队可以帮助您构建它们。 一个村庄要养育一个孩子，一个团队要养育一个开发商。 但这并不像在团队中进行渗透学习那样简单。 团队的工作方式直接影响开发人员的成长。 因此，团队应努力建立协作流程，以帮助促进互动性和批判性思维，进而有助于培养开发人员的技能。
那么这些过程中有哪些呢？ (So what are some of those processes?)
代码审查 (Code Review)
A code review is the easiest, “cheapest” process a team can have that helps a developer’s learning journey. It allows good discussion around code quality, making sure that the knowledge of what “good code” looks like in the team is shared and agreed on. Seeing the discussions take place and even talking about your own code is a learning experience for a developer, since it makes sure you can articulate why you did something the way you did.
代码审查是团队可以拥有的最简单，最“便宜”的流程，可帮助开发人员进行学习。 它允许围绕代码质量进行良好的讨论，以确保共享并商定团队中“良好代码”的外观知识。 看到讨论的进行，甚至谈论您自己的代码，对于开发人员来说都是一次学习的经历，因为它可以确保您清楚地说明为什么以这种方式做某件事。
Personally, every team I’ve worked in has used Github PRs for their code reviews, allowing for asynchronous discussion that’s easy to follow and remains there to look back on and learn lessons from.
就个人而言，我工作过的每个团队都使用Github PR进行代码审查，从而使异步讨论很容易遵循，并且可以在那里进行回顾和学习。
The downside to code reviews is that it only catches problems at the end, which means that a developer is still left to themselves while they work on the code, and as we’ve established, that’s not always the most productive approach for both the completion of work AND the development of skills. You could maybe create a draft PR and get feedback as you go along, but sometimes you need real time feedback and advice. I wonder if there’s a way to achieve that…
代码审查的不利之处在于，它最终只会发现问题，这意味着开发人员在处理代码时仍然任由他们自己解决，而且正如我们已经确定的那样，这并非总是最有效的方法来完成代码工作和技能发展。 您可能会创建一份PR草案并随时获得反馈，但是有时您需要实时反馈和建议。 我想知道是否有办法实现这一目标……
卡开球 (Card kickoffs)
Kicking cards off as a team is a really good way to establish domain context for a piece of work and discuss a technical approach at a high level. This helps reduce the possible confusion around a card’s purpose and also spread the knowledge of what can be done to reduce singular dependencies on a developer. If they get sick and the card is picked up by someone else, now you’ve got documented approach on what they were trying to do.
团队协作是建立工作的领域上下文并在高层讨论技术方法的一种非常好的方法。 这有助于减少关于卡用途的可能混淆，还可以传播有关如何减少对开发人员的依赖的知识。 如果他们生病了并且被别人拿走了卡，那么现在您已经对他们试图做的事情有了书面记录。
So how does this help build a developer’s skills? Well, similar to the code review, it helps build communication skills as a developer has to explain what approach they’re thinking as well as the overall reasoning/importance of the card. It also helps provide domain context and provide the chance to see how the work the team does fits into a larger picture. Developing the understanding of how your work fits in the grand scheme of things helps a developer create better or smarter solutions. You need to know your customers to build something good for them, so it stands to reason that you need to know what will consume your code so you can build something that integrates well with it.
那么，这如何帮助建立开发人员的技能呢？ 嗯，类似于代码审查，它可以帮助开发人员提高沟通能力，因为开发人员必须解释他们在考虑哪种方法以及卡的总体推理/重要性。 它还有助于提供领域背景，并有机会查看团队的工作如何适应更大的前景。 加深对您的工作如何适应大环境的理解，有助于开发人员创建更好或更聪明的解决方案。 您需要了解您的客户，以便为他们构建有益的东西，因此，您有理由要知道哪些东西会消耗您的代码，以便您可以构建与其良好集成的东西。
So a card kick off is also another good process that promotes the growth of developer skills, and it especially focuses on the “soft” skills. But it’s lacking in helping a developer grow their more technical skills, like the actual coding side of things. If only there was some kind of way to get the benefits of both processes at the same time…
因此，启动牌也是促进开发人员技能发展的另一个好过程，并且特别着重于“软”技能。 但是它缺乏帮助开发人员提高其更多技术技能的能力，例如实际的编码方面。 如果只有某种方式可以同时获得两个流程的好处，那么……
配对 (Pairing)
Surprise this article is actually one of those “why pairing is good” articles! In my opinion, it’s a near perfect way of helping grow all aspects of developer’s skillset. Now, pairing’s been talked to death as being a positive thing and how we should all do it, and for good reason to be honest. It’s a really effective medium to share problems, ideas, and solutions while working on a card. Just from that description, the benefit for a learning developer is immediately obvious. It’s growing all your important skills at once. You’ll need to effectively communicate what you’re thinking to your partner to explain your ideas, you’re writing code to get the card done and also getting immediate feedback around things like code quality.
令人惊讶的是，这篇文章实际上是“为什么配对很好”的文章之一！ 我认为，这是帮助发展开发人员技能的各个方面的近乎完美的方法。 现在，将配对视为死是一种积极的事情，我们都应该怎么做，并且有充分的理由说实话。 这是在处理卡片时共享问题，想法和解决方案的真正有效的媒介。 仅从该描述中，学习型开发人员的好处就显而易见。 它可以一次培养您所有的重要技能。 您需要与合作伙伴有效地交流您的想法以解释您的想法，您正在编写代码以完成工作，还需要立即获得诸如代码质量之类的反馈。
An underrated aspect of pairing is the reduced attachment of code. It’s harder to become attached to an idea or solution when it’s shared with someone else and they’re willing to rework it. After all, if they worked on it with you and they think it can be better, it’s probably the case right? That reduced sense of ownership is vital for any developer, especially ones that are more junior. Ideas, and code by extension, are malleable and meant to be changed and shaped by new information and other opinions. It doesn’t mean get rid of everything if someone says it’s bad, but it does mean you should be open to changing things. When you’re pairing, this process is happening constantly, and it leads to better solutions.
配对的一个被低估的方面是减少了代码的附加。 与其他人共享想法或解决方案并且他们愿意对其进行重做时，很难将其附加到想法或解决方案上。 毕竟，如果他们与您一起努力并且认为可以做得更好，可能是这样吗？ 对于任何开发人员，尤其是初级的开发人员，降低所有权感至关重要。 想法和扩展代码具有延展性，并且可以通过新的信息和其他意见来更改和塑造。 这并不意味着如果有人说这很不好，就摆脱一切，但它确实意味着您应该敞开心changing。 当您配对时，此过程会不断发生，这会带来更好的解决方案。
There’s a chance you’re reading this and thinking “we do pairing already, our developers are gonna be growing constantly”. It’s good that you’re pairing but is your team really pairing? Pairing comes in many different flavours, and as a team matures its pairing practices, they can adopt what works for them. But to be honest, I know there are a lot of teams that consider “one developer looking as another codes” as pairing, and while that can work, in most cases it’s the more senior developer who’s coding and the junior developer watching, and that’s not conducive to the growth of the junior developer. If they don’t get a chance to write code, that’s most of the benefits we just talked about gone or severely diminished.
您有可能在读这篇文章并认为“我们已经结对了，我们的开发人员将不断增长”。 配对很不错，但您的团队真的配对吗？ 配对具有许多不同的风格，随着团队对配对实践的逐渐成熟，他们可以采用对他们有用的东西。 但是说实话，我知道有很多团队将“一个开发人员看起来像另一个代码”视为配对，尽管这可以工作，但在大多数情况下，是由资深开发人员进行编码，而初级开发人员则在关注，不利于初级开发人员的成长。 如果他们没有机会编写代码，那么这就是我们刚才谈到的大多数好处，即已消失或严重减少。
It’s important that if your team is going to adopt pairing as a common practice, that everyone has a solid understanding of the fundamentals of pairing. It’s one thing to “pair” but it’s another to understand the dynamic and different approaches to work with it. Understanding the role of the “driver” and “navigator” is vital, because then you can figure out how that dynamic can be adapted to best suit your team and environment.
重要的是，如果您的团队将采用配对作为一种普遍做法，那么每个人都必须对配对的基础知识有深刻的了解。 “配对”是一回事，但了解与之合作的动态且不同的方法则是另一回事。 了解“驾驶员”和“导航员”的角色至关重要，因为这样您就可以弄清楚如何才能使动态适应最适合您的团队和环境。
And like with all processes, these approaches are fluid and can be changed as you go along. You don’t have to stick to a single approach forever, you don’t even need to keep to a single approach for the entire team. All that matters is that whatever you do choose to do enables developer growth by allowing active contribution and collaboration. Pairing is hard to get right, but once you do, it pays off exponentially in the long term, especially for any developer that’s trying to grow their skills.
就像所有过程一样，这些方法是可变的，可以随着您的进行更改。 您不必永远坚持单一方法，甚至无需为整个团队坚持单一方法。 重要的是，无论您选择做什么，都可以通过积极的贡献和协作来促进开发人员的成长。 配对很难正确，但是一旦完成，从长远来看，配对将成倍地回报，特别是对于任何试图提高其技能的开发人员而言。
A quick aside about mobbing
快速围攻
Pairing’s hard to get right and mobbing is even harder. I’ve only experienced one team that did mobbing really well, and that was because they already had a strong pairing culture they built off. I think if you dive into mobbing without having done pairing well first, it’s going to be hard to make it effective and not fall into the trap of “senior developer writes code with occasional input from fellow developers”. And realistically speaking, a junior dev might have even less input on these or have their voice drowned out by others. Not due to maliciousness or anything, but if you were unsure of your skills or in the middle of trying to build them up, wouldn’t you feel reluctant to talk when the rest of your team already is?
配对很难正确，而围攻甚至更困难。 我只经历了一支擅长集结的团队，这是因为他们已经建立了强大的配对文化。 我认为，如果您没有先进行好配对就投入了围攻，那将很难使其有效，也不会陷入“高级开发人员偶尔会从其他开发人员那里输入代码的陷阱”的陷阱。 实际上，初级开发人员可能对此没有什么投入，或者他们的声音被其他人淹没了。 不是由于恶意或其他原因，而是如果您不确定自己的技能或在尝试建立技能时，是否会在团队其余成员不愿意说话时感到不情愿？
这对我的团队有什么帮助？ (How does this help my team?)
So we’ve talked a lot about how a team’s processes can benefit an individual, but let’s face it, that’s a lot of effort to put in to just help out a single developer. However, what if I told you that introducing these kinds of collaborative process actually benefits the entire team? It becomes a lot more enticing, huh?
因此，我们谈论了很多有关团队流程如何使个人受益的问题，但让我们面对现实，这是投入大量精力来帮助单个开发人员的事情。 但是，如果我告诉您，引入这种协作过程实际上会使整个团队受益呢？ 变得更诱人了吧？
A key benefit is that these collaborative processes help introduce new perspectives while a team works. The buzz word innovation can be used here but it’s more than just that. If everyone is constantly collaborating, everyone can feel safer introducing their own opinions/ideas, increasing diversity in approach and, long term, that’ll help the team create some really cool things. And that constant innovation doesn’t apply to everything, from code to even the processes themselves.
一个关键的好处是，这些协作过程有助于团队工作时引入新的观点。 在这里可以使用创新的流行语，但不仅限于此。 如果每个人都在不断协作，则每个人都可以更加安全地介绍自己的观点/想法，增加方法的多样性，从长远来看，这将帮助团队创造出一些非常酷的东西。 从代码到流程本身，这种不断的创新并不适用于所有事物。
When you take part in these kinds of processes, in reality you’re actually solidifying your existing skills and developing new ones. When you take time to explain the greater architecture of your application or how a certain code snippet works, you’re actually double checking your own knowledge and sometimes you may even find that you have a gap in what you know. The process of explaining something in general is fantastic way to build your communication skills.
当您参与这些过程时，实际上您实际上是在巩固现有技能并开发新技能。 当您花时间解释应用程序的更大体系结构或某些代码片段的工作方式时，实际上是在仔细检查自己的知识，有时您甚至可能发现自己在所知道的知识上存在差距。 一般而言，解释某件事的过程是建立沟通技巧的绝妙方法。
Now you might be thinking, “Wait a second, all those things you just said is what the junior developer gets out of these processes!” And you’d be right. These processes don’t just benefit a single developer on the team. They benefit everyone. They create an environment where all developers help each other out, constantly swapping between a mentor and mentee role. Everybody wins! A junior developer in a team is really just a coincidental reason a team can embark on this journey.
现在您可能会想：“等等，您刚才说的所有这些都是初级开发人员从这些过程中得到的结果！” 而且你会是对的。 这些过程不仅使团队中的单个开发人员受益。 他们使所有人受益。 他们创建了一个环境，所有开发人员都可以互相帮助，在导师和受训者角色之间不断交换。 每个人都赢了！ 团队中的初级开发人员实际上只是团队可以踏上这一旅程的一个偶然原因。
git团队开发流程
1829
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
