【问题标题】:Etiquette for refactoring other people's sourcecode? [closed]重构他人源代码的礼仪? [关闭]
【发布时间】:2010-03-26 09:39:44
【问题描述】:

我们的软件开发人员团队由一群经验丰富的程序员组成,他们具有各种编程风格和偏好。我们没有针对所有事情的标准,只有防止彻底混乱的基本必需品。

最近,我遇到了一位同事所做的一些重构。我的代码看起来有点像这样:

public Person CreateNewPerson(string firstName, string lastName) {
    var person = new Person() {
        FirstName = firstName,
        LastName = lastName
    };
    return person;
}

重构为:

public Person CreateNewPerson (string firstName, string lastName) {
    Person person = new Person ();
           person.FirstName = firstName;
           person.LastName = lastName;
    return person;
    }

仅仅因为我的同事需要在我写的一个类中更新一些其他方法,他还“重构”了上面的方法。郑重声明,他是那些鄙视 syntactic sugar 并使用与我们其他人不同的括号放置/标识方案的开发人员之一。

我的问题是:(C#)程序员重构其他人的源代码(语义和句法)的礼仪是什么?

【问题讨论】:

  • 你应该把它变成一个社区维基。
  • 至于礼仪,最好的办法可能是与他对质,让他知道你不喜欢他重构你的代码。您还可以更微妙地播放它并还原您的代码并更改他的代码以匹配您的风格。虽然一开始很有趣,但最终可能什么也得不到。
  • 我确实将它恢复到我的版本,并将其签入到 SVN 中,并附上评论“改进的代码一致性”。之后没有进行任何更新。当我把它告诉他时,他或多或少地承认这并不是真的必要。所以基本上,我们同意除非需要,否则不碰对方的代码。
  • “同意除非需要,否则不碰对方的代码”——这是一个错误。你的团队需要解决这个问题——这样它才能真正作为一个团队工作。建立每个人都可以接受、每个人都可以遵循的标准——然后每个人都将重构(实际上是重新格式化)到同一个目标。
  • 我会是那些将第二个版本重构为第一个版本的人之一......

标签: c# refactoring


【解决方案1】:

我会少担心礼貌,多担心经济问题。每次代码更改都会产生大量成本:

  • 代码更改必须经过 QA 测试
  • 代码更改必须有开发人员为其编写的测试套件
  • 可能需要记录影响用户体验的代码更改
  • 代码更改可能会引入错误;这些显然是巨大的成本
  • 等等。

我不会梦想对任何生产质量代码进行微小的“仅美学”更改,无论它是否是“我的”。变革带来的好处远不及成本的合理性。

您可以考虑提醒您的同事,您从事编码业务的目的不是为了编写大家都觉得美观的漂亮代码,而是为了在经济疲软的情况下为您的公司创造利润。你不是艺术家,你是工程师,所以要像工程师一样行事;所有更改都应有商业目的。

【讨论】:

    【解决方案2】:

    我相信collective code ownership,即代码属于项目,而不是单个工程师。所以我对有人重构我写的东西没有问题,只要它符合项目标准。如果项目没有编码标准,那么团队应该定义一些。

    【讨论】:

      【解决方案3】:

      礼仪应始终在团队层面进行。因此,请与您的同事讨论此事,然后与整个团队讨论以定义规则。

      如果只是为了美化和有争议的编码风格,通用规则可能包含不更改代码。如果将来有人必须维护您的课程,那么通常他可以改变任何事情。

      定义一些基本规则、一些反模式(总是可以由你的同事重构)等等。

      这样的规则不必非常严格,因此不需要定义大括号或类似事物的位置。但在这种情况下,没有人应该对代码进行美化,其他人会维护。如果您在某件事上发生冲突,请在整个团队中讨论,为这种情况制定新规则。

      【讨论】:

        【解决方案4】:

        如果没有编码风格的指南/规则,他甚至可能不会意识到更改正在引起烦恼。

        也就是说,这种风格是相当不标准的,而且在个人层面上,我会对不会改变代码含义而只会在你脸上印上他的编码风格的“重构”感到恼火.我不确定它是否有资格作为重构。太自私了。

        【讨论】:

          【解决方案5】:

          恕我直言,这并没有使代码更清晰,只是将其他人的编码风格强加于它。您应该与您的同事讨论这种类型的“重构”是否真的有必要(以及您的同事是否真的没有更好的方式来度过他/她的时间:-)

          【讨论】:

            【解决方案6】:

            其中最重要的方面是一致性。你的团队应该决定是否使用类型推断和对象初始化器并写下一些编码指南。

            【讨论】:

            • 最佳答案在这里。如果为团队或项目制定了编码标准,那么问题就在于谁坚持该标准,谁不遵守该标准。在决定标准时让战斗发生。
            • 另外:通过与同事的互动,您正在决定标准;到目前为止,您已经确定没有标准。这是个问题。
            【解决方案7】:

            我相信最重要的是能够不同意和承诺。我们都有自己的喜好,但来回改变不重要的事情会浪费每个人的时间。

            【讨论】:

              【解决方案8】:

              严格遵守标准。如果没有标准,那是您的问题,而不是其他人可以并且确实更改您的代码。

              此外,在对代码更改感到不安之前,您需要确定意图。是恶意的,还是无辜的改变?

              【讨论】:

                【解决方案9】:

                如果我正在修改同事拥有的文件,我会尽量保持更改与他们的风格一致。这样,即使我们的文件中有一半的字段前缀为“m_”,而一半的文件前缀为“_”(以及其他一些小事),但至少一个文件/类是自洽的。

                【讨论】:

                  【解决方案10】:

                  他是否为相关项目编写了大部分代码?如果是这样,我可以理解他的所作所为。当进入一个已经在进行中的项目时,我会尝试匹配整个代码中已经使用的格式。

                  当然,这可能不适用于您的情况。如果任何项目从你们所有人那里得到了大致相同的贡献,也许可以听从 Mnementh 的建议,把问题解决掉。

                  【讨论】:

                    【解决方案11】:

                    我会简单地与您的开发人员同事讨论您想要重构的内容以及原因。仅当您同意某事时才重构代码。

                    这将引发讨论,你们很可能会互相学习。

                    【讨论】:

                      【解决方案12】:

                      我认为在这个特定示例(即 C#)中,您应该简单地遵循 Microsoft 提供的指南。与 .NET Framework 的代码标准保持一致,便于阅读类和代码结构。

                      另一件事是 Visual Studio 会在您键入时自动更正各种格式规则,这会有所帮助。例如,关闭括号或结束语句时。

                      我个人认为外观重构看起来很难看并且降低了可读性,而您的代码遵循 .NET 约定。

                      【讨论】:

                        猜你喜欢
                        • 1970-01-01
                        • 2012-11-02
                        • 1970-01-01
                        • 1970-01-01
                        • 1970-01-01
                        • 2010-11-03
                        • 2012-04-29
                        • 2017-08-23
                        • 1970-01-01
                        相关资源
                        最近更新 更多