it-swarm.cn

坦白说,您喜欢牛仔编码吗?

大多数程序员都在捍卫政治上正确的方法论,例如敏捷,瀑布式,RUP等。其中一些遵循方法论,但并非全部遵循。坦白说,如果您可以选择方法论,那么您肯定会采用主流的“正确”方法论,或者您更喜欢像牛仔编程这样的“简便”方法论?为什么?

我知道这取决于。请说明何时使用一种或另一种。请说出您在Cowboy编码方面看到的优势。

在Wikipedia上了解 (牛仔编码

68
Maniero

我认为几乎每个有经验的程序员都经历了三个阶段,有些经历了四个阶段:

  1. 牛仔编码器掘金对设计一无所知并认为不必要的手续。如果为非技术利益相关者从事小型项目,这种态度可能会在一段时间内为他们服务;它成就了事情,给老板留下了深刻的印象,使程序员对自己感觉良好,并证实了自己知道自己在做什么的想法(即使他不知道)。

  2. 建筑宇航员目睹了他们第一个绕线项目的失败,无法适应不断变化的环境。必须重写所有内容,并且为了避免将来使用另一个进行重写,它们会创建内部平台,最终一天要花费4个小时在支持上,因为没有其他人知道如何正确使用它们。

  3. 准工程师经常将自己误认为实际,受过训练的工程师,因为他们是真正的能干并且了解一些工程原理。意识到潜在的工程和业务概念:风险,投资回报率,用户体验,性能,可维护性等。这些人将设计和文档视为连续,并且通常能够将架构/设计的级别调整为项目要求。

    在这一点上,许多人都爱上了方法论,无论它们是敏捷,瀑布式,RUP等。他们开始相信这些方法论的绝对可靠性,甚至必要性,而没有意识到real软件)在工程领域,它们仅仅是工具,而不是宗教,而且不幸的是,它阻止了他们进入最后阶段,即:

  4. 管道胶带程序员又名大师高薪顾问在听到项目需求后五分钟内便知道他们将使用哪种架构和设计。所有的体系结构和设计工作仍在进行中,但是它是在直观的水平上进行的,并且进展如此之快,以至于未经培训的观察者会将其误认为是牛仔编码-许多都做

    通常,这些人都是在创造“足够好”的产品,因此他们的作品可能设计得有些欠完善,但与牛仔编码员制作的意大利面条式编码相距miles。他们被告知他们,因为对他们来说,在后台发生的一切都不存在。

你们当中有些人可能会自己想到我还没有回答这个问题。那是因为问题本身是有缺陷的。牛仔编码不是选择,而是技能水平,而且您不能选择成为牛仔编码器,而不能选择文盲。

如果您是牛仔编码员,那么您别无选择。

如果您已成为一名建筑宇航员,那么您_在生理和心理上无能为力)无需设计即可生产软件。

如果您是准工程师(或专业工程师),那么只需很少或不需要前期设计工作即可完成项目是一种有意识的选择(通常是由于最后期限的荒谬),必须权衡明显的风险并采取相应的措施仅在利益相关者同意(通常是书面形式)之后。

而且,如果您是胶带程序员,那么就没有任何理由“牛仔代码”,因为您可以同样快地构建quality产品。

没有人比其他方法“更喜欢”牛仔编码,因为它不是一种方法。它的软件开发等同于视频游戏中的混搭按钮。初学者水平还可以,但是任何超过该阶段的人都不会这么做。他们可能会执行看起来类似的操作,但不会是同一回事。

204
Aaronaught

我也更喜欢将袜子放在放下袜子的地板上,桌子上铺满打印件和旧的小吃包装纸,水槽里满是脏盘子,床还没整理好。

我不认为事先计划好的假期是适当的假期,不要以饮食为目的而食用营养适当的食物,也不应该在已知的小径上进行适当的远足。

我喜欢获得乐趣,感到惊讶,学习新事物,犯错误,并且永远不确定我是否会重做。有时候,这种态度是恰好开展项目所需要的...

...但是在大多数情况下,这是不负责任的。舞蹈结束后,吹笛者将获得报酬...忘了这个,后果自负。

46
Shog9

你是完全正确的。这种“牛仔编程”方法可能会更快地完成代码的第一版,但是由于以下原因,节省的时间将比损失的更多

  • 其他错误
  • 寻找您原本会遇到的错误所需的额外时间
  • 必须对代码进行反向工程以记住六个月内需要进行更改时所做的工作
  • 花费额外的时间培训需要使用您的代码的其他开发人员
  • 进行更改可能会导致某些问题的更改时,没有可回顾的修订日志
  • 没有模块,您可以在以后的项目中轻松重用
  • 并不断

