（初级）开发人员是否应该尝试在其开发/ IT团队中寻求更好的流程和实践？

我是一名初级开发人员，如果我可以证明更改的合理性，并且可以帮助团队完成工作，则可以帮助调整团队的流程。这对我来说是新的，因为我过去的公司或多或少都严格定义了来自管理层的流程。

我的团队很小，有些新（不到3岁）。他们缺乏：

• 定义明确的软件开发/工作管理框架（如Scrum）
• 强大的产品所有权
• 定义明确的角色（例如，业务人员将进行手动测试）
• 定期站立会议
• 合并的问题跟踪流程（我们有一个工具，该流程仍在开发中）
• 单元，系统，回归或手动测试套件或列表
• 有关业务逻辑和流程的文档
• 知识库以记录内部和面向客户的提示

而这样的例子不胜枚举。只要价值是合理的，管理人员就可以实施改进措施，并且可以帮助完成最重要的工作（即开发）。但是，基本假设是您必须在实现中拥有所有权，因为没有人会为您做这件事。毋庸置疑，上述某些项目是不平凡的，无疑是耗时的，并且显然不是开发工作。

随着时间的流逝，（初级）开发人员尝试实现上述目标是否值得？还是最好“随心所欲”并专注于开发，将大部分流程定义和优化留给管理人员？

到目前为止，答案很好，但并不能涵盖所有基础。

以我的经验，许多刚从大学毕业的人都具有出色的理论知识-远胜于我或拥有数十年构建软件为生的许多其他老年人。

但是，这是一个很大的问题，知识并不以任何实际情况为基础。在现实世界中，许多理论都趋于统一，或者至少必须采用大量的盐，因为在实践中发现它在现实世界中不能很好地起作用。

例子：我很久以前从事的应用程序是由一位杰出的面向对象理论家设计的，其设计遵循T的面向对象原理和理论，并在各处应用了许多模式。

这是一个很棒的软件设计。

可悲的是，这导致了生产和维护的噩梦。代码库是如此庞大和复杂，以至于无法更改位置。不是因为它特别脆弱，而是因为它是如此复杂，所以没有人敢于触摸它，因为担心会发生什么（最初的建筑师/设计师是一个很久以来就已经离开的承包商）。

正是由于模式的多层结构以及设计所需的类库，它的性能也非常差。例如，单击屏幕上的按钮以对数据库进行一次调用将导致数百个对象实例化和方法调用-都是以确保松耦合和类似的方式进行的。

这位建筑师曾是一位大学教授，以他的名字写过几本有关该主题的书。他从来没有一天做过商业项目的程序员。

具有构建软件的实际经验的人们会意识到设计不可避免地会导致怪异的事情，并采取更加务实的方法，从而导致系统易于维护并且性能更好。

同样的事情可以适用于您在应届毕业生或任何公司的新员工中遇到的许多其他事情。不要以为您的理论基础会告诉您什么是错误的或次优的，所以不要以为这样做的理由不是很好。

即使到现在，在该领域已有20多年的经验，我仍然对批评与之合作的公司的工作方式持批评态度。我会顺便提及，我注意到事情与我的最佳经历有所不同，但不是好战的。关于这些事情为什么如此，通常会引发有趣的对话。取决于更改事物的价值是否小于成本，也许会发生改变，也许不会发生。

不要害怕暗示事情可能会做得更好，但始终要确保您不会像一个全知的流鼻涕的孩子那样，而是作为一个努力并且愿意不仅学习而且还愿意学习的同事帮助改善流程以改善公司，而不仅仅是理论上的正确性。

是的， 但要格外小心！

让我澄清一下。

您应该努力提高软件的可居住性。如果您查看代码/团队/业务/项目/管理，而您的第一反应是洗个澡，那是不适合的。如果您的第一反应是大声喊叫...，然后当您因草皮离开办公室而抱怨时，则需要使您的房屋更宜居。这是一种感觉，您会知道的。

话虽这么说，您正在从事一个复杂的工作。您所做的任何事情都可能出错，并且至少在短期内可能会使情况变得更糟，因为简单的更改会产生连锁反应。因此，首先要变得谦虚，我并不是说要推翻或接受事情一定很糟糕，我的意思是要接受这样的事实，即您的良好意图会恶狠狠地打扰您。

