10

我遇到了一篇讨论“代码钦佩”问题的文章。基本上,作者谈到了开发人员应该如何对他们编写的代码持怀疑态度。我们如何过度“欣赏”我们的代码,将我们的自我附在它上面,使我们更容易受到可能摆在我们面前的错误和其他不幸的影响。

你怎么看待这个问题?您是否有更多关于如何避免/更加注意这个问题的提示?

4

11 回答 11

34

几年前,我和另一个人一起做一个小的“爱好”项目,我意识到我们必须重新评估事情。我们已经编写了很多代码,但并非都是好的代码。

我们并不是真的想“扔掉”我们已经投入的所有工作。但我意识到:最重要的是我们从现在开始需要投入的工作量。

我们无法改变我们已经在项目中投入了这么多工作的事实,因此最大限度减少项目所需工作总量的唯一方法就是尽量减少我们尚未完成的工作量。

从那天起,我就不再依附于我的代码了。如果我确信扔掉它并从头开始比保留它并根据我的需要调整它意味着更少的工作,那么我会把它扔掉。

于 2009-09-12T12:29:59.410 回答
14

我的高中美术老师曾经鼓励我们把我们认为是最好的画作撕掉;他称之为“净化灵魂”。他的理由是,作为艺术家,我们被驱使创作艺术作品,任何时候我们创作出我们喜欢并让我们满意的东西,我们继续创作的动力就会减弱。

所以我听从了他的建议,撕毁了我最好的东西,它奏效了。我没有花时间欣赏我的旧作品,而是创造了新的东西并不断变得更好。我试图在我的代码中遵循相同的原则,但它并没有真正起作用:我的计算机有一个坚韧的塑料外壳,几乎不可能撕破。

于 2009-09-12T13:24:32.660 回答
8

我从 Jeff Atwood 的博客中发布了一个片段,每年吸少一点,我 100% 同意。

我经常认为,每年少吸一点是谦虚的程序员的进步。你应该对一年前写的代码不满意。如果你不是,那意味着要么 A)你一年内什么都没学到,B)你的代码无法改进,或者 C)你永远不会重新访问旧代码。所有这些都是软件开发人员的死亡之吻。

于 2009-09-12T12:58:51.473 回答
6

我们当然喜欢欣赏我们漂亮的代码,但知道要欣赏什么并不总是那么容易。复杂而精致的代码有时会被误认为是令人钦佩的代码,而优雅和简洁应该是我们努力追求的目标。

想到两句:

“调试的难度是一开始编写代码的两倍。因此,如果你尽可能巧妙地编写代码,那么根据定义,你就不够聪明,无法调试它。”</p>

——布赖恩·克尼汉

“让一切尽可能简单,但不要更简单。”

- 艾尔伯特爱因斯坦

于 2009-09-12T12:43:48.373 回答
3

乔纳森·爱德华兹(Jonathan Edwards)在 O'Reilly 的《美丽代码》一书的推动下,就这个主题写了一篇非常漂亮的文章。这是最后一段,但文章的其余部分也值得一读。

我学到的另一个教训是不信任美。似乎对设计的迷恋不可避免地会导致心碎,因为被忽视的丑陋现实侵入了。爱情是盲目的,但电脑不是。长期的关系——维持多年的制度——教会人们欣赏更多的家庭美德,比如直率和传统。美是一种理想主义的幻想:真正重要的是程序员和代码之间永无止境的对话的质量,因为他们彼此学习并适应对方。美貌不是幸福婚姻的充分基础。

这种智慧的其他版本存在于其他领域。塞缪尔约翰逊,关于写作:

阅读你的作文,无论哪里遇到你认为特别好的段落,就把它删掉。

威廉·福克纳对此的解释更为简洁:“杀死你的宝贝。”</p>

我的岳父是一名电影剪辑师,他刻意避开拍摄电影的场景。当他确实必须访问时,他会尽可能地遮住眼睛。这是因为当他决定是否在最后一部电影中加入一个场景时,他不想被拍摄场景所花费的精力所影响。重要的是场景在最终电影中的表现如何。