就像尼尔·巴特沃思(Neil Butterworth)在他的回答中提到的那样,有时您必须做自己想做的事情。但是,按照惯例,不花时间在源代码控制,模式,文档等上花费尽可能多的时间来敲打代码是一种非常不好的习惯。

对您的同事进行分析并考虑他们的习惯是有益还是有害的,而不是像他们那样盲目地做,对您有益。

31
Warren Pena

这实际上归结为以下问题:您是否可以在没有紧密结构的情况下正确执行事情,以及在计划中浪费大量时间。

我将在此发表一些可能并不受欢迎的内容:客户通常希望以牛仔的方式处理事情

也就是说,他们想要请求完成某件事,并让某人跳上它,执行它,然后将其交付。没有项目管理,会议,电话会议或表单。去做就对了。我从未有客户说过“嘿,这样做的速度太快了,不符合我们的口味,如果您下次再在其中放一些瀑布或其他东西,我们将不胜感激”。

团队方法和结构旨在平衡项目的竞争环境,并以相同的方式以相同的方式在同一页面上吸引不同水平的开发人员,以实现相同的目标。

与我合作过的成功“牛仔”能够:

  • 确定最简单的方法来快速实施
  • 知道什么时候会破裂
  • 编写干净,易读和简单的代码
  • 预测用户将如何使用,滥用和破坏它
  • 在正确的地方缩放/抽象它,而不要在上面使用建筑宇航员
  • 知道在哪里以及如何处理Edge案例和异常

这样的人只需很少的管理和结构开销就能产生真正的好结果,但是这种情况很少见。

29
Brandon

编辑:为了将来参考,我的答案是 另一个 问题,该问题已合并到此问题中。这里很不合适,但这不是我的电话。


她只是懒惰,自大,无知和极端自私。此行为是鲁re的。

我的意思是,这并不是说她使用了一种非常规的或过时的方法。她只是有意识地使用none。没有标准。没有质量保证。没事她期望软件质量来自何处?树木?
可笑的是,她很明显地拒绝了您所说的人的经历,但实际上她对此很缺乏。提供可验证且相关的论点以质疑其主张是有效的。但是,仅仅通过否认他们的经历来抹黑他们并不是什么。

但是,要点是:版本控制需要多少时间?
如果不能说服她时不时地投入这5秒钟,则应将其交给老板。版本控制不是可选的。句号.

并且,一旦让她使用版本控制,就可以轻松跟踪她引入的错误。然后让修复它们。是她的烂摊子,为什么要清理它?如果她认为自己的方法更好,那么就让她-一路
假设她实际上可以做到(在合理的时间内),那么您仍然有一个问题:与她的团队合作几乎是不可能的。这是您必须说服她(听起来不太可能),离开她(为了您的公司)或离开(为了您的理智)而解决的问题。
但是她失败的可能性更大,并且绝对可以证明你的观点。然后,她将开始像许多经验丰富的人一样坚持最佳实践。

13
back2dos

这完全取决于我是独自工作还是团队合作。

如果我在团队中工作,则需要some惯例和协议-团队中的每个人都必须遵循some达成共同目标的共同商定标准,以使他们的努力相互兼容。

但是,如果我一个人工作,那么我当然想成为牛仔。世界上所有伟大的发明都是由一个或最多两个工作的牛仔风格发明的。仅举几个:

  • 古典力学?牛仔艾萨克·牛顿(Isaac Newton),后来从莱布尼兹,拉格朗日,汉密尔顿出发。
  • 飞机?牛仔莱特。
  • 相对论?牛仔阿尔伯特·爱因斯坦。
  • 计算机基础科学?牛仔艾伦·图灵。
  • 晶体管?牛仔Walter Brattain和John Bardeen。

团队擅长进行渐进式改进,并相当快地基于经过验证的配方组合新系统(前提是他们被很好地领导),但是很少听到团队进行实际发明的消息。团队合作及其所需的方法各有千秋,但牛仔编码也是如此。

11
Joonas Pulakka

取决于问题。一个优秀的高级开发人员将编写非常紧凑,简单且健壮的代码,这些代码非常稳定,并使用所有最佳实践,而无需花费大量文档页面以及大量不同的模式和范例。但是他也将知道何时有能力做这些事情。

如果他遇到一个新问题并开始设计一个需要从头开始工作数月的应用程序,我会感到震惊。但是,如果它是一个插件,简单的工具,您可以在2个小时内编写完毕,那么该函数会进行一些转换并且不打算重用,因此设计和模式实际上只不过是在浪费时间。

