当前位置:  开发笔记 > 程序员 > 正文

如何向同事证明他们制作了糟糕的代码?

如何解决《如何向同事证明他们制作了糟糕的代码?》经验,为你挑选了3个好方法。

我发现在我目前的工作中工作有点困难.

代码库最近变得有点疯狂(但绝对不是我见过的更糟糕),而且我很难处理代码的某些部分.我可能是愚蠢的,但很可能只是因为它让我很失望,开始研究一些难以理解的事情.

我的老板已经意识到了我的想法 - 我表达了这样工作的感觉.他让我举例说明出了什么问题.当我指出两三个小问题时,他说"是的,好的",但重构花了他很多钱,我们必须把产品拿出来(不是我第一次听到这个).

我不得不承认这些例子并不是最引人注目的,但问题实际上很难解释.它由整个代码库中的许多微小"错误决定"组成.(我们也看到这个问题绝对是主观的).例如,错误的命名,处理空值,样板,不使代码可重用(或相反)等等.再次重新考虑别人的代码以证明我会以不同的方式做到这一点可能会很累.

你有关于如何处理这个问题的想法吗?我有点厌倦了每次都要快速破解一个快速的代码库!



1> sharkin..:

有时你的程序员与你做的事情有很大的不同,你可能觉得错误的事情实际上可能有积极的方面.我们都有自己的学校.我想我经常遇到那些抱怨我不理解的事情的程序员,因为我自己也觉得有些东西需要被抱怨.

确保你可以推断出你抱怨的具体劣势.如果没有其他原因,那么你可以激励中层管理人员改进.难以推断成可衡量事实的事情通常源于品味/风格的差异而不是质量(有关这个主题的阅读有些博弈).smacl发布的答案有很好的具体建议!

如果你能把你的担忧推到一个真正的劣势,那么当人们说必须"接受"这样的情况时,我真的不同意.我不止一次地接触过这个问题,让我告诉你,重构不是问题的解决方案.重构仅修复症状.

接受这种情况就像说" 质量差的产品线和昂贵且令人沮丧的维护是我公司可以忍受的 ".这在很少的情况下是这样的.然而,管理(即那些有优先顺序的项目的管理人员)通常在技术上并不知道问题是什么,或者为什么开发费用昂贵.他们不应该为此而烦恼.

这就是为什么你需要一个拥有技术主管,首席架构师,良好的组织结构和分层模型等的开发组织.如果你忽略了开发的某些方面,那些经验丰富的软件专业人士已经看到了这条道路的发展方向.这是关于改变团队的"文化".

要么你坚持你的公司并试图改变你从根本上做事的方式,要么你找到另一个工作的地方,并确保你在面试中找到他们在日常发展中的工作方式.

祝好运



2> Ethan..:

我最近遇到了一个非常类似的问题,一位朋友给了我一些帮助很大的建议.他说:"让自己远离它."

他的意思是,你必须传达问题,因为它们是真实的,代价高昂的问题,在时间和金钱方面都会产生影响.但是当你进行沟通时,只谈谈对组织的影响.不要提到给的后果,因为那听起来像是抱怨而且会被忽略.

例如:

不要让自己脱离它:

"其他开发人员使用这些模糊不清,误导性的标识符,然后不得不花费数小时来查看代码,试图发现他们的意思.这占用了很多时间."

让自己远离它:

"对类和变量名称进行一些重构以及围绕标识符建立一些编码标准将是非常有用和经济有效的.立即的回报将是一个易于理解的代码库,适用于每个人,从而提高生产力.期限支付将是以后我们将能够更快地修改代码并修复问题.如果在发布之前发现了一个关键错误,那么可理解的代码库将非常重要."

我希望有所帮助.



3> SmacL..:

1)使问题更加明显,并获得管理层的支持

在大约一个月的时间内,对各种编码任务所花费的时间进行非常详细的记录.在月底分析和总结你的老板的内容,即浪费时间和浪费金钱,以说明某种形式的变化是必要的.

2)想一个具有成本效益的前进方式

例如; 而不是重构整个代码库,从实现中分离接口,并在接口层强制执行更严格的标准,包括单元测试,命名约定等.因此,每个程序员都可以放心使用他们没有编写的代码.虽然这在一定程度上将地毯下的垃圾清扫干净,但这是一种准备大规模重构的好方法.

从管理角度来看,重要的是工作流程不会中断,并且可以看到积极的结果,因此需要进行相应的规划.

3)与您的同事达成更长期的条款改进

坐下来与其他程序员就未来代码达成合理的编码标准.

推荐阅读
LEEstarmmmmm
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有