在本文的第一部分（点击此处链接至第一部分）中，我讨论了代码本身的组织：架构、整洁代码以及 SOLID 原则。但是，如果周围的团队没有清晰的版本控制、文档和工作流程，那么仅仅写出良好的代码是不够的。这正是我现在想要讨论的内容。
我已经这样做了一段时间——只是我不知道它的名称
我记得一位同事让我“从开发分支创建一个功能分支”。我几乎不假思索地完成了，因为这正是我多年来一直在做的事情。但就在那时，我突然意识到：“等等……这有个名字吗？”
就这样，我发现我一直在使用的那种“自动”工作流程——稳定的主分支、功能分支、隔离的热修复分支——已经有了一个正式的名称：Git 工作流。
而且这并不是唯一的一次。在我的职业生涯早期，遵循指示（“这样做”、“遵循这种模式”）而不理解原因，甚至不知道背后有理论支持，是很常见的。实践往往先于名称出现，直到后来——出于好奇，或在与另一位开发人员的交谈中——你才会发现你已经正在做的事情的正式标签。这不是能力不足，这只是日常学习的自然顺序。
我认为这说明了我们是如何习得良好实践的——有时也包括不良实践 😅
我们经常出于必要而内化某种行为，这并不自动意味着它是对是错——只有后来我们才会去追溯它的真正来源。将“名称”与“事物”联系起来需要时间，这是正常的。在这里值得小心的是：很容易假设一个流程是正确的或最佳实践，仅仅因为有人告诉你那样做，而实际上你可能只是固守一种习惯。保持好奇心，在进行动手实践的同时进行研究和学习，才能随着时间的推移建立真正的清晰度——并让你能够向接下来加入团队的任何人清晰地解释该流程。分享你正在从事的项目的技术知识也是你的责任的一部分，这正是其如此重要的原因。
文档：没人读但每个人都怀念的“整洁代码”
文档往往被视为次要任务——直到有一天新成员加入团队，却不知道如何设置环境或为何做出某些架构决策。一份写得好的自述文件、一些策略性的注释（而非过多的注释）以及记录下来的架构决策，毫不夸张地说，能在项目的生命周期中节省数天的工作时间。
Scrum、Kanban 以及适合每种上下文的方法
在流程方面，我根据项目的性质混合使用 Scrum 和 Kanban。对于具有明确截止日期和范围的交付，Scrum 的冲刺节奏有助于建立可预测性。对于持续维护或小型小队，Kanban 的可视化流程通常更合适，因为它避免了那些对于小团队来说并不总是有意义的仪式所带来的额外负担。
敏捷方法论并不是关于遵循规则手册——而是关于让正在进行的工作可见，并减少编码人员与依赖这些代码的人员之间的沟通摩擦。许多人认为这是过度设计或不必要的流程，但恰恰是在其缺失时，其价值才变得显而易见。
归根结底，这是为了下一位开发人员
将本主题的两个部分结合起来——整洁架构、SOLID 原则、明确定义的版本控制、文档以及真正有意义的敏捷流程——所有这些都汇聚成我在每次拉取请求前试图问自己的一个问题：如果其他人打开
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
