Questions tagged «cowboy-coding»

我很调皮……太多的“牛仔编码”，还不够提交。现在，我在这里做出了巨大的贡献。是的，我应该一直坚持下去，但是现在为时已晚。 什么是更好的？ 做一个非常大的提交，列出我所做的所有更改 尝试将其分解为可能无法编译的较小提交，因为文件具有多种修复，更改，其他方法名称等。 尝试仅针对适当的提交对文件进行部分还原，然后放回新的更改。 注意：到目前为止，我是唯一从事此项目的程序员。至少在我们雇用更多程序员之前，唯一会查看所有提交评论的人就是我。 顺便说一句：我正在使用SVN和Subclipse。在进行任何这些更改之前，我确实创建了一个新分支。 更多信息：我首先问了一个与我如何进入这种情况有关的单独问题：如何为重写应用程序的粘合做准备

100 version-control  development-process  scm  cowboy-coding 

我认为，敏捷方法最适合需求模糊且需要大量交互以帮助塑造最终用户想法的项目。 但是...在我的专业工作中，我一直不停地被那些使用“敏捷”方法作为为什么不花精力在前期设计上的公司作为最终结果。当要求很容易理解时。 我忍不住想，如果没有敏捷方法，我会坐在这里，拥有一个很好的高级规范，而不必在第二天左右出现其他问题时隔天重新访问相同的屏幕和功能所以没有想到这一点。 敏捷方法学的好处真的足以超过给牛仔技术领导者带来la脚的借口吗？ 更新：具有讽刺意味的是，我现在是一名认证的Scrum Master。在Scrum课程上发表的一篇论文指出，最好的开发过程是只有一个专家或专家来进行设计决策的过程，但是它存在明显的弱点。Scrum将生产高质量软件的责任转移到“团队”，这意味着不合格的团队可以摆脱意大利面条的困扰，我想这与其他敏捷和非敏捷开发流程没有什么不同。

73 agile  cowboy-coding 

大多数程序员捍卫政治上正确的方法论，例如敏捷，瀑布式，RUP等。其中一些遵循方法论，但并非全部遵循。坦白说，如果您可以选择方法论，那么您肯定会采用主流的“正确”方法论，或者您更喜欢像牛仔编程这样的“简便”方法论？为什么？ 我知道这取决于。请说明何时使用一种或另一种。请说出您在Cowboy编码方面看到的优势。 在Wikipedia上了解有关Cowboy编码的信息

66 development-process  development-methodologies  cowboy-coding 

更新 我在一个由4个人组成的小型开发团队中工作。他们都使用了源代码控制。他们中的大多数人不能忍受源代码管理，而是选择不使用它。我坚信源代码控制是专业发展的必要部分。有几个问题使得说服他们使用源代码管理非常困难： 该团队不习惯使用TFS。我进行了2次培训，但只分配了1个小时，这是不够的。 团队成员直接在服务器上修改代码。这样可以使代码不同步。要求比较只是为了确保您正在使用最新的代码。并出现复杂的合并问题 开发人员提供的时间估算不包括解决这些问题所需的时间。因此，如果我说诺诺，则需要花费10倍以上的时间...我必须不断地解释这些问题并冒险冒险，因为现在管理层可能会认为我“慢”了。 服务器上的物理文件超过100个文件以未知的方式有所不同。合并需要了解手头的项目，因此需要我无法获得的开发人员合作。 其他项目不同步。开发人员继续对源代码管理不信任，因此不使用源代码控制使问题更加复杂。 开发人员认为，使用源代码控制很浪费，因为合并容易出错并且很困难。这很难辩驳，因为当源代码控制被严重滥用而源代码控制被不断地绕开时，它确实容易出错。因此，证据在他们看来是“不言而喻”。 开发人员认为，绕过TFS直接修改服务器代码可以节省时间。这也很难争论。因为开始同步代码所需的合并非常耗时。乘以我们管理的10多个项目。 永久文件通常与Web项目存储在同一目录中。因此，发布（完全发布）会删除这些不在源代码管理中的文件。这也加剧了对源代码控制的不信任。因为“发布破坏了项目”。解决此问题（将存储的文件移出解决方案子文件夹）需要花费大量时间和调试时间，因为这些位置未在web.config中设置，并且通常存在于多个代码点中。 因此，文化会持续存在。不良做法会导致更多不良做法。不良的解决方案会驱使新的黑客“更正”更深层次，更耗时的问题。服务器，硬盘空间极难获得。然而，用户的期望正在上升。 在这种情况下可以做什么？

62 version-control  teamwork  team-foundation-server  cowboy-coding 

我发现了一个问题（团队中的牛仔代码），但它与“忍者编码器”的关系更大，而与我遇到的问题有关。 我有一个团队成员，他是“ 牛仔编码器 ”的真实代表。我确实知道不能改变人，但是是一种使他像“牛仔编码器”一样停止行为的方法吗？ 他拒绝听取团队的意见，并且他最近停止了代码审查，单元测试，共享实施细节等。 是的，他可以快速“编码”，但是他的代码只是一个错误生成器。我和其他团队成员都处于“错误修复阶段”，其中80％的错误来自他的代码。我不想修复他的错误。管理层是盲目的，或者不想看到这一点，或者他们喜欢他的“速度”。 我（作为他年龄较小的同事，而不是老板）可以采取任何措施吗？ 我该如何解除牛仔编码器的武装？ 我觉得我是最后一个真正关心这个项目的人。

37 development-environment  teamwork  communication  cowboy-coding 

当使用支持嵌套函数（例如Python和D）的语言处理复杂算法时，我经常编写大型函数（因为算法很复杂），但是通过使用嵌套函数来构造复杂代码来减轻这种情况。即使大型功能（超过100行）仍通过使用嵌套功能在内部进行了结构合理，仍然被认为是邪恶的？ 编辑：对于那些不熟悉Python或D的人，这些语言中的嵌套函数还允许访问外部函数范围。在D中，此访问权限允许外部范围内的变量发生突变。在Python中，它仅允许读取。在D中，可以通过声明显式禁用对嵌套函数中的外部范围的访问static。

23 coding-style  coding-standards  readability  cowboy-coding