只有完美代码不够的，如何做一个完美的Pull Request？

    <li>
        <span>
            <span># </span>
            <span>First</span>
            <span> Crew Dragon launch was postponeddue </span>
            <span>to</span>
            <span> bad weather, </span>
        </span>
    </li>
    <li>
        <span>

         #  and
 now we needan event 
for
 the 
“second”
 
first
 launch. 

2.描述清晰

有关pull request的描述为审查者提供任务最初的上下文，包括：

• 标签的链接。
• 对已完成事件的总结(如果不能从pullrequest的标题中看出)。
• 相关pull request的链接(例如在另一服务中的相关变化)。

不要把自认为理解代码需要的信息放在对pullrequest的描述里，应当进行代码注释：它们的效果更加显著，有助于未来代码阅读者的阅读。

3.精简pull request

这是一项强大的技术，谷歌甚至就小型pullrequest的益处单独写了一篇文章(https://google.github.io/eng-practices/review/developer/small-cls.html)。以下是笔者最喜欢的小型pull request的特点：

• 审查更彻底
• 审查更快捷
• 更易合并(频繁的合并能减少冲突)
• 如果被拒绝，浪费的精力更少

完美代码不够的，如何做一个完美的Pull Request？” src=”http://p3-tt.byteimg.com/large/pgc-image/c45bb9b527d34589a0668ca995cfb9ba?from=pc” width=”554″ height=”36″>

4.快速回应审查

处理审查注释通常比较费时，需要修复打字错误、添加遗漏的测试案例、对方法重命名等。如果你能快速完成，你的同伴就能花更少的时间来记忆与pull request相关的信息。
但这种方法的缺点是会增加上下文切换的工作量，替代方法是使用番茄工作法(Pomodoro technique)：每工作25分钟穿插一次短暂的休息。它能让人更专注、更有成效、更健康，并减轻疲劳度，休息后的上下文切换也会进行得更加自然。负面的破坏性影响虽然没有消失，但是会大大降低。

5.给自己的pull request注释

完美代码不够的，如何做一个完美的Pull Request？” src=”http://p1-tt.byteimg.com/large/pgc-image/f316334d8f60461db31c70de42023672?from=pc” width=”554″ height=”183″>

8.在实现功能之前讨论整体方法

这可以省下很多时间。在要处理更复杂的重构和功能之前，先与同事讨论一下方法。与其他的开发人员讨论，解释这项任务和你的想法，他们也许会表示赞成，也许会提出更好的方法。
很多时候笔者都面临着初步协调的缺失，好几天的工作成果白白浪费。想象一下你连续五天做一件事情，结果却听到“对不起，其实我们不需要……”想要把自己从失望中拯救出来，你得尽早获得反馈。
未丽燕TEL：（010）68476606】