我是一个相对较新的开发人员，刚从大学毕业。在上大学时以及随后的求职过程中，我意识到我缺少很多“现代”软件开发方法：单元测试，日志记录，数据库规范化，敏捷开发（相对于通用敏捷概念），编码风格指南，重构，代码审查，没有标准化的文档方法（甚至要求）等。

总体而言，我认为这不是问题。我希望我的第一份工作会包含所有这些想法，并在工作中教给我。然后我在一家大公司获得了第一份工作（全栈Web开发），我意识到我们不做任何事情。实际上，我是团队中经验最少的人，是率先尝试使我的团队掌握“现代”编程技术的人，因为我担心不这样做会导致职业自杀。

首先，我开始使用日志记录软件（log4J），但随后我迅速着手编写自己的样式指南，然后放弃了它，而改用Google样式指南-然后我意识到我们的Java Web开发使用手写的前端控制器，因此我坚持我们对Spring的采用-但后来我意识到我们也没有单元测试，但是我已经在学习Spring ...正如您所看到的，它变得太快了，尤其是与正常的开发工作结合使用时。此外，我很难在这些方法论中变得足够的“专家”来教给其中的任何其他人，而又不花太多的时间去研究其中的一个，更不用说全部了。

在所有这些技术中，我认为在当今的软件开发世界中这些技术都是“预期的”，我如何将它们作为一个新的参与者整合到团队中，而又不让自己和团队感到不知所措？

我如何影响我的团队变得更加敏捷？是相关的，但我不是像这里的问询者那样的敏捷开发人员，并且我正在寻找比敏捷更广泛的方法集。

对我来说，听起来像是在把车推到马前。

您的团队面临的主要问题是什么？哪些技术可以解决该问题？

例如，如果存在很多错误，尤其是回归型错误，则单元测试可能是一个起点。如果您的团队缺乏时间，也许一个框架可能会有所帮助（中长期）。如果人们难以阅读彼此的代码，则样式可能会很有用。

请记住，您从事的业务的目的是赚钱，而不是赚钱。

Java的？现代？！您在第一个障碍中失败了。如果您想成为真正的现代人并且避免“专业自杀”，那么您必须编写Rust代码。当然，下周，一切都会改变，您必须学习一些更新的知识才能跟上！

或者，你可以接受，没有时髦的技术或方法，或框架或任何其他的量大谈特谈将改变要建立一个工作质量的产品的事实。如果成功产生正确的输出，则不使用敏捷也没关系。当然，如果不是，那么您可能想更改某些东西，但是没有特殊的实践机会可以解决问题。它们将仍然是人类问题，可以通过许多不同方式加以解决。

至于专业自杀，如果您知道自己在做什么并且很灵活，那么您就不需要任何提及的事情。人们将继续想出做旧工作的新方法，而您将永远追赶过去。或者，您可以简单地使用当前公司使用的任何技术。更换公司时，您只需学习和使用他们使用的技术即可。

太多的孩子迷上了他们可以使用的所有新工具，而忘记了这些工具在新手手中毫无价值。首先学习实践，一旦您是经验丰富的开发人员，就可以使用“新奇事物”来“修复”开发实践，但是到那时，您将有望意识到它们并不像您当前所认为的那么重要，并且仅在确实需要它们时使用。

许多公司都被这样困住了。您甚至会惊讶地发现，您的某些开发人员同事是自学成才的，成为没有正式背景的开发人员。这些开发人员通常更擅长于工作，因为他们将成为驱动学习新技能并取得成功的驱动力，而不是简单地干这项工作。不幸的是，这也可能意味着，尽管他们擅长编程，但他们可能不知道这些做法的好处。事实是这些是最佳做法，而不是常见做法。在最佳使用他们，但他们并不要求取得成功，它们只是工具，以帮助使成功更容易。

您是完全正确的，尝试一次实现所有功能将是不堪重负的。您可能会竭尽全力（甚至可能是您的团队）尝试这样做，这将削弱以后采用新方法/技术的努力。在这种情况下最好的选择是事情（记录可能是一个不错的开始，因为您可能要走很艰难的路才能找到没有记录的错误，并且肯定会有错误）并与团队讨论。您不必单枪匹马地实现它；您会更好地与团队（和您的老板，绝对必须这样）一起讨论团队的利弊，并提出实施方案。它必须尽可能地轻松（请记住，您要告诉人们，他们现在必须在已经做的事情之外编写更多的代码）。

