“初级开发人员应该容易理解”的论点[已结束]

我非常不同意。初级开发人员最终将成为高级开发人员。怎样遇到学校没有教过的高级话题。

控制反转 从不 将我的代码恢复到原来的方式,因为初级开发人员在摸索IoC时遇到了问题。相反,我会在下班后带他们出去喝杯啤酒,然后讨论这个问题。初级开发人员学习得越多,需要做的握手动作就越少。

这里有一个 blog post

如果您不断地简化代码或设计,这是确保初级开发人员保持沉默的一个很好的方法。挑战他们,并将其作为指导机会。当然,有些人永远也学不到,但在这一点上你会遇到更大的问题。

也不仅仅是头发尖的老板。作为一名高级开发人员,通常很难抵制吸引初级开发人员的冲动。“哦,我只会做这部分,因为这对他们来说太难了”,否则他们会花太长时间,或者他们会在杂草中消失。

最后,确保在使用语言全部功能的惯用代码和滥用语言功能的惯用代码之间取得平衡。没有理由只为了在两个单独的线程中运行其参数而重写| |运算符。至少为你更年长、更愚蠢、未来的自己把代码写得更简单一点。

嗯,我认为避免使用“聪明”的语言结构是合理的,除非它们真的,真的使代码变得更好-在这一点上,如果初级开发人员看到它,希望他们会问,而不是只是被弄糊涂。

这里有另一种表达方式:“编写代码,这样就很容易理解,如果凌晨3点接到电话,要求修复其中的错误, 我仍然能理解。”

说真的,让它尽可能容易理解。那个 每隔一行就意味着一条注释——它意味着一段代码的目的不明显的注释,只有在这样的情况下,首选的“好”选项才会出现 制作 很明显,这“不起作用”。

拼图代码和复杂代码之间有区别。

我发现一个最大的问题是“通过阅读容易理解”和“考虑因素充分”之间存在很大的差异,而且这两个目标往往直接相互矛盾。在经过良好分解的代码中,类之间有更多的跳跃和大量的虚拟调度,因此通过代码的路径是非常非线性的。

是的,在我看来,可读性和易于理解代码是可维护性的重要组成部分。

没有。在过去,我从经验丰富的开发人员那里学到了很多。我宁愿有机会从他们那里学到新的东西,也不愿让他们为我隐瞒一些愚蠢的事情。

这是一种平衡行为。。。
如果你的团队中有三个人可以“阅读”你的代码并知道它在做什么。。。不需要改变。然而,如果你是唯一能理解你的代码的人(不管你认为它有多聪明)。。也许你应该把它降低几级。

在这篇文章中,经理的观点被严重遗漏了:)(我不是其中之一)。他/她主要担心的是,他不想看到其他人都不敢涉足的黑暗代码区。。因此,如果你能说服你的老板团队中的其他一些人可以任意修复(或者更好的是……展示一个由其他人修复的实际bug),经理应该让你摆脱困境。与上司意见不合是另一种艺术:)。。但你通常可以把事情说出来。
你不必一直倒退到最低公分母。。取得平衡。

您的目标不应该是让您的代码对于初级开发人员来说易于理解。相反,对于维护程序员来说,它应该很容易理解。

这意味着:

• 需要时,局部“复杂性”是可以的。如果他们看到了复杂的代码,他们就会知道他们需要深入挖掘。
• 隐藏的复杂性是不好的。如果你看不到修改一段代码会有微妙的副作用,那么维护代码将是一场噩梦。
• 如果不走极端,可见的新技术也可以。

我不同意经理的观点:需要简单的是代码,而不是用来编写代码的技术。

• 内部文档清楚地说明了理解此代码需要哪些技术,并提供了可以学习这些技术的地方的参考。

Numerical Recipes ,我能猜出细节。

对这是一个非常合理的理由,可以把它降低一个档次。现实情况是,大量的开发人员(和大多数人一样)处于初级阶段。

至于你应该做什么。。。说“是的,先生”或“是的,女士”,然后去做。这种关系中只有一个老板。

有些人似乎认为,让jr开发人员一边学习高级主题,一边费力地阅读模糊的代码,我想在这里再介绍一件事。

当任何开发人员(jr或其他人)遇到他们不理解的代码时,他们的第一种方法是将其重构成可以理解的东西。这是所谓的哇,代码是垃圾,我必须重写它!综合征我敢打赌这个董事会上的每个人都经历过。所以,作为一个企业主,我是想在每次有新人来访时为开发的代码付费,还是想为添加的新功能付费?

猜猜我会和谁待得更久。

如果你对你的代码哑口无言,你将被困在与那些永远不会熟悉高级编码技术的低级程序员的工作中。如果有任何冗长的代码试图表达您编写的固有的复杂过程,那么前面提到的初级开发人员可能无论如何都看不到森林。如果他们必须表达一个复杂的概念,如果他们只知道基本的原始构造,那么他们可能会搞砸,而如果他们知道如何简洁优雅地表达他们的意思,那么代码就更有可能是正确的。

我发现最大的一个问题是“通过阅读容易理解”和“考虑因素充分”之间存在很大的区别而且这两个目标之间往往存在着直接的紧张关系。在经过良好分解的代码中,类之间的跳跃和虚拟调度要多得多,因此通过代码的路径是非常非线性的。”