我的文章“我作为程序员的演变”(如果我不是新用户,我会链接到该文章),主要是关于学习对我编写的代码的怀疑:它是否有效,是否有用,是否易于理解(结对编程在这里是一个真正的警钟)。这个很难(硬!

于 2009-09-19T21:01:20.947 回答
2

我从不欣赏我的代码。我很欣赏我“借用”的其他人的代码,并尝试模仿他们或改进他们,我发现我知道的越多,尤其是关于编码,我发现我不知道的越多。唯一有价值的是同行程序员欣赏我的代码并借用它。

于 2009-09-12T12:49:59.967 回答
2

我认为他有一个很好的观点。与拥有太多这样的人一起工作是令人沮丧的,因为这确实阻碍了团队合作和找到问题的最佳解决方案。

由于我可能有点妄想,我尝试将实践放在适当的位置,以使我立足于现实。对于代码,

  • 单元测试:这些让我更专注于代码应该做什么,而不是任何抽象的“美”。

  • 共享代码所有权:这里有两个阵营:给人们更多的代码所有权并希望自豪感接管,或者给他们更少,让同行压力发挥作用。我相信,给予人们更多的所有权可以导致这种代码钦佩。我们实行共享代码所有权,所以我经常被迫看到有人重写我的完美代码以使其更好(在他们看来)。我很快意识到过度欣赏它是浪费时间和情感上的困难。

  • 结对编程:与某人并肩工作将使您保持现实。

  • 其他反馈:这些都是反馈循环,但还有其他反馈。没有比观察某人(尝试)使用它更好的方法来查看某样东西是否有效。把你的工作放在尽可能多的人面前。进行代码审查。阅读别人的代码。运行静态代码分析工具。

于 2009-09-12T16:52:31.367 回答
1

我在 PurplePilot - 我不欣赏我自己的代码,因此我一直在寻找新的、更有效(地狱、更简单)的方法来做同样的事情。我喜欢 Effective c# 这本书,从那里收集了很多我欣赏的有用代码。

我会毫不犹豫地丢弃代码并重新开始,但不一定从头开始,即通过为特定场景编写一些代码然后将其丢弃,您可能会更好地掌握该场景。换句话说,这是一个“邪恶的问题”,或者你找到了另一种对爱迪生不起作用的方法。

它引出了一个更广泛的问题:如果代码没有被丢弃,或者至少被重新审视,那么在停滞不前的库上进行开发是一件好事吗?

于 2009-09-17T13:53:40.683 回答
1

欣赏你的代码并没有错……这是积极强化过程的一部分,它将激励你在未来编写更多更好的代码。

然而,放错地方误用的赞美可能是个问题。如果代码真的不好,或者有单元或其他测试没有暴露的错误,或者需要重构/重新设计/替换,那么这个错位的赞美就是一个问题。以钦佩为借口跳过部分流程——例如代码审查,或对代码不持怀疑态度——是滥用钦佩。

就像其他任何好的东西一样,对代码的赞美可能会被放错地方或被滥用——这并不意味着它本身就是坏的。这就像说“宗教是一件坏事,因为它会引起人与人之间的冲突和战争”。

于 2009-09-17T14:11:57.900 回答
0

两个词:代码审查。

召集两个或更多的开发人员,并邀请他们审查/批评/评论您的代码。'twill 为您的代码提供一些(诚然严厉的)启示。

于 2009-09-15T20:04:50.090 回答
0

有一个更健康的观点也许会更好——我们不是火箭科学家,我们也不是治愈癌症——这只是工作。

(是的,如果你是一名建筑师,为你帮助建造的整栋建筑感到自豪是合理的,但他们真的有很多自尊心包裹在个人蓝图或他们设计的 3 楼壁橱中吗?他们自己?)。

于 2009-09-17T14:46:37.167 回答