问题

怀着最好的意图，您可能会感到需要进行广泛的变革，我并不不同意这些情况确实存在，但请花一点时间考虑一下。当前的系统正在运行，您和您的团队正在生成代码，也许是缓慢的代码，也许是痛苦的代码，但是它正在运行，并且大家都具有执行此操作的经验。您大致知道会发生什么，简而言之，您是该系统中的执业专家。

经过全面的变革之后，除了实施者之外，没人知道会发生什么。简而言之，在系统的这一部分，每个人都被重置为新手级别。这不好。新手必须学习需要时间的新规则。在那个时候，新手正在犯错误，因为他们没有实践。这些错误成为系统的一部分，您现在必须忍受该错误，而且现在还没有那么闪闪发光。

前进的道路

有时，斜线，刻录和重建是您所能做的最好的事情。如果没有人在旧系统中实践，那么它特别有吸引力，因为唯一丢失的是已编码的知识。如果这种知识是完全不可理解的，那么它已经丢失了，重新开始是唯一的选择。相反，如果编纂方法或其用法有问题但可以起作用，则该知识仍可访问，并且可能值得保留，也许不值得-只是不要轻易做出决定。

另一种选择是使用系统，以便每个人都有一个参考框架，但是要更改系统的一小部分，以便团队中的每个人都知道，或者如果他们不知道更改，则很容易注意并且易于学习。这是称为Kaizen的实践的基础。在“剃须Ya牛”演示文稿中介绍了一个面向开发人员的公式，我强烈建议您仔细阅读并仔细考虑。

因此，找到一件可以改变的小事情，它可以改善您的生活，希望可以改善您的生活。解决或改善情况。这将为您提供实践和经验，以将更改付诸实践。确保您得到反馈：您是否可以更好地讨论它，它是否真的有用，是否使系统的另一部分不适？培养您对可以做什么以及如何做的感觉。

现在发生了三件事：

• 您已经改善了系统，
• 您已获得有关如何更改系统的经验
• 团队已经看到您成功更改了系统。

现在，随着您的经验的增长以及消除悬而未决的问题，您还需要选择另一项改进的东西，您将开始面对系统中较棘手的问题，但至少现在当您说我们必须更改X时：

• 您知道更改将如何影响系统
• 您知道它将产生什么问题（需要重新学习哪些规则）
• 您知道一些立即解决或解决变更将带来的问题的方法
• 您周围的人都知道您对系统有所了解，并能够成功进行更改

是的你可以。但...

你必须要小心。

在我职业生涯的开始（很久以前），我很幸运/很不幸进入了几个月大的“初级”项目。

我注意到的第一件事是（OMG）没有代码存储库！所有代码合并都是通过邮寄彼此发送zip文件来手动完成的。

因此，我去了（也是新来的）经理，建议我们应该有一个存储库。答案是：好的，整理一下....

因此，在没有帮助的情况下组织代码存储库在公司中是新的，现在这真是令人沮丧的经历。

当我完成所有设置后，（震惊）没有人愿意使用它。因此，我努力推进工作，幸运的是，我的经理了解了它的重要性，因此我得到了支持。

但是，这导致我不太喜欢，并且不幸地从源代码管理系统获得了一个昵称。

因此，我的观点是，首先了解您的团队成员，他们认为接下来要建立的团队很重要。

也许他们也有您的清单。也许他们已经完成了所有工作，但他们想做清单上的“事情”。也许他们……（无论如何）……

整个团队必须保持一致。

但是，如果不是，那么您仍然可以专业地工作。并找到志趣相投的人，并一起工作，您认为应该如何做。如果这带来了良好的结果，那么更多的人将与您合作，最终将成为“过程”。

就像代码一样，开发过程也是如此：需要持续改进。

因此，是的，您应该始终尝试进行改进，这是有可能改进的。

但也要记住与您一起工作的许多人，可能已经是专业人员，他们知道什么地方错了以及需要什么。

随着时间的流逝，（初级）开发人员尝试实现上述目标是否值得？