而且,我猜设计的大部分已经在高级开发人员内部的某个后台线程中进行了处理。

当高级开发人员开始为复杂系统的类或从头开始编写新应用程序而没有计划步骤时,就必须开始担心。

7
Coder

这取决于情况。例如,在一些灾难性的交易丑闻之后,一些电子证券交易所坚持要求在所有交易中添加自动交易标志。这必须在一周内用于所有交易软件。我的意思是必须这样做-如果国旗不在那里,您就无法交易。在这种情况下,所有好的做法都由董事会决定-您只需要(如我们过去所说的)​​“ hacky,hacky,hacky”。在这种情况下,快速而准确地编写代码是关键。特别是因为没有可用的测试系统。

6
Neil Butterworth

根据我的经验,使用源代码控制的男婴编码是开发大型软件系统的最佳,最无错误的方式。

5
jojo

这种人被称为黑客,通常这并不是我们中间更专业的称呼。

如您所知,调试中浪费了设计,组织和控制方面的时间。而且经常会发现实际发布的是哪个版本的代码。如果您能找到它!

我发现这种人太过自我包装,认为他们太好了,无法应对他人所遭受的“局限性”,因此不必理会他们,与其他人相比,这会浪费更多时间团队必须对他们进行清理。他们也没有太过参与错误修复过程(这是维护开发人员的任务,远低于'l33t编码人员的技能和才能)。

因此,这可能是其他地方的常用方法,但是在我自己的位置(我是高级编码人员,很喜欢这种方法,哎呀),我们不会遭受它的困扰。不是我们需要大量的过程和程序,而是我们确实坚持最少的组织,源代码控制(说实话,这是流血的东东,该死的有用!)

Kent Beck 等人,都是专业人员,他们都认为旧的处理过程方式本身很糟糕,因此他们创建了新的方法来组织编码,同时仍然使编码更加面向工艺,然后告诉其他所有人关于它的信息-通过出版书籍(在互联网出现之前,您还做了什么?)

您听起来好像做对了-不要因为别人无法破解而接受不良做法。您的团队负责人或经理应该坚决反对这个“摇滚明星”,但是,如果他们做的不好,那仍然不能阻止您做正确的事。只是不要接受她的卑鄙行为,如果她搞砸了(她会的!),那就让她清理一下。您坚持良好的做法(并且知道它们是什么),而又不让它们接管对您的编码效率造成损害的情况,那么您将对未来有好处。

这是一位真正有见识的作家的 一篇文章 。它并不能解决您的问题,但是可以为您提供一些了解,让您了解它的真实情况,并为您提供一些专业的处理技巧。

4
gbjbaanb

我认为其中一位评论员是对的-关于结果的一切。

如果一个人可以生产出优质的产品-某种产品能够完成其应做的事情,并且是可维护可靠,那么,如果遵循正式的方法论或过程,那有什么关系?流程非常重要,可以确保达到最低要求,但是如果有人已经在该最低要求之上工作,那么这些流程就不会增加任何费用。如今,imo太多的开发人员似乎认为编程的是坚持流程,而不是生产好的产品。

4
GrandmasterB

您可能会在我对 坦率地说,您更喜欢牛仔编码吗? 您正在查看哪个版本。

当有人看到问题并立即开始准确而又准确地编写代码时,may就是一位总工程师的标志,他曾经一千次见过这个问题,并且已经知道最好的方法。解决这个问题。

或者,这可能是业余爱好者的标志。

我将告诉您一件事:绝对不使用版本控制或编写测试是因为它们太“学术”了not“高级”或什至是远程专业的方法。您将永远不会在大型软件商店(例如Microsoft或Google)上看到这种事情,而且在大多数初创公司或相当成熟的企业团队中也可能不会看到。

风险太大。如果您的PC在一夜之间死亡怎么办?再见了3年的生产力。好的,因此您要进行备份;那么,当您进行重大更改,意识到完全错误并必须还原该更改时,会发生什么?即使requirements是错误的,即使对于最有经验和才华的开发人员,也会发生这种情况。如果您没有运行任何类型的版本控制,那么您只会在泥泞中旋转。我去过一次,并且会从不回去。

根本没有任何借口-建立存储库需要10分钟,提交则需要10秒。它可能占您总开发时间的1%。如果您很忙,可以每天将测试减少到20-30分钟,并且仍然相当有用。

我不喜欢敏捷方法(请注意大写的A),但是有时候您确实确实需要袖手旁观并开始编写该死的代码。我见过“分析瘫痪”的人员和团队,而生产力确实受到了明显的打击。但是,解雇我们行业中的基本工具,例如修订控制和测试对我来说确实是硬道理;这个人确实属于高级职位。

3
Aaronaught

唯一重要的事实是团队的长期产品成果。

有一种说法认为,一个包含一个(或多个)出色程序员的团队将比拥有更多平均程序员以平均比率编码的团队产生更好的结果。

如果牛仔生产出常规程序员没有的东西(在给定的期限或规格下),并且牛仔团队甚至不得不花费几个星期/几个月的时间来清理牛仔的烂摊子,他们可能仍然会更好的结果。

如果拥有牛仔的团队即使在经过数月/一年的工作后仍无法清理(记录,调试,集成,维护)混乱,那么牛仔创造的任何进步都不会给团队带来长期的优势。

决定哪一个,并优化团队花名册。

只要最终结果是好的,并不是每个程序员都能(或应该)以相同的方式工作。

3
hotpaw2

当我想到“传统的”方法论时,我认为“管理人员不知道如何理解开发人员,因此,他们没有进入开发人员的世界并了解足够的知识以了解正在发生的事情,而是使开发人员进入了他们的世界”。

从根本上说,当我想到“敏捷”时,我认为“您需要做的事情是为了最大程度地减少多个人一起工作所带来的低效率”。因此,我坚决主张:“没有[〜#〜] [[##〜]敏捷方法论,只是一套价值观和原则”。

换句话说,在大型项目中需要执行某些操作,在小型项目中需要执行某些操作,而在这两个项目中都需要执行某些操作。

例如,对于我自己开发的项目,我只需要最简单的积压订单……这只是一个待办事项清单。如果我们两个人在一起,我可能会共享该列表,但格式非常简单(可能只是存储在代码存储库中的注释)。一旦有了3或4,我正在寻找某种工作项目系统。

2
MIA

是的,但是您必须识别什么时候不这样做。

在任何较小的物体上,您可能都很好,但是如果您遇到复杂,危险,受约束的事物等,则需要能够识别出适当的设计何时值得花额外的时间。

我也认为您绝对应该考虑Aaronaught的回答。牛仔对不同的人意味着不同的事物。

2
Bill

我觉得您对她的风格的厌恶会导致您稍微歪曲它。您说牛仔方法在调试中是有偿的-这是否已经在发生,还是您对它如何发挥作用的假设?

公开披露-我本人是一名高级开发人员,而且我经常放弃正式的设计流程和经验。对于在问题领域非常有经验的人没有正式的程序是很常见的。如果您已经数十次解决问题,则无需正式流程即可再次制定类似的解决方案。

正式程序处理代码的设计-我不明白为什么由于缺少正式程序而需要引入更多错误。我在您的帐户中读到的唯一大问题是,没有使用版本控制-这不仅是自私的,而且代表开发人员是鲁re的。她实际上是根本不承诺,还是只是不按照自己的喜好来承诺?

在我的书中,没有正式的设计方法不是“牛仔编码”(尽管没有使用修订控制)。经验应恰好用于此目的-减少提出“足够好”的解决方案所需的时间。请记住,您必须解决当前存在的问题并使代码易于更改,而不是针对将来可能永远不会发生的情况进行设计。有了经验,您会对如何快速做到这一点有很好的感觉。

1
Eran Galperin

似乎有两个阵营-赞成结果的阵营和主张原则的阵营。我属于后者。

我是一个平庸但可以说是尽职尽责的程序员-编码时的主要问题超越完成工作,是我正在帮助任何使用我的代码完成其工作的人。我不能这么说,我一直都实现了这一目标-但这就是我的目标。

当然,您may您的团队遇到了麻烦-但是,当他们休假几个星期并且要求您调试他们的工作或向其中添加内容时,会发生什么?最终,牛仔程序员不是团队合作者。他们可能会编写出色的代码,但是如果团队依赖他们,那么这很危险。

1
sunwukung

仅当原型制作非常简单的功能时。

然后,一旦完成并考虑正确的方法,我就放弃代码并认真对待。

1
Klaim

我曾经在一个真实的项目中做过一次(当时我们将其称为“ Samurai编程”,这是在“ Saturday Night Live”上出现了“ Samurai Tailor”系列草图之后),令我惊讶的是,效果很好。当然,我从垃圾开始,所以几乎没有使它变得更糟的风险。

但是,我内心很“整洁”,不喜欢那种“一发而发”的发展风格。

另一方面,沉重的过程操作方式也不符合我的口味。我只是想在行动前做好计划。

总而言之,我认为适当的正式过程的数量在很大程度上取决于项目的规模(代码的大小,项目的持续时间,开发人员的数量,需求的种类等)。我希望对开发航空电子设备或生物医学设备软件的人员施加严格和严格的标准,例如例如,对于游戏而言,任何失败的负面影响要小得多,因此严格而有条理的开发实践的成本和负担并没有真正的道理。

1
Randall Schulz

它(很大程度上)取决于项目的规模。一方面,要获得不错的结果,您需要必须设计。另一方面,如果该项目足够小,您可以在不写下,绘制图等的情况下将整个设计概念化(无论如何,大部分都是这样),那么您可能会很富裕,而无需进行额外的工作记录您所做的一切。

几乎每个人都听过足够多的恐怖故事,以至于意识到如果不明确了解自己在做什么以及往何处去,就跳进去是灾难的根源。很少有人指出相反的情况同样是灾难性的。仅举例来说,我们大多数人在编程过程中通常都会编写小型工具。编写完整的规范,测试和文档通常是不值得的。有一个门槛,低于这个门槛就不值得进行产品生产-人们经常不喜欢重新发明轮子,但是在某些情况下,重新发明比避免轮子更容易。

在这种情况下,通常值得is制作一个库来简化这样的任务。这样一来,前端代码通常变得微不足道,以至于编写(或修改)代码来执行所需的操作比弄清如何使完整的程序执行所需的操作要容易得多。考虑一下,例如,gnu缩进了50多个不同的标志,其中许多标志以各种微妙的方式交互,因此唯一合理的选择是1)根本不使用它,或2)决定喜欢它给您的东西而不是试图获得您最初想要的东西。