再说一次，请确保您的老板同意。这至关重要。您可能会发现，随着实施新事物，修复/发布的速度变慢。关键是您要预先付款以节省成本。他们必须理解这一点，并站在您这一边。如果您不让他们参与进来，那么您充其量只能是一场失败的战斗，而在最坏的情况下，他们可能会认为您在积极破坏团队（请问我怎么知道）。

将这些项目带到桌面上之后，与团队讨论它们，计划如何实施它们，并逐步进行第二，第三，第八等等。不仅如此，团队和您的老板还有可能在您的建议得到实施并被认为可以增加价值时赢得您的尊重。大！只需确保保持灵活性即可：在这里要克服惯性，而改变并不容易。准备慢慢地使小更改，并确保您可以跟踪进度和所赚取的价值。如果您实现了新流程的登录，并且可以帮助您节省三周内发现错误的时间，那么请花很多时间！确保每个人都知道该公司通过提前做正确的事才节省了XXX美元。另一方面，如果您遇到压力，或期限紧迫，请不要试图强行提出问题。让新更改暂时滑动，然后向后转。您不会通过强迫团队做他们不想做的事情而获胜，并且您可以确定他们建议放弃的第一件事是新的“额外”工作（例如编写日志记录或遵循样式指南，而不仅仅是“使其正常工作”）。

希望您不要像您在帖子中向我们所做的那样向您的同事介绍这些问题。那将是专业的自杀。

第一个问题是，您正在尝试向一群程序员讲授即使没有经验的技术和方法，这些程序员也许有些过时了，但是却“完成”了工作。回火的可能性是无限的，并且可能会给您的同事带来很多快乐。您想改善自己和部门，但避免使用诸如“带头人”之类的术语，这是有趣而令人钦佩的。真诚的，不要使用这个词。

作为上述附带问题，请检查您是否正在做一些工作。我作为一个孤独的，自学的程序员已经工作了很多时间，并且我知道抛弃实际的工作来探索有希望的框架，技术等等是多么容易。确保您自己的性能在预期的参数范围内（不，没有人关心您是否花20个小时研究Spring，如果他们要求您完成该报告）。

从以上所有方面，避免成为老师（除非它与您实际上有足够经验的领域/技术有关）。一个比较中立的演示文稿将指出自动化测试的优势，并让管理层选择他们想要研究这些实践的利弊的人员。

现在，为了展示这些“最佳实践”，有两种方法可以向您的团队解释它们：

• 因为我说它们是最佳实践，这就足够了。
• 因为它们很有用，有助于解决问题。

使用第一个论点，除非您是团队的老板或非常高级的成员，否则他们不太可能给您任何注意。而且“我读过Knuth的书是这样的”或“ SE的人说的那样”不会给人留下任何印象，（“那些人不在这里工作，所以他们真的不知道这家IT商店有什么好处。 ”）。他们有自己的方法，例程，过程以及“或多或少”的工作，那么为什么要付出努力和改变的风险呢？

对于第二种工作方法，必须意识到存在问题。所以：

• 不要昼夜不停地进行自动测试。等到更新破坏了某些功能，团队必须加班来修复它，然后提议构建一个自动化测试系统。
• 不要要求代码审查。等到Joe休完长假，然后才需要更改仅Joe知道的模块，并指出您的老板为试图理解Joe的代码而浪费了多少时间。

当然，变革将是缓慢而渐进的（在大公司中更是如此）。如果您要在五年内引入代码审查和自动化测试，则应该对自己所做的出色工作表示祝贺。但是，除非由于外部原因进行了彻底的重写，否则请不要忘记它们会将核心IS转换为Spring的任何幻想（Joel向您解释了这种方式，甚至比您出生之前还更好¹）；到那时，您最多可以将Spring列入受支持的平台列表中，以编写非关键系统。

欢迎来到企业IT的世界，男孩！:-p

