当更改代码中过时的部分(例如HAML视图、jQuery模块)时，请使用是否重构的酌处权。对于长期的可维护性，我们非常感兴趣的是将旧代码迁移到一致和首选的方法(例如Vue、GraphQL)，但我们也对用户会喜欢的特性感兴趣。
    目的用首选的方法实现新的模块或特征，但改变原有的不合格部件是一个灰色区域。
    如果重构和其他约束(如时间)的权重可能威胁到功能的可用性，那么请在另一个时间强烈考虑重构。另一方面，如果所讨论的代码损害了可用性或对其构成威胁，那么请考虑优先考虑重构。这是一个平衡的行为，如果你不确定你的改变应该去哪里(或者你是否应该在手之前做一些重构)，联系另一个工程师或维护人员。
    如果在实现新功能或更改之前进行重构是有意义的，那么请：

    1.   - 为重构和更改创建单独的合并请求。这有助于维护性和代码评审。
    2.   - 通知你的工程经理和相关的利益相关者(最好是在一个问题的评论)有关的范围扩大和理由。

    如果决定不若要在此时进行重构，请：

    1.   - 确保这种重构存在描述性的“技术债务”问题。
    2.   - 通知工程经理，以便对重构问题进行加权和调度