在新工作中继承应用程序

Question

在新工作中继承应用程序时，您是否倾向于坚持最初的开发人员编码实践，还是开始应用自己的应用程序？

我在没有指导的小商店工作，总是想知道这里的规则是什么。有些应用程序编写得很好，但不遵循我使用的标准（变量名等等），我不想“弄脏”它们。我觉得我的自我需要多一点时间才能保持一致。

其他人的写得非常糟糕，看起来开发人员每次按键时都会改变主意......

额外的想法

当我开始自己的项目时呢？所以现在我已经为这个组合引入了一个新的编码标准：

1. 好的代码 - 但不是我的风格
2. 糟糕的做法和缺乏标准的错误代码
3. 我自己的标准

Answer 1

如果代码中有明显的标准，您应该坚持使用它们。如果没有，请开始介绍自己的。

Answer 2

如果有多个开发人员在同一模块上工作，请不要更改样式。

如果您将在不久的将来将其交给另一位开发人员（此角色是暂时的），请不要更改样式。

如果您正在对模块进行完全，独占，永久的所有权，请更改它，但请遵循以下规则：

一次改变一次。

立即修复所有缩进，并提交更改。

立即修复所有大括号位置，并提交更改。

立即修复所有其他格式，并提交更改。

立即修复所有命名，并提交更改。

不要花很多时间在上面。

如果需要一两个小时，那就减少。

明确提交说明。

因此，您可以在分析更改历史记录时快速忽略这些更改。

使用自动化工具

确保结果一致且完整，因此您不必再次使用它。

运行测试

仅仅因为你的改变不应该影响行为并不意味着他们不会。 （三重否定，哎哟！）

确保每个人都知道您在做什么

现在有人可能会想要提交更改，并且与您的更改合并会很痛苦。此外，你不希望任何人感到惊讶，并在你做之前告诉你的老板。

不要再做了

这是一次性的事情。

Answer 3

发布遵循最佳做法的样式指南，并围绕它建立共识。重构旧代码，因为你需要维护它。

Answer 4

我和你在同一条船上。从最后一个人那里继承了一些应用程序的孤独开发者。我

我一直坚持看似是他现有项目的标准，以保持一致性，并使用我自己的偏好来开发新东西。

Answer 5

我注意到大多数人都认为在他们面前的人不知道如何编写代码。然后无论谁来他们认为同样的事情。有些事情是常识，但大多数事情只是个人偏好。

对于重大问题，即使用评论vs.不使用注释，更新代码可能会使其更容易使用，并且更容易让其他人使用。即使这样，你花时间更新代码也是最好的时间，而不是开始一个庞大的项目来重构一切（在这个过程中引入新的问题）。

缩进，行间距，变量名，单行ifs v.s.多行ifs，现实情况是你的编码风格可能与你认为的一样糟糕。

Answer 6

组合通常优于继承

： - P

Answer 7

我认为这取决于“编码实践”的含义。如果你的意思是代码格式化和命名约定以及我个人认为“化妆品”的东西，那么坚持已经存在的东西。如果你的意思是编写最好的prcatices并首先正确编写代码，那么请尽可能回过头来解决问题，但至少要让你的新代码遵循最佳实践。

Answer 8

鉴于我继承的大多数应用程序都被“牛仔编码员”一起攻击，他们甚至没有应用最基本的编码实践，我的观点有点偏颇。

我说引入编码标准，如果没有或存在明显错误和/或愚蠢（例如“所有变量长度不得超过4个字符”，“每个数据库列都是varchar（255）null “等等）。显然，如果你有一个团队，那么你需要就实施哪些实践达成协议，但如果你是一个独立的开发者，那么你有自由的统治和IMO，你应该把秩序引入混乱。

Answer 9

• 如果代码有效，并且似乎有一个干净的格式。不要浪费时间改变风格。
• 如果代码写得不好。如果您有一些停机时间，或者下次您在项目上工作，请务必更改它。
• 对于新项目，按照自己的方式进行，因为没有标准。和其他编写得很好的程序一样，你的程序应该很容易维护。