¹：好的，也许我有点夸张，但不是太多。

您应该从迈克尔·费瑟斯（Michael Feathers）的《有效地使用旧版代码工作》一书开始。从本书的引言开始，“这是关于采用纠结，不透明，复杂的系统，逐步，逐步，逐步，逐步地将其变成简单，结构合理，设计合理的系统。” 他主要从自动化测试开始，以便您可以安全地重构（您会知道是否破坏了任何东西），并且他提供了许多策略来将困难的代码置于自动化测试中。这对于仍在开发中的每个项目很有用。一旦有了一些基本的顺序，就可以看到您的项目可以从中真正受益的其他现代技术-但是不要以为您需要所有这些。

如果您出于专业原因而不是因为您当前的项目实际需要它而想要学习一个新的框架（或其他东西），那么您应该（在自己的时间）在某个个人项目中使用它。

源代码控制。

您没有提及它，希望是因为它已经存在，但是如果没有，请从那里开始。

源控制具有最大的优势，除非在少数情况下，在病理上需要其他条件。

如果最初没有人买入，您可以独自开始。

直接回答

其他答案为采用更好的做法提供了很好的“要点”，但是，为了给您一些直接相关的指导，这是我建议您的团队（或任何团队）采用（第一）的最佳实践的粗略排序：

1. 源代码控制
2. 问题跟踪（项目和任务管理）
3. 自动构建¹
4. 自动化部署

^{1 _{一个非常相关的做法是自动化或至少记录下来，以设置要开发或维护的每个应用程序或软件项目的构建和开发环境。因为您（希望）很少或很少这样做，所以它的用处不大。}}

其他一切

您提到了其他一些良好实践-“单元测试，日志记录，数据库规范化，...重构，...文档”-但这些都是可以并且应该逐步采用的实践。不需要一次全部采用它们，您最好通过认真，谨慎地采用它们来更好地采用它们。

我上面列出的四种实践也将使采用和尝试新实践尽可能容易。例如，可以将单元测试合并到您的自动化构建中，并可以将文档发布为自动化部署的一部分。

您提到的其他一些实践-“敏捷开发，...编码样式指南，...代码审查，...标准化文档方法”和框架（例如Spring）-确实是可选的或具有可疑的价值。这是您会发现或遇到的很多（大多数？）可能的做法。

敏捷开发显然并不优于所使用的任何其他方法。许多人（包括我自己）都经历过可怕的经历。但是很多人也真的喜欢（或喜欢）它。试试吧！

编码样式指南可能会有所帮助，尤其是对于大型项目或大型团队而言，但实施这些指南也需要大量工作，而这可能并不是任何人使用它们的最佳时间。

代码审查也可能非常有帮助–您是否要求同事审查您的代码？请记住，您无需采取正式流程即可采用良好做法！

文档很棒–您有资料吗？如果是这样，对您有好处！您是否面临许多额外的工作，而这些工作如果有（更多）“标准化”文档可以防止？如果是的话，那可能是值得做的事情。但是，如果您的软件仅由一小部分人使用，则可能不需要任何文档。（或者，您可以直接将文档合并到您的软件中。这始终是我的偏好。）

框架是……（非常锋利的）双刃剑。一个很好的封装和维护良好的解决方案，可以解决您的软件的非核心功能，这是很棒的……直到事实并非如此。我不确定确切的“手写前端控制器”是什么，但是对于为什么它们不如利用Spring的代码逊色，没有明显的解释。您是否考虑过将所有这些控制器中的通用逻辑封装到您自己的内部框架中？采用Spring并重写所有现有代码，可能是一个巨大的重构（或更可能是重写）项目，而这可能并不是您可以对代码进行的最佳更改。当然，您不应该编写所有使用的软件-框架（和库）很棒！但是也许您不必使用Spring（或替代方法）来编写出色（或出色）的Web应用程序。

环顾您所在的团队。您是否能看到任何证据表明测试驱动的开发或数据库规范化将改善您正在编写的软件的质量或使人们的生产率更高？

您是否尝试过与一位开发主管或开发负责人交谈？真正非正式的聊天将是一个好的开始。是什么让您认为您之上的人没有相同的想法，但由于业务不允许而无法/将其付诸实践？