引用的是真理,我认为这是一个最大的问题与C++代码一般。如果你是编写代码的人,很容易想出一套非常复杂的东西,这些东西都经过了很好的分解,如果你已经知道的话,很有意义,工作很好,通常像钻石晶体,等等。但是,从一个人的角度来看,他试图弄清楚你是如何做到这一点的,为什么事情是这样的,事情是如何运作的,以及如何做出符合现有系统和满足新需求的改变,这几乎是完全不透明和难以理解的。

这种情况如何 可维护性?这种情况是我C++程序员的主要任务之一。拥有一堆可以被黑客攻击的普通C代码要比拥有一个几乎没有人能想出如何在不破坏晶体结构的情况下进行合理修改的具有不可穿透的超级因子代码的钻石晶体要好得多。

我认为“哑巴”代码的一种很好的做法是使用更长的变量名和函数名。IMHO表示,命名变量和函数以使其用途易于理解是一项重要的工程任务,代码的原始作者需要付出额外的努力。Damian Conway在“Perl最佳实践”中有一些很好的例子。一些示例包括:首选“ final_total" to "sum “更喜欢” previous_appointment" to "previous_elem" ,更喜欢“ next_client" to "next_elem" . 更喜欢“销售记录”而不是“数据” . max_displacement 一个地方,然后使用 VelocityMax
sales_record[i] vs sales_record[cancelled_transaction_number]

我经常在开发周期结束时通过为所有函数和变量找到新名称来“重构”代码。在一个现代的编辑器中,修改它们是很简单的,直到最后我才真正明白我使用它们是为了什么。这样的“简化”代码并不是经典的C语言,但几个月后我回来问WTF我做了什么,这对我来说更容易?

这取决于代码。您的旗舰产品中是否有需要使用经理出于性能原因希望您删除的功能的产品?如果答案是肯定的,我会让你的经理让你保留代码,然后写一份文档详细解释代码中难以理解的部分。如果它是一个内部应用程序,需要由许多不同的人维护,并且复杂的功能可以在不影响程序的情况下删除,请删除它们并选择更重要的战斗。

你应该提醒你的老板,你可以建造火箭飞船或鸡舍,他必须为任何一个付给你同样的报酬。照他们说的去做,但一般来说,这样的环境适合那些寻找新环境的人。

旧的引语适用于以下情况:

让一切尽可能简单, 但并不简单。

我认识一些开发人员,他们编写了高度模糊的代码,他们认为这些代码很先进,但团队的其他成员认为这些代码不可读且无法维护。其中一部分涉及到过度使用高级语言功能(在C语言中,三元运算符和逗号运算符)以及使用其他人无法维护的晦涩个人习惯用法(例如,将ptr->item替换为(*ptr).item everywhere)。作者试图智取优化器(公平地说,这远远不够好)。

在这种情况下,“简化”代码是个好主意。问题不在于高级算法或高级语言功能,而在于高级语言功能的过度使用和不当使用,以及模糊的个人习惯用法。

但是,在您询问的情况下,经理的更改使代码更难阅读和维护,我同意您和其他人的回答。我只是想指出其他人没有提到的替代方案。

我建议将代码保持在一个“极客级别”,并对其进行良好的注释,这样年轻人就可以理解代码背后的意图,同时学习更好的编码方式(或正确的编码方式),这样我们就拥有了两个世界中最好的。

我认为这是经理礼貌地告诉你你的代码太模糊/复杂/混乱/拼图代码…不管你怎么称呼它。有时候,我们太过专注于编写代码,以至于我们忘记了其他人以后会过来阅读代码。

我通过艰苦的方式学会了这一点,回想起来,我发现这是更好的方式。让循环自己重复。

当我编写用于用户注册的向导控件时,出现了这个问题。

我认为这比在ASP.NET中使用数据绑定语法要好得多,而且更干净,因为ASP.NET没有编译时检查,并且会弄乱html的布局。

数据绑定解决方案是“标准的”,而JQuery解决方案是“不寻常的”,这意味着初级用户不太可能理解它。

最近我越来越多地尝试为UI提供所需的数据,而不是通过数据绑定将其破解到UI中,这就是为什么我在当前步骤索引中添加了隐藏字段。

这就是说,做一些仅仅因为是一个新的或复杂的问题而难以理解的事情与做一些因为你试图炫耀或你认为让人困惑会以某种方式为你赢得工作保障而难以理解的事情之间有着显著的区别(我从未见过有人这样做,但我听说过有人这样做)。

你应该让事情变得容易理解吗?是的,绝对是的,尽可能的人性化。然而,一个有效且工作出色的项目是更高的优先级。

经理的抱怨永远不应该是“不要这样做,因为我们的下级不懂”——应该是“只要可行,就做x而不是y,因为x更容易阅读/理解”。这还假设x和y是等效的(接受相同的输入并产生相同的结果)。

如果你想知道这些管理者有多可笑,试试这个:我有一个管理者因为我把一个变量声明为“布尔”类型而大骂我,因为他觉得其他程序员无法处理它。事实上,当我问为什么时,他的回答是“因为我们在这里不这样做”,这是一个非答案,但我将其解释为“沉默”。他们还因为这一点和类似的做法斥责我,似乎很明显,好的编程习惯实际上是“坏的”,我应该已经知道为什么了,尽管他们从未表达过一种首选的编程风格(无论是正式的还是非正式的)。不用说,这是一份糟糕的工作。

确保你能理解6个月后它会做什么。

如有疑问,请对代码进行注释。这就是评论的目的。