1
Jerry Coffin

我不认为牛仔编码是一种高级方法。

正如其他人所说,丢弃版本控制确实存在危险。跳过文档和分析可能还意味着冒着交付用户不需要的内容的风险。只是我的意见,但是如果您所做的只是牛仔代码,我不认为您会从“编码人员转到开发人员”。

但是,是的,有一些例外,例如尼尔·巴特沃思(Neil Butterworth)提到的那样。在这种情况下,我宁愿有一位经验丰富的高级开发人员来做牛仔编码。

0
Bernard Dy

我发现您的帖子有趣。我经常与您的主题分享看法,她的感觉是过分规范化的方法令人窒息。就像其他人指出的那样,如果她是个天才,并且可以同时追踪大量的心理笔记而又不会忘记或感到困惑,那么很有可能会保持一大堆混乱的代码,并使其通过完全模糊的更改来完成令人惊奇的事情。能做到这一点的人们的大脑中会充满某种精神上的快乐-就像在您的脑海里成为一个小宇宙之神。

但是,聪明的雇主已经学会了艰难的方法,即只有原始作者之外的任何人都无法对该代码进行任何有价值的工作。如果程序员继续前进,他们最终会浪费大量金钱,弄清楚唯一的选择就是重写(我以前认为那意味着全部损失,但是我意识到,如今,您并没有破坏外部功能级别的迭代开发)。