我发现以身作则是一个不错的选择。如果其他人已经完成了工作并且可以向他们展示如何复制它，人们的抵抗力就会大大降低。将TDD引入您正在从事的项目中。要求向团队中的其他成员，甚至其他几个人进行演示，并向他们展示您的工作。@DrewJordan所说的从老板那里买进的东西比您可能意识到的要重要得多。

发现缺陷。修复缺陷。显示修复程序。

让我们首先进行归一化*。实际上，我建议您首先使用它，因为缺乏规范化可能会导致实际的错误数据，否则这些错误数据就不会存在，而其他情况则是最佳实践可能会有所帮助，但很难说“ A是由于未遵循政策X“引起的。如果您的数据库未规范化，那么您的数据可能会不一致。

不错的选择是，您将能够发现实际数据不一致的情况。您现在发现了两件事：

1. 您数据中的错误。

2. 数据库架构中的错误。

您实际上首先了解了第二个错误，但是第一个错误更容易证明，并且也引起了实际的问题，而理论上却没有。

不幸的是，拒绝规范化非规范化数据库的真正原因之一是，如何处理此类错误数据并不总是那么容易，但是您会发现一个实际的错误。

（请注意，尽管有一些原因有时会故意使某些数据非规范化。不要将知识渊博的违反规则误认为是对规则的无知；如果规范化了出于查询速度而故意非规范化的表，则可以即使赢得了赞誉，也应该在程序上进行处理，因此，如果未根据规范化表的内容自动创建非规范化表，那么仍然会有进步。

对于其余部分，在他们短期内提供帮助时对其进行介绍，以后在长期内对其进行扩展。例如，如果给您要编写的一小段代码，请为此编写一个单元测试。更好的是，如果您得到要修复的错误，则编写一个由于该错误而失败的单元测试，然后在修复该错误时，请说明在关闭这些错误时该错误通过了（或发送一封电子邮件指出该错误已修复） ， 管他呢）。

*顺便说一句，不是很现代。这就是所谓的原因正常化，而不是正火或别的东西，是在当时，这是一个局部的笑话坚持化对事物的结束，使尼克松的名字的乐趣越南化政策。

我要反驳说：在花一些时间在这份工作上花一点时间来建立自己的简历后，再找一份新工作。瞄准一年左右。尽管很多事情都是“流行语”，但是对于单个开发人员而言，诸如完全缺乏单元测试之类的问题是棘手的，而且很可能，如果在那里工作的程序员没有测试的欲望，那么您永远都不会买账，甚至可能危及您的职位在公司中让人们认为您是个顽强的人。您需要在一个可以得到指导的地方，而不是试图将文化推向基本能力。

已经有很多关于改进编程范例的建议。现在最热门的流行语似乎是敏捷编程和面向对象。还是他们？与五年前相比，两者都已大幅下降。

您可以完全相信，无论采用什么方法，都试图达到相同的最终结果：帮助工程师经济地生产出足够好的最终产品。

有一个模式，它是有争议的20世纪60年代引入： 结构化程序设计：只能用“高级别”结构，如while，for，repeat，if/ then/ else，switch/ case语句来代替大量使用goto其已接受默认的语句。有仍辩论是否goto有任何合法使用的。

我接受最大程度地减少使用goto是一件好事，但是像所有其他好事一样，有可能走得太远。

您提到的agile方法论是积极的。我在一个开发团队工作了大约六个月，有意遵循了规定的敏捷方案。我发现它就像几十年前的开明的项目管理方法一样，只是一切都被重命名了。也许通过重新打包和转售与某人交流的想法谋生，公司就可以“看到” 皇帝的新衣着。

敏捷是最有价值的一课，这是很久以前就知道的，灵活性是找到最终产品更好的途径是一件好事，而找到该途径的能力可以来自任何人，而不仅仅是高层管理人员。

摘自反goto头目Edsger Dijkstra的文章：

编程的技巧是组织复杂性，掌握众多技巧并尽可能有效地避免其杂乱无章的技巧。

—Dijkstra，载：Dahl，Dijkstra和Hoare 1972年，第16页。6.（参见第6页这里。）