Answer 10

如果有的话，我会遵循公司标准。

如果没有，并且变化很小，我会采用已使用的编码方式。

如果要进行更大的更改并且我不喜欢编码器的风格，我将使用自己的风格。 如果现有代码不好，我也会改变它。

Answer 11

简短的回答是，“这取决于。”在确定是否保持旧式时，我认为有几个因素是重要的：

1）变化范围。如果它接近完全重写应用程序，那么如果你有一个你觉得适合你的新标准，那么投入新标准可能更有意义。

2）未来变化的可能性。这会一次又一次地改变吗？如果是这样的话，那么早点花一些时间最终可能是值得的。这确实需要一些判断并预测未来，但在某些情况下可能很容易看到一些相当复杂的系统会一次又一次地发生变化。

3）有多少代码是第三方代码库的自定义，例如与完全自行开发的应用程序相比，公司针对其业务流程的Oracle产品的特定自定义。这里的影响是，当新版本被重新启动并且要求升级时，由于定制了很多，因此可能会有多少痛苦。

开始自己的项目时，请提供您所知道的最佳标准。

Answer 12

我认为这在很大程度上取决于具体案例。

• 如果你是一个项目的顾问很短的时间，你应该坚持自己的方式。
• 如果你已经很久了。尝试将错误的代码重构为您自己的方案。
• 如果您在短时间内工作但正在使用隔离模块，请使用您自己的方案。

Answer 13

如果DID符合我的样式标准，我会对代码应用相同的重构标准。也就是说，我会忽略这种风格，继续关注我的业务。

如果遵循代码中的样式并不是非常困难 - 关于命名约定，我会继续使用它们来创建新代码。

但是，我不打算尝试遵循“不应该使用标签”之类的内容，“每行应缩进2个空格”等等。有很多编辑器在那里你可以“漂亮”代码这些天你需要的时候。

G-曼

Answer 14

听起来我们谈的是没有官方风格指南/最佳实践的情况。在那种情况下，正如肖恩所说，我会带头建立一些。但是......如果可能的话，选择现有的，广泛使用的标准。它更有可能被接受，所有论据都已完成，并且开箱即用的工具支持（编辑器，代码审查工具等）的可能性大大增加。

让其他人采用它通常会自下而上最好 - 将新代码写入新标准，向其他人提及您已经这样做，请求反馈。比试图提前获得批准和买入要容易得多。

在现有的丑陋项目中，避免对现有模块进行批量更改。首先，如果文件突然重新缩进，差异和版本控制将会非常混乱。

如果你正在处理的块是那么坏以至于不可读，我会先做 来重新格式化它;通过实际代码更改来跟进。

Answer 15

您是否有更好的机会使用标准样式更新现有代码？可能不是。当您不熟悉代码时，您将最有可能花费一些额外的时间来进行非新功能和非bug修复。缺乏标准可能令人沮丧，但与第一次继承代码相比，您不太可能有更好的标准化机会。

Answer 16

如果我继承了显然从未被重构的代码，我会把它作为一个强加我自己的结构的机会。

如果人们希望我为代码添加功能而花费时间和成本估算，我需要非常熟悉它，并确保它符合我的标准。

如果代码已经写得很好，那将是一件我不会惹事的祝福。但根据我的经验，这种情况并非经常发生。

Answer 17

如果只是你，那就去吧。如果它是一个团队，特别是如果任何原始开发人员仍在（或可能被称为咨询），请尽可能地保持现有的风格和实践。不要跟着他们一个老鼠洞 - 如果你认为他们做了一些愚蠢的事情，改变它，但如果它只是一个风格的东西，尽可能多地保持他们的风格。

在我上过的几个工作中，除了“如果你要对现有文件/类进行更改，使用现有的样式，甚至是新代码。”之外，我们没有编码样式的规则。