是的，尝试使事情变得更好总是值得您付出努力的。您最清楚自己毕竟会面对什么问题。

但是正如您所提到的，有许多问题需要解决，而且其中许多问题并不是很有价值。在很多地方，成功或其他条件更好的人都会遇到难以克服的障碍。所以，你应该总是试图把事情做好，即使这意味着采摘它的东西，你花你的时间来做出更好的。

因为最后，如果您不属于解决方案，那么您就是问题的一部分。

是。但是，即使对于高级管理人员而言，组织变革也很困难，因此，如果您真的想有所作为，请以正确的方式进行：

• 不在最初的几周内：利用这段时间来：

  • 创造良好的第一印象。证明你适合团队。
  • 了解文化和政治或您的公司。推动变革是否安全？
  • 与同事建立良好的关系
  • 了解团队的流程，规则和需求
  • 学习您的工作，并尽其所能。您一定会很忙。

• 选择你的战斗。早日取得胜利：您可能会充满力量改变一切，但这是不现实的。专注于一些低调的成果，并表明您的想法可行。您希望他们接受更复杂的改进。并记住，在书中事情要容易得多。

• 考虑对其他人的影响：我会重构影响很多文件。即使他们改进了代码，我也必须非常小心，以免将合并变成麻烦。还应尝试了解他们继续那样工作的原因。可能是由于缺乏测试，他们无法使用Scrum，并且可以理解的是，他们害怕将未经测试的代码频繁地投入生产。编写可行的测试绝非易事。当前的代码可能真的很难测试。此外，团队可能既不编写测试也不编写可测试的代码。当前的代码库可能特别难以测试，需要重构。更改此问题可能需要几年时间，但至少您可以专注于根本原因。

• 不要判断。不要要求。要求并仔细聆听：这是交流至关重要的时刻，程序员，我们通常不善于细微差别。有技术可以帮助。不断推动我们的想法而不是专注于答案很容易。首先，确保他们觉得您有他们的观点。了解感觉很重要。这种变化使他们感到什么？恐惧？不足？愤怒？挫折？希望？懒？笨？（永远不会使人感到愚蠢）。当然，您之前会问很多问题，这样可以避免很多错误的步骤。

• 以身作则：抱怨很容易，改变很难。显示结果，人们就会相信您。如果他们不使用测试，则可以编写单元测试。如果人们不提供文档，则可以与团队共享一些Google文档。理解“确定，做到这一点”是最好的方案之一，然后您需要交付。在这种情况下，您需要考虑所需的资源。示例：给我一个小的Amazon实例，让管理员离开Jenkins服务器两个小时

• 保持小巧而简单（又便宜）​​：您不想等待正式的预算批准，或者让您的老板认为您正在浪费昂贵的程序员宝贵的时间。最好使用此代码来审查软件或评估几个开源工具，但是我们暂时仅使用仓库。

• 达到临界质量：聚集一群致力于提高质量的人。您甚至可以与他们一起参加会议并寻求帮助或指导。Peopleware在团队的基础上形容“唤醒巨人现象”，实际上是在反抗一些愚蠢的做法，这些做法会降低生产率。单独地讲，这真的很危险，我不建议这样做。但是如果所有人都同意，改变就容易了。

• 给它一点时间。之后用脚投票：您可能想要在几个月至两年内尝试一下。但是有些公司没有简单的解决方案。一些团队不想改变并且没有激励。有些代码库简直令人恐惧。如果您觉得自己与世无争，请记住工作池中有很多职位。您想学习良好的做法，从长远来看，如果您的薪资水平明显降低，您会变得更好，但是获得的经验将使您变得更有价值。

奖励：如果成功，可以将其写下来进行简历/面试。作为初中生，您通常无话可说，做出更好的改变总是一个好兆头。您希望对自己的所作所为和他人的工作有一个非常清晰和现实的看法。想象以下面试问题。

• 告诉我您在团队中有所作为的那段时间。
• 好吧，我在一个地方，那里有老式的做法。很多人对此不满意，生产力还有很大的提高空间。因此，我建议进行回顾性的快速实验，我们分别进行了X和Y检验，结果得到了这个可衡量的出色结果。”

