从DashiOS的开源开始，不追求完美的代码太多Wrangling，直到现在的后续结果。这件事我们不多评论，但开源是人们乐于看到的。DashiOS版开源后，受到了一些开发者的称赞，没想到，其代码却引发了一些争议。在以往开发者的印象中，开源就是展示自我，追求代码。Dash可以说打破了这种观点。但正如图拉丁所说，代码写得再好并不妨碍其商业上的成功。您如何看待黑客代码的追求？我们找到了伦敦资深程序员DanielIrvine分享的一篇文章，他认为不应该追求黑客代码。简介***的特点是对一件事的追求欲望太强。他们不会对所看到的任何事情都完全满意，所以他们常常会陷入很深的矛盾之中。他们不知道这个世界上没有绝对。***，把精力投入到工作和生活的方方面面，努力提高，乐此不疲。程序员中的黑客呢？许多程序员文化都建立在黑客代码的理想之上：代码不仅应该工作，而且还必须干净优雅。我们以巧妙地构建难题的解决方案而自豪。然而，这种宗派主义可能不利于团队的成功，因为宗派主义往往会导致个人分歧。但是，并没有一个通用的编码标准，可以被所有人所认可。每个人对于***代码的审美观点都略有不同，这意味着我们每个人对于***是什么样子的代码都有自己的想法。如果我们都被共产主义所驱使——希望我们的代码看起来像我们想要的样子——那么我们最终会与我们的队友发生争执，因为我们彼此为了让代码库看起来像这样而互相攻击我们希望看到它。随着我作为一名程序员的成长，我发现有一些技巧可以让团队避免因破解代码而发生冲突。下面我们一起来看看吧。不要被教条所困代码库的唯一要求是可用。通过简单的方法验证，如果测试全覆盖并通过，就可以证明是可用的。除此之外，每项测量都是主观的。当你阅读别人的代码时，不要去想如果是你写的代码会发生什么。不要试图在脑海中重写这段代码，让它保持原样。降低你为代码设定的标准。制表符还是空格？两个或四个空间？您是为左括号设置同一行，还是另起一行？不知道是不是只有一个编程语言单一就不会有这样的争论？解决这个问题的标准方法是为团队制定编码标准，这会给团队的代码带来一致性。不幸的是，很难形成一个完整的编码标准。总会存在导致潜在分歧的灰色地带，例如命名、模式、对象建模技术等。而且，他们团队制定的规则有时会适得其反。我所在的团队有以下编码标准规则：“功能不应超过7行代码”。事后看来，这条规则也可能不存在。虽然我仍然同意这种观点，但这条规则引起了很多混乱和争论。人们需要不断地思考它。团队中的一些人从不相信这个规则。总而言之，我们的团队花了很多时间和精力来维护这个规则。想想看，那个时候结对编程或一起改进代码会好得多。所有规则都是有代价的，尽管有这些规则，您可能仍然会有意见分歧。虽然我仍然根据短代码规则（通常少于七行）编写代码，但我不屑根据这些规则编写代码。让代码库成为你自己的标准，而不是写出一些规则。不要被pullrequests困住我通常会快速合并pullrequests，即使它对代码有很大的改变。这样做有两个原因。***是等待PR改版很煎熬，会打消团队成员的积极性。第二点更微妙，基本代码保持可塑性非常重要：意义、准备和对变化的预期。然而，“***拉需求”文化阻碍了这一点。它提倡这样一种观念，即master分支中的代码是“黄金”的，不应再更改。如果我们允许不可靠的代码成为主干，那么我们鼓励更高的更改率。团队学会总是问：“我正在查看的代码是否足够干净？”这有点违反直觉：允许主程序编写不干净的代码。事实上，它可以提高程序的质量。那么，审查拉取请求的更好方法是什么？我的策略是这样的。我会首先通读整组更改，注意任何可能重要的内容。然后优先考虑他的反馈，最多只能提供三个建议。不要管其他人。我很少评论样式问题，例如错位的空格或缩进参数列表。如果代码是可延展的，有人可能会在以后清理它。同时，这些风格问题不会伤害任何人。放眼世界，凡是几十行以上的代码，都只是旁观者的感觉。如果你期望每个人都以完全相同的方式解决问题，那你就错了。如果您对代码抱有宏伟的愿景，那么您会感到失望。为您的队友提供批准设计和代码的空间，并鼓励每个人在系统设计中发挥平等的作用。当他们的代码不是您想要的那样时，不要与您的团队争论。请记住，从长远来看，在团队中保持健康的工作关系会有回报。因此，也许您必须牺牲个人对质量的看法。程序员应该每天抽出一些时间来回顾和反思自己开发技术的发展。想想你自己和你的团队的日常工作效率。这个月的工作下个月可能就做不完了。当团队的技能从新手成长为专家时尤其如此。所以，一定要少走弯路，因为最初的弯路比其他的更有帮助。
