坦白说，您喜欢牛仔编码吗？[关闭]

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

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

在Wikipedia上了解有关Cowboy编码的信息

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

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

2. 建筑宇航员目睹了他们的第一个球状项目无法适应不断变化的环境。所有内容都必须重写，并且为了防止将来再次需要重写，它们创建了内部平台，并最终每天花费4个小时在支持上，因为没有其他人知道如何正确使用它们。

3. 准工程师经常将自己误认为是经过培训的实际工程师，因为他们真正有能力并且了解一些工程原理。他们了解基本的工程和业务概念：风险，ROI，UX，性能，可维护性等。这些人将设计和文档视为连续的，通常能够使体系结构/设计的级别适应项目要求。

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

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

   一般来说，这些人都是关于创造一个产品，是“足够好”，因此他们的作品可能会有点下设计的，但它们英里从牛仔式的编码产生的面条代码了。当他们被告知掘金时，他们甚至无法识别他们，因为对他们而言，在后台发生的一切都不存在。

你们当中有些人可能会想到我还没有回答这个问题。那是因为问题本身是有缺陷的。牛仔编码不是一种选择，它是一种技能水平，并且您不能像文盲那样选择成为牛仔编码员。

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

如果您已经成为一名建筑宇航员，那么您在生理上和心理上都无法生产没有设计的软件。

如果您是准工程师（或专业工程师），那么只需很少或没有前期设计工作就可以完成项目是一种明智的选择（通常是由于截止日期很短），必须权衡明显的风险并采取相应的措施仅在利益相关者同意（通常是书面形式）之后。

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

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

是。

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

我不认为事先计划好的假期是适当的假期，不考虑饮食以营养为佳，或者在已知的小道上适当徒步。

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

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

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

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

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

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

这实际上归结为以下问题：如果没有适当的结构，并且在规划中浪费大量时间，则是否可以正确实现事情。

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

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

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

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

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

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

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

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

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

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

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

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

如果我在团队中工作，则需要一些约定和协议-团队中的每个人都必须遵循一些共同商定的标准来朝着共同目标努力，以使他们的努力相互兼容。

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

• 古典力学？牛仔艾萨克·牛顿（Isaac Newton），后来从莱布尼兹（Leibniz），拉格朗日（Lagrange），汉密尔顿（Hamilton）增购。
• 飞机？牛仔莱特。
• 相对论？牛仔阿尔伯特·爱因斯坦。
• 计算机基础科学？牛仔艾伦·图灵。
• 晶体管？牛仔Walter Brattain和John Bardeen。

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

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

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

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

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

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

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

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

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

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

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

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

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

肯特·贝克（Kent Beck）等人都是专业人士，他们看到过时的处理过程本身就很糟糕，因此他们创建了新的方法来组织编码，同时仍使编码更加面向工艺，然后通过出版书籍将其告知其他所有人（您在上网之前还怎么做？）

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

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

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

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

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

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

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

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

您可能会在我对Frankly的回答中找到一些见识，您喜欢牛仔编码吗？ 麻烦的是，“牛仔编码”对于不同的人来说意味着不同的东西，而对于未经培训的人来说，这并不是立即显而易见的，您所看到的是哪个版本。

当某人可以查看问题并立即开始快速而准确地编写代码时，这可能是一位总工程师的标志，他曾经一千次见过它，并且已经知道解决问题的最佳方法。

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

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

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

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

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

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

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

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

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

从根本上讲，当我想到“敏捷”时，我认为“您需要做的事情是为了最大程度地减少多个人一起工作所带来的低效率”。所以，我坚定地在营里说：“没有这样的东西的敏捷方法，只是一套价值观和原则”。

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

例如，对于我自己从事的项目，我没有比最简单的待办事项列表了……这只是一个待办事项清单。如果我们两个人在一起，我可能会共享该列表，但是格式非常简单（可能只是存储在我们代码仓库中的便笺）。一旦有了3或4，我正在寻找某种工作项目系统。

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

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

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

但是，我的内心很“整洁”，不喜欢那种从头到尾的开发风格。

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

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

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

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

在这样的情况下，有什么往往是值得被产品化图书馆，使这样简单的任务。这样一来，前端代码通常变得非常琐碎，以至于编写（或修改）代码来执行所需的工作比解决如何使完整的程序执行所需的工作要容易得多。考虑一下，例如，gnu缩进了50多个不同的标志，其中许多标志以各种微妙的方式交互，因此，唯一合理的选择是1）根本不使用它，或2）决定喜欢它给您的东西而不是试图获得您最初想要的东西。

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

我是一名平庸但可以说是尽职尽责的程序员-编码时除完成工作外，我主要关心的是，我正在帮助任何使用我的代码来完成其工作的人。我不能这么说，我一直都实现了这一目标-但这就是我的目标。

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

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

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

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

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

没有永不。

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

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

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

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

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

牛仔编程是创造一个大泥球的相当确定的方法。听起来不愉快，但往往会带来 ...

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

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

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

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

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

另一方面，做一个自己的人，自己决定问题的答案是什么，因为唯一可以肯定的是，在构建软件时，没人知道它是什么。这是使其成为有趣领域的一件事...