是。但是您建议的内容不对。

不在您的列表中单元/集成测试是您唯一可以取得进展的项目。

您可以以最少的时间投入就自己添加这些，并显示即时价值。这是一个技术问题，具有广泛接受的好处，不会影响其他工作惯例。即使您没有接受结果，也可以使您对代码库有所了解。容易卖出。

其他通常是涉及整个团队甚至其他团队的业务流程。您可能会提出改进建议，但对于初级员工而言，这些改进将很困难，并且更改过程通常是非技术性的，并且可能与您的正常工作无关。

我还建议诸如设置CI管道，自动部署，版本控制，打包库之类的东西作为攻击的好材料

这取决于：

• 您期望从更好的实践中获得多少
• 您要花多少精力才能到达那里
• 成功的机会和风险是什么-从简单的采用失败到新的实践实际上是可怕的，代码质量下降，关键人员离职，每个人都讨厌您，而您却不得不在另一个没人知道您名字的城市找到另一份工作

基本上：花一些合理的时间提倡自己认为最好的事情完全在您的职责之内-但决定应该是团队或管理的责任。请记住，即使最终会有更好的做法，疏远别人也很少值得。

不要从最复杂的事情开始，例如Scrum。从最简单的步骤开始。

您没有提到源代码管理。您是否有一些源代码存储库（git，svn，cvs等）？标记和分支的策略？这些是初学者可以做的简单步骤。阅读这些步骤（尝试）解决的问题，以及如何帮助您的公司降低成本（这是管理层感兴趣的）。

下一步可以是每晚或在每次入住后直接进行自动构建，例如使用Jenkins。您也可以自动运行测试。并添加一些用于测量代码质量的工具（哦，是的：定义一些编码标准也是一个好步骤）。

至于Scrum，最好阅读有关“极限编程”（XP）的内容。Scrum基于XP的许多思想，并围绕它们添加了正式的流程-如果没有XP的概念，仍可以使用XP的概念。

提出建议，提供背景信息，尝试说服其他人尝试，分析结果，...但是不要期望别人给予太多合作：大多数人都喜欢坚持自己的旧坏习惯。但是，如果您不尝试这样做，则不会有任何改善。

您说该团队还很年轻（3岁），所以如果您现在不能引入一些好的原则，那么10年后的工作将会更加困难。您提到的某些内容（例如测试和版本控制系统）已经可以提出建议，但不要在不强调它们的明显好处并选择开发堆栈所需的工具的情况下提出建议。

一开始问问题

阅读您的列表后，我将提出以下问题（请参考您的列表以了解它们的适用范围）：

• 我如何查看企业主要求的工作？
• 您是否尝试过[Scrum]？
• 谁是产品的所有者？
• 有什么作用？
• [此角色]是做什么的？
• 哪个角色负责[此活动]？
• 你有没有尝试过每天站起来？
• 如何将我的障碍传达给团队的其他成员？
• 我如何找出团队中其他成员的工作方式？
• 我们应该将[this]放在问题跟踪工具中吗？
• 我们应该如何在问题跟踪工具中编写[this]？
• 当[此]发生时，我们是否应该像[那个]那样将其放在问题跟踪工具中？
• 我们如何测试？
• 我们如何记录测试以供其他人重复使用？
• 您是否尝试过[JUnit]？
• [此]记录在哪里？
• 您尝试过[MediaWiki]吗？

适当地替换[方括号]中的内容，以使问题有意义或适合您的优先事项。如果我的措辞与您的风格不符，请考虑重新措词。

您可能已经开始这样做。优先于一对一对话而不是小组对话。因为一对一，您可以更好地了解他人的想法。这个人是这个人吗？反对？虚弱？疯了吗

当您是新手时，提问几乎是免费的。人们应该期望您提出问题。即使您的问题暗中鼓吹反对的立场，也不应生气。他们应该解释为什么反对这一立场。我建议不要与他们争论。争论往往会使立场更加坚强。注意谁有什么位置并继续前进。

稍后，采取步骤