就我个人而言,我不介意在团队中有这样的人,因为在紧要关头,他们可能会做别人没有想到的事情。

另一方面,做一个自己的人,自己决定问题的答案是什么,因为唯一可以肯定的是nobody在构建软件时就已经弄清楚了。这是使其成为有趣领域的一件事...

0
Aaron Anodide

牛仔编程是创建 大泥巴 的一种相当确定的方法。听起来不愉快, 倾向于交付 ...

0
Denis de Bernardy

我认为,较新的程序员在承担他们可能没有太多经验的项目/范围时,或者由于老板的压力而试图“完成任务”时,往往会做一些牛仔编码的事情。我知道我肯定走了这条路,因为我缺乏使用正确模式的知识,只是“破解了它的方法”。

我和您抱怨的人之间的区别是,通常我很快就会意识到自己可以做得更好,更容易维护,这通常会促使我学习更多并提高自己的技能(阅读有关学科)。当我回去调试其中一些被黑的解决方案时,我通常会觉得很痛苦,这对我想学习如何以“正确的方式”做更多的贡献。我认为您所描述的这个人基本上停留在婴儿般的自我反思水平上,并且让他们自己的自我阻碍了实际提高他们作为软件开发人员的技能的方式,似乎我不想与之合作。

0
programmx10

没有永不。

我总是进行需求分析,考虑架构,设计细节,然后编写代码。即使我独自在家为个人项目工作。

如果他/她以牛仔风格工作,我会立即将其开除。我们是工程师,对客户和用户负有责任。

0
CesarGon