我最近开始以开发人员的身份工作,并在一位更高级的开发人员的指导下工作,他有点监督/指导我.
他建议的很多事情似乎都不对.例如,他告诉我只是以程序的方式编写我的代码,忽略它的编写或整体设计的好坏,并让它工作.然后迭代地,它将在需要时变得更好,随着时间的推移改进代码.
这让我感到不舒服的是花时间实际上正确地考虑解决方案以及编码前的实际问题,我觉得通过这种方式进行编码并最终将花费更多时间.不幸的是,我不能通过第一次写出完美的代码来立即解决问题.
此外,他对记录代码感到皱眉,相信它应该说明一切.他认为每种方法顶部的简短评论应该足够了.对我来说,这似乎反直觉.
总而言之,我觉得我现在正在编写真正的hacky代码,以便得到一些启动和运行.他是否正确,这是整个行业的事情吗？
我会在这里走出困境,并建议你可能误解了高级开发人员告诉你的内容."只是让它工作","代码应该为自己说话"是相互排斥的.如果我们假设这个人确实知道他在做什么,那么让我提供一些替代解释:
对于新开发人员而言,很容易迷失在通过正确的方式来设计软件的杂草中.这是一种分析瘫痪.他可能希望你快速深入研究代码,这样你就可以实际写出一些东西,然后你很快就会发现什么效果不好.这听起来像是他让你早早失败并经常为了学习而失败.
很多新开发人员都会毫无用处地评论他们的代码.他要求你编写自我记录的代码,而不是hacky和令人困惑的代码.如果您只允许在函数顶部进行简短注释,则必须使用明确的变量名称和简单直接的算法来使代码有意义.这是一件好事.
与导师坐下来澄清他告诉你的内容并没有错.你确实有有效的顾虑.不要犹豫,向他询问更多信息.它表现出自信和自我思考的能力.优秀的员工不是精神错乱的机器人.
此外，他不赞成记录代码，认为代码应该不言自明。
这几乎就是我需要阅读的全部内容。这个人真的不知道如何编写可维护的代码。
话虽如此，这个人显然是你的导师/主管，所以你不能只是说，“嘿，这很愚蠢”，你必须巧妙地做到这一点。
但不记录代码，因为它“应该不言自明”，这会导致灾难。而且你绝对应该注意编写清晰、有效和高效的代码。做正确的事情总是比把一些 6 个月后你还无法理解的东西拼凑在一起要好。如果你不明白，很可能其他人也不会明白。
我认为你应该和他们的主管谈谈并解释情况。
话虽如此，如果时间紧迫，有时有理由走捷径，引用 Netscape 工作人员 Jamie Jawinski 的话：
“我们将在 3 月 31 日尽可能运送最高质量的产品”
所以你必须找到平衡点。但总的来说，在代码中编写有用的注释并不需要花费太多时间，当然也不足以显着影响项目时间表，我喜欢Donald Knuth所说的：
...当您编写程序时，主要将其视为文学作品。你正在尝试写一些人们会读的东西。不要将其主要视为计算机将遵循的东西。你越有效地使你的程序可读，它就会越有效：你今天会理解它，下周你会理解它，而你将要维护和修改它的继任者也会理解它。
简而言之，即使时间紧迫，编写高效、清晰且可维护的代码也是无可替代的。