我遇到过一篇讨论“代码钦佩”问题的文章。基本上，作者讨论了开发人员应该如何对他们编写的代码持更多怀疑态度。我们如何“钦佩”我们的代码，将自己与自己联系起来，使我们更容易受到可能在我们面前的错误和其他不幸事件的影响。
您对此问题有何看法？你有更多关于如何避免/更多地意识到这个问题的技巧吗？
答案 0 :(得分：34)
几年前，我在另一个小型“爱好”项目上与另一个人合作，我意识到我们必须重新评估一些事情。我们写了很多代码，但并不是所有代码都很好。
我们并不是真的想“抛弃”我们投入的所有工作。但我意识到了一些事情：最重要的是从现在起我们需要投入的工作量
我们无法改变我们已经将大量工作投入到项目中的事实，因此最小化项目所需的总工作量的唯一方法是尽量减少我们尚未完成的工作量。
从那天起，我就不再使用我的代码了。如果我有信心将它丢弃并从头开始意味着减少工作量而不是保持它并使其适应我的需要，那么我就把它扔掉。
答案 1 :(得分：14)
我的高中美术老师过去常常鼓励我们采取我们认为最好的图纸并撕掉它们;他称之为“净化灵魂”。他的理由是，作为艺术家，我们被驱使创造艺术作品，任何时候我们制作出我们喜欢的东西并且让我们满意，我们继续创作的动力将会减少。
所以我遵循了他的建议并撕毁了我最好的东西，并且它起作用了。我没有把时间花在欣赏我的旧作品上，而是创造了新的东西并且不断变得更好。我试图用我的代码遵循相同的原则，但它并没有真正起作用：我的电脑有一个坚硬的塑料外壳几乎不可能撕裂。
答案 2 :(得分：8)
我发布了Jeff Atwood博客Sucking Less Every Year的片段，我同意100％。
我经常认为吸吮较少 每年都是程序员的谦虚 提高。你应该不高兴 你一年前写的代码。如果你 不是，这意味着A）你 在一年内没有学到任何东西，B） 你的代码无法改进，或者C）你 永远不会重访旧代码。所有这些 是软件的死亡之吻 开发者。
答案 3 :(得分：6)
我们确实很欣赏我们的优秀代码，但要知道该欣赏什么并不总是那么容易。复杂而复杂的代码有时被误认为是令人钦佩的代码，而优雅和简洁应该是应该努力的目标。
有两个引号浮现在脑海中：
“调试是写入的两倍 代码首先。 因此，如果您将代码编写为 尽可能巧妙地，你是 定义，不够智能调试 它“。
- Brian Kernighan
和
“让一切变得如此简单 可能，但并不简单。“
- 阿尔伯特爱因斯坦
答案 4 :(得分：3)
Jonathan Edwards在O'Reilly的书 Beautiful Code 上的作品中写了一篇关于这个主题的impressively beautiful essay。这是最后一段，但文章的其余部分也值得一读。
我学到的另一个教训是不信任美丽。似乎对设计的迷恋不可避免地导致心碎，因为被忽视的丑陋现实侵入。爱是盲目的，但计算机不是。一个长期的关系 - 维持一个多年的系统 - 教会人们欣赏更多的家庭美德，如直率和传统。美是一种理想主义的幻想：真正重要的是程序员和代码之间永无止境的对话的质量，因为每个人都从另一个人那里学习并适应。美丽不是幸福婚姻的充分基础。
其他领域也存在同样智慧的其他版本。塞缪尔约翰逊，关于写作：
阅读你的作品，无论你在哪里遇到一段你认为特别好的段落，都要把它搞定。
William Faulkner的版本更为简洁：“杀死你的宠儿。”
我的岳父是一名电影编辑，他刻意避免拍摄电影的场景。当他确实要去拜访时，他尽可能地保护自己的眼睛。这是因为当他决定是否在最终影片中包含一个场景时，他不想受到拍摄场景需要多少努力的影响。重要的是场景在最终影片中的表现如何。
我的文章“我作为程序员的进化”（如果我不是新用户，我将链接到），主要是为了学习对我编写的代码的怀疑：它是否有效，是否有用，是否可以理解（结对编程在这里是一个真正的警钟）。这很难！
答案 5 :(得分：2)
我从不钦佩我的代码。我钦佩其他人的代码，我“借”并试图模仿它们或更好地发现它们，我发现我知道的越多，特别是关于编码越多我发现我不知道。对于同行程序员来说，唯一有价值的就是欣赏我的代码并借用它。
答案 6 :(得分：2)
我认为他有一个好点。与那些有太多这方面的人一起工作是令人沮丧的，因为它确实阻碍了团队合作并为问题找到了最佳解决方案。
因为我可能有点妄想，所以我会尝试将实践纳入现实。对于代码，
单元测试：这些让我更专注于代码应该做什么，而不是任何抽象的“美”。
共享代码所有权：这里有两个阵营：让人们拥有更多的代码所有权并希望自豪感能够接管，或者减少他们的代价并让同伴压力发挥作用。我相信给予人们更多的所有权会导致这种代码钦佩。我们实行共享代码所有权，因此我不断被迫看到有人重写我的完美代码以使其更好（在他们的脑海中）。我很快意识到欣赏它太浪费时间和情感上的困难。
结对编程：与某人并肩工作会让您保持现实。
其他反馈：这些都是反馈循环，但还有其他反馈循环。没有比通过观察某人（尝试）使用它更好的方式来看看是否有效。把你的工作放在尽可能多的人面前。有代码审查。阅读other people's code。运行static code analysis工具。
答案 7 :(得分：1)
我在使用PurplePilot - 我不羡慕我自己的代码，因此我不断寻找新的，更有效（地狱，更容易）的方法来做同样的事情。我喜欢有效的c＃书，从那里我从中汲取了大量有用的代码。
我会毫不犹豫地抛弃代码并重新开始，但不一定是从头开始，即通过为特定场景编写一些代码然后扔掉它，你可能会更好地掌握场景。换句话说，这是一个“邪恶的问题”，或者你已经找到了另一种对爱迪生不起作用的方式。
这引出了一个更广泛的问题：如果代码没有被丢弃，或者至少被重新访问，那么正在开发的图书馆正在变得停滞不前是一件好事吗？
答案 8 :(得分：1)
欣赏代码没有任何问题......这是积极强化过程的一部分，将激励您在将来编写更多更好的代码。
然而，错误放置或误用钦佩可能是个问题。如果代码确实不好，或者没有单元或其他测试未暴露的错误，或者需要重构/重新设计/替换，那么这个错位的admiratoin就是一个问题。使用钦佩作为跳过部分过程的借口 - 例如代码审查，或者对代码没有持怀疑态度 - 是滥用钦佩。
与其他任何好的东西一样，对代码的钦佩可能会被错放或误用 - 这并不意味着它本身就是坏事。这就像是说“宗教是一件坏事，因为它会导致人与人之间的冲突和战争”。
答案 9 :(得分：0)
两个字：代码审查。
收集两位或多位开发人员并邀请他们审核/批评/评论您的代码。 'twill在你的代码上放了一些（肯定是苛刻的）。
答案 10 :(得分：0)
拥有更健康的观点可能更好 - 我们不是火箭科学家，而且我们没有治愈癌症 - 这只是工作。
（是的，如果你是一名建筑师，为你帮助建造的整栋建筑感到自豪是合理的，但是他们真的有很多自尊心被个人蓝图或3楼的衣柜所包围他们自己设计？）。