在什么时候为了更多的钱而放弃一些软件开发原则？

我想把这个问题扔出去，有趣地看看介质在哪里。

我要承认，在过去的12个月中，我获得了TDD和软件开发中的许多敏捷价值。我对软件开发的进步感到不知所措，以至于我永远都不会放弃它们。直到...我被任命为承包人，这使我当年的实得工资翻了一番。

我加入的公司没有遵循任何特定的方法，团队还没有听说过代码气味，SOLID等问题，而且如果团队从未做到过，我当然也不会浪费时间进行TDD在实践中看到了单元测试。我卖完了吗？不，不是完全...代码将始终被“干净地”编写（按照Bob叔叔的教）），并且SOLID的原理将始终应用于需要的我编写的代码。尽管对我来说测试已经放弃了，但坦率地说，公司无法承担如此未知的任务，即使我确实创建了测试框架，他们也永远不会正确使用/维护测试框架。

以此为例，您会说开发人员出于金钱/个人其他利益而绝不放弃其工艺原则的观点？我了解这可能是一种非常个人的看法，即人们对自己的需求，业务需求以及工艺等方面的关注程度。但是，可以考虑，例如，如果公司决定宁愿进行测试，则可以放弃测试。测试团队，而不是理解编程中的单元测试，那会不会像我那样原谅自己？因此，考虑到您会丢掉一些东西，通常业务中应该有相等的成本来弥补您丢掉的东西-希望如此，除非您当然愿意掏腰包而不是依靠社区/社会合作； ）。

加倍您的钱，回到RAD？或继续前进，寻找正在做敏捷的人，再也不回头...

自从我10多年前沉迷于单元测试以来，在我的大多数工作场所中，我是第一个听说过这些测试的人。尽管如此，我仍然尽可能地编写我的小型单元测试，并估算单元测试在任务中的成本。每当有人问我的编码习惯时，我都会告诉我我在做什么以及为什么它对我有用。通常，至少有一些人对此感兴趣，最终我必须进行关于该主题的演示，并指导人们编写他们的第一个单元测试。

您无需在新工作场所的第一天就就敏捷方法说服人们。尽可能多地遵循自己工作中的原则。如果做得好，您将提供更好的代码。如果您的同事和/或管理人员注意到它，他们会问您如何做。然后，您可以告诉他们。

更新资料

大多数经验丰富的开发人员（和管理人员）都已经看到了趋势和潮流的来临，因此他们对最新的流行语并不感到兴奋。但是，如果您可以证明某种方法（工具，思维方式）在实践中确实可行，那么在实际项目中，关心工艺的人几乎肯定会坐下来倾听。但是，如果您的团队中没有这样的人，也许是时候寻找一个更好的地方了……

我认为这是所有开发人员都应该了解一些项目管理的地方。一切都是时间，金钱和资源之间的权衡。考虑一下自己的资源。

在我十二年的编程生涯中，我认为我从未完成过一个项目，并认为它已经完成或在我脑海中完成。我总希望自己能做得更好或更清洁。我花了很长时间才意识到这是由于这些折衷所致。

因此，如果您只是因为方法论不存在而考虑更换工作，那么我会再次考虑。这些权衡是不变的，并适用于所有软件开发人员。即使是最敬业的游戏开发人员，也希望他们可以重新做一些事情，或者如果有机会，可以再次练习另一种方法。

我要说的是，您应该研究自己的敏捷开发实践，并意识到即使在微观层面，您也可以做到这一点。当然，您的队友可能会在la la la laland上做他们想做的任何事，但是您的个人满意度会更高，从长远来看，您肯定会生成比他们更好的代码。然后，当经理来询问您的代码为何如此出色时，您就有机会转换团队：)

但是，如果您不喜欢员工或工作，那么我想您已经知道答案了。但是我非常怀疑有人会走进教室，告诉您在编码时不要使用敏捷开发原则……如果他们这样做的话……大喊大叫。

从长远来看，切勿丢掉会让您不高兴的东西。当然，您可以从无人区开始，并尝试使团队朝您的方向前进。如果您愿意付出努力，并且工作值得，那么这甚至可能是一个有趣的挑战。

