我的团队应该从哪里开始成为“现代”？ [关闭]

#1 楼

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

您的团队面临的主要问题是什么，哪些技术可以解决该问题？例如，如果存在很多错误，特别是回归型错误，那么单元测试可能是一个起点。如果您的团队缺乏时间，也许一个框架可能会有所帮助（中长期）。如果人们在阅读彼此的代码时遇到困难，则样式可能会有用。

#2 楼

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

或者，您可以接受没有任何流行语技术，方法论或框架或任何其他形式其他新闻将改变您想要制造有效产品的事实。如果成功产生正确的输出，则不使用敏捷也没关系。当然，如果不是，那么您可能想更改某些东西，但是没有特殊的实践可能会解决问题。它们将仍然是人类的问题，可以通过许多不同的方式解决。你提到过人们将继续想出做旧工作的新方法，并且您将永远追赶过去。或者，您可以简单地使用当前公司使用的任何技术。更换公司后，您只需学习和使用他们使用的技术即可。

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

#3 楼

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

你是完全正确的，尝试一次实现所有功能将是不堪重负。您可能会竭尽全力（甚至可能是您的团队）尝试这样做，这将削弱以后采用新方法/技术的努力。在这种情况下，最好的方法是选择一件事（日志记录可能是一个不错的开始，因为您可能很难在没有日志记录的情况下查找错误，并且肯定会有错误），并与团队讨论关于它。您不必单枪匹马地实现它；您会更好地与团队（和您的老板，绝对必须这样）一起讨论团队的利弊，并提出实施方案。它必须尽可能轻松（请记住，您要告诉人们的是，除了他们已经做的事情之外，他们现在还必须编写额外的代码）。再说一遍，请确保您的老板同意。您可能会发现，在实施新事物时，修复/发布的速度会降低。关键是您要预先付款以节省成本。他们必须理解这一点，并站在您这一边。如果您不让他们参与进来，那么您充其量只能是一场失败的战斗，而在最坏的情况下，他们可能会认为您在积极破坏团队（请问我怎么知道）。

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

#4 楼

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

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

作为上述附带的问题，请检查您是否在做一些工作。我已经作为一个孤独的，自学的程序员工作了很多时间，并且我知道抛弃实际的工作来探索有希望的框架，技术等等是多么容易。确保自己的表现在预期的参数范围内（不，没有人会在乎他们是否花了20个小时研究Spring，如果他们要求您完成的报告没有完成）。教师（除非它与您实际上有足够经验的领域/技术有关）。一个更中立的演示文稿将指出自动化测试的优势，并让管理层选择他们想要研究这些做法的利弊的人。

现在，介绍那些“最佳做法” ，有两种方法可以向您的团队解释它们：


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

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

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


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

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

欢迎来到企业IT领域，男孩！ :-p

1：好的，也许我有点夸张了，但并不过分。

#5 楼

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

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

#6 楼

源代码控制。

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

源代码管理具有最大的优势，除了在极少数情况下，在病理上需要其他东西的情况下。

#7 楼

直接答案

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


源代码管理
问题跟踪（项目和任务管理）
自动构建1

自动化部署

1非常相关的做法是自动化或至少记录设置您正在开发或维护的每个应用程序或软件项目的构建和开发环境。它没那么有用，因为您（希望）很少或很少这样做。标准化，...重构，...文档”，但这些都是可以并且应该逐步并逐步采用的做法。不需要一次全部采用它们，您最好通过仔细，认真地采用它们来更好地采用它们。

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

您提到的其他一些实践–“敏捷开发，...编码样式指南，……代码审查，……标准化文档编制方法”和框架（例如Spring）–确实是可选的或具有可疑的价值。您将发现或遇到的很多（大多数？）实践都是如此。许多人（包括我自己）都曾经历过可怕的经历。但是很多人也非常喜欢（或喜欢）它。试试吧！

编码样式指南可能会有所帮助，尤其是对于大型项目或大型团队而言，但实施这些指南也需要大量工作，而这可能并不是任何人使用它们的最佳时机。 br />代码审查也可能非常有帮助-您是否要求同事审查您的代码？请记住，您无需采取正式流程即可采用良好做法！如果是这样，对您有好处！您是否面临许多额外的工作，而这些工作如果有（更多）“标准化”文档可以避免？如果是的话，那可能是值得做的事情。但是，假设您的软件仅由一小部分人使用，则可能不需要任何文档。 （或者，您可以直接将文档合并到软件中。这始终是我的偏爱。）

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

#8 楼

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

您是否尝试过与一位开发主管或开发负责人交谈？真正非正式的聊天将是一个好的开始。是什么让您认为上层的人没有相同的想法，但由于业务不允许而无法/不会实施它们？一个好方法。如果其他人已经完成了工作并且可以向他们展示如何复制它，人们的抵抗力就会大大降低。将TDD引入您正在从事的项目中。要求向团队中的其他成员或什至其他几个人进行演示，并向他们展示您的工作。 @DrewJordan所说的从老板那里买进的东西比您可能意识到的要重要得多。

#9 楼

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

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

最好能找到一个不一致的数据的实际案例。现在，您发现了两件事：


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

您实际上已经了解了第二个问题bug首先出现，但是第一个更容易证明，并且是引起实际问题的原因，而不是理论上可能的问题。处理此类错误数据并不总是那么容易，但是您会发现一个实际的错误。

（请注意，尽管有某些原因有时会故意使某些数据非规范化。将规则知识化为愚昧无知是不正确的；如果您规范化为了查询速度而故意非规范化的表，您将不会赢得任何荣誉。即使在这种情况下，繁琐的非规范化也是应该通过程序完成，因此，如果未根据规范化表的内容自动创建非规范化表仍然有进步的余地。）

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

*顺便说一句，不是很现代。之所以称其为“正常化”而不是“正常化”之类的原因，是因为当时在话题结尾坚持固话以取笑理查德·尼克松的越南化政策之名是一个笑话。

#10 楼

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

#11 楼

有许多改进程序设计范例的建议。现在，最热门的流行语似乎是敏捷编程和面向对象。还是他们？与五年前相比，两者都已大幅下降。
有一个在1960年代引起争议的范例：结构化编程：仅使用while，for，repeat，if / then / else，switch / case语句之类的“高级”结构，而不是频繁使用的goto语句默认情况下已接受。关于goto是否有任何合法用途，仍存在争议。 goto方法论是积极的。我在一个开发团队中待了大约六个月，有意遵循了规定的敏捷方案。我发现它就像几十年前的开明的项目管理方法一样，只是一切都被重命名了。也许通过重新捆绑和转售与某人交流的想法谋生，公司就可以“看到”皇帝的新衣服而感到愉悦。
很早以前就知道敏捷的最有价值的一课，就是寻找更好的灵活性。通往成品的路径是一件好事，发现路径的能力可以来自任何人，而不仅仅是高层管理者。

摘自反goto头目Edsger Dijkstra的著作：

编程的艺术是组织复杂性，掌握多种知识并尽可能有效地避免其混乱的艺术。 6.（请参阅第6页。）