当您独自工作并编写了您的同事认为丑陋且难以管理且需要重写的代码时,您会:
(a) 当你再看一遍时同意他们的看法,
(b) 不同意?
如果是(a),那么问题在于您自己在编写代码时并没有完全阐明代码。由于结对编程是唯一能让你写出体面代码的东西,我想我建议“奇数”应该用于不涉及编写大量糟糕代码的任务:bug-hunting;也许编写测试代码,因为这往往不那么可怕。同时,努力提高你编写更好代码的技能——也许对你自己几个月前的代码进行审查,并记下它有什么问题。
如果是 (b),那么你遇到的问题是表达你的想法的方式不兼容。按照您的标准,该代码可能还不错,但它是相互无法理解的,这在公司环境中意味着它是糟糕的代码。结对编程意味着你写的东西是一种妥协,三分之二的人都理解,但这并不是真正的解决方案。你需要就彼此的代码最困难的地方达成一些共识,并停止这样做。你们都迫切需要从“我的两个同事会喜欢这个代码”而不是“我喜欢这个代码”的角度来考虑“代码质量”。
无论哪种方式,你们都需要为被阅读而编写代码,而不是为了尽快完成当前的工作。就我个人而言,我通过尝试以我认为其他人可能表达和理解的方式表达事物来做到这一点,而不仅仅是当时对我有意义的方式。最终会成为习惯。当我写代码时,我是为公众写的,就像我为公众写这篇文章一样。好的,所以在我的个人项目中,是一群和我一样思考的人,而在工作中,是一群像我的同事一样思考的人。但原则是编写代码,就好像有人在阅读它一样。你是在向他们解释自己,而不是编译器。
并不是说我的代码是世界上最好的,但我确实认为我受益于我的第一份工作是在一家拥有 30 多名程序员的公司中,所以我看到了各种各样的思考方式。还有一些“不该做什么”的例子,其中一位程序员做了一些其他人无法轻易理解的事情,因此可以明确地说是坏事。只有 3 人,尚不清楚 2 对 1 的意见分歧是否意味着 1 是怪胎或合理的少数。当我做了一件事,四五个人可以看到它并立即说“哎呀,不要那样做”,然后我开始真的相信这只是一个愚蠢的想法。
我还建议,如果不允许您为代码审查预算,那就撒谎和作弊。如果你在大量重写别人的代码,你实际上是在花时间去审查它,你只是没有提供反馈,这是代码审查中有价值的部分。因此,悄悄地进行审查 - 编写一个或三个函数,然后让同事查看它并就它是否对他们有意义给你即时反馈。完成后立即与监视器上的代码进行对话会有所帮助,但请尽量不要在人们“心流”时打断他们,或陷入冗长的争论。这不是结对编程,也不是正式的代码审查,但它可能会帮助你弄清楚你自己在做什么,这太糟糕了。