但是，如果您不得不离开那些让编写代码保持愉悦的东西（或与此相关的任何工作），那么我的经验是，您迟早会离开。我了解到绝不能低估沮丧。

您上一份工作的人员已经知道TDD，SOLID等。这太好了。我相信您喜欢在那里工作并学到了很多东西。现在，您将有机会教这些概念（同时赚大钱）。以我的经验，必须教别人一个概念总是可以帮助我自己更详细地学习它。请耐心等待，并一次提出一个概念。当您感到沮丧时，回家算一下钱。或寻求SE支持。

我必须承认我在这方面是绝对的。作为自由职业者，无论客户认为哪种项目的方法正确，我都可以接受。这并不意味着钱是我唯一关心的，但是决定做什么和遗忘什么取决于客户。不过，我不会接受恶劣的工作条件（大声，长时间工作等）。

我想引用我的一位前同事。他说，每当他寻找工作或兼职项目时，该项目必须满足三个条件：

• 和它一起工作一定很有趣
• 它必须对您的能力发展有益（不确定这是否是表达它的正确方法）
• 应该还不错

当我阅读您的问题时，该项目仅满足最后一个条件。

随着您对TDD的喜爱（就像我一样），我认为您将每天走动，并希望您的所有同事都获得与您相同的见解。因此，可能不符合第一个标准。

其次，如果您想从事TDD项目，并且可能在构建敏捷团队方面获得更多经验，那么从事此项目并不会帮助您增强这些技能。因此，第二个也可能不会被满足。

因此，就我个人而言，如果我能担任您的职务，而又无法帮助将TDD引入公司，我会去找别的地方。

决不。

生命太短了（特别是随着年龄的增长），无法做自己会讨厌的事情。

当然，这确实使换工作变得更加困难，并且工作场所更少。

但是至少只有旧版代码难闻。（而且我有自主权，因此我们可以做一些明智的事情，例如花一个星期的时间来消除旧版代码库中的编译器警告。...）

简而言之，开发方法并不属于您。这不是a悔，也不是您。这是一个工具。按照您的要求做，如何做，并赚取额外的钱。如今，已经开发了成千上万个没有TDD，Code Smell等系统的系统。在几年之内，没人会知道这些术语的含义，因为方法论的兴起比城市公共汽车更为频繁。像被告知的那样努力工作，并随时随地接受金钱的感谢：）

只要确保与新团队合作是您宝贵的时间。

也许它们以比您到目前为止遇到的方式更有效的方式工作？如果是这样，与他们合作将是一个很好的学习经历（因此，是一笔不错的投资）。

另一方面，新团队的方法论对您可能没有什么价值（太多的“牛仔编码”等）。在那种情况下，额外的钱可能是不值得的（除非它是IPO前的初创公司或非同寻常的公司）。您可能不会学到很多东西，并且可能会精疲力尽。

我不会在不允许我按照自己想要的方式工作的地方工作。我的意思是说我不想受到微观管理。

我以我擅长的工作为前提，如果您给我一些任务，我会高效地完成它们。在不违反您的代码准则和模式的前提下，如何实现它们取决于我。那是我工作的乐趣。

如果我想对我编写的每个班级进行单元测试，那可能是个问题，但是只要我仍按时完成，编写单元测试就可以了。我希望TDD的拥护者会认为编写单元测试实际上会提高生产率（以后等等）。如果我不知所措，我会写一些单元测试，这将节省我一些时间（大概更少的错误，更容易的修复）。如果您将节省下来的时间投入到更多的测试中，那么它将节省更多的时间，最终，当您拥有一套很棒的测试时，您可以大笑一笑，并在新的第11小时轻松检查代码更改要求进来了。

如果我做不到，那我就不知道是否要在那里工作。

我的意思是，我认为在这些问题上应该有所取舍-有点谈判。他们付给我的钱越多，我所期望的非金钱上的好处就越少。但是我总是需要一定程度的自主权和自尊心，尤其是在不需要拒绝的时候。只要我有一定的自治权，我就会放弃任何其他原则。毕竟，看起来有些疯狂的方法论可能是您做过的最好的事情！