寻找您和可能的其他人（即您之前指出的同意您的那些人）可以启动所需更改的方法。不是每个人都想站起来吗？为什么不？也许想要一个的人可以拥有自己的立场。不如整个团队有效，但比您现在拥有的更多。

当您遇到障碍时（并假设您无法分摊），请向团队发送电子邮件以寻求帮助。

确定角色应该是什么，可能要在其他同意您的人的支持下。当工作涉及到您（可能是您的一个小组）认为他们应该扮演的角色时，请开始始终如一地与他人联系。如果他们退缩，请他们确定谁应该担任那个角色。

要求产品所有者（您确定）撰写关于他们认为产品现在和将来应该如何工作的描述。

安装测试框架（如果其他人喜欢，请共同决定使用哪个框架），并将其用于您的项目。修复错误时，编写测试。将此文档记录在问题跟踪器的错误报告中（表明错误的书面测试，存储在[location]）。鼓励其他人在进行更改时运行测试。如果没有，请自己运行测试，并在必要时将问题提交给跟踪器。

如果您可以获得管理支持，请安装Wiki软件或类似软件，然后开始记录您的资料。如果有人问您一些问题，表明他们没有阅读文档，请将其指向相关页面。如果他们不了解文档，鼓励他们提出更多问题。如果他们继续问文档中涉及的问题，请在回答时引用文档中的内容。如果您认为问题是结构性的而不是他们没有阅读，请考虑鼓励他们更新Wiki。

我建议一次只专注于一项任务。当然，一次只能推一个。不要努力 看到这个比团队想要的更努力的例子。比他们更专注于改变您的行为。如果您的方法是正确的方法，那对观察您的人应该是显而易见的。行动胜于雄辩。轻推时，尽量不要与同一个人重复。一旦您将马匹引水了，就可以选择何时或是否该给另一只喝水了。

最终，您将成为高级

随着时间的流逝，您的团队将雇用新人。您将不再是新员工，而是可以与新人一起提拔您的职位。与他们一起进行更改。而且您可能会发现与现有的队友也在进步。或者，如果这不起作用，则在他们有更好的做法的情况下寻找新工作。不用着急。你有一份工作。您可以等待一段时间，找到更好的工作，要么改善工作，要么找到更好的工作。

简短答案：否，出于其他答案中概述的所有原因。即使是中高级开发人员，加入新团队时通常最好先寻求了解。

建议的解决方案：

1）每当您发现需要改进的地方时，请注意！（在笔记本中，在数字笔记中...）

2）6个月后，返回笔记并检查。现在有多少主意感到毫无意义和不足？很可能您为自己节省了一些尴尬。如果某些想法仍然存在，那么现在将是介绍它们的好时机，如果可能的话，请先自己进行测试。

晚答案，并在其他答案中同意很多好的内容。

我认为需要指出的是，这里的关键问题不是具体做法，而是整体团队文化。

• 创造文化变革是困难的。
• 如果您被视为“初级”，则更是如此

如果有实现持续改进的方法，那么其他所有事情都会随之而来。

我实现这一目标的方法是：

• 文件化的流程和程序
• 团队的回顾，其行动是对流程文档的更改。

我想如果您没有冲刺，那么您还没有常规的回顾。您所需要做的就是与团队进行对话，然后采取行动。

您可以轻松地开始记录过程。“我是新人，我说对了吗？让我写下来。” 然后自己真正按照流程进行操作，或者尝试打电话给我们中断的地方，这一点很重要。

也许您从这样的临时对话开始，然后建议常规的仪式。

采用这种方法可以渐进地，轻柔地进行。您可以避免以初级人员的身份来了解他们所掌握的一切，而可以尝试成为团队进行变更的促进者。

一些注意事项：

• 一些团队的过程很糟糕，但实际上已经知道这一点。他们想要改变，而只是需要某种催化作用。其他团队确实陷入了困境，很难改变。
• 个人也是如此。
• 您需要对此保持敏感，并弄清楚团队中哪些人愿意改变，而哪些人不愿意改变。了解原因。
• 寻找轻松的胜利。
• 使更改受到团队欢迎：找到他们的个人痛点并尝试帮助他们解决。