作为“最低开发商”与技术债务作斗争？

假设您在一家公司工作，而您所要做的就是为他们开发软件。您不了解总体情况，也可能不了解。您所拥有的是通过问题跟踪系统分配给您的任务。您得到了任务，使它们按照任务描述它们的方式工作，然后将其发回。像加2个整数：

function add(a,b){return a + b;}

但是后来，随着项目的进行，您注意到随着add变得越来越复杂，您意识到它应该需要某种形式的体系结构，而不仅仅是添加参数并返回值的函数。但是，您不知道。首先，他们所需要的就是这么简单add。您没想到add会变得如此复杂。

该项目具有更多功能，而您最初没有想到这些功能。最后，您将不断堆积各种技巧和功能，以免破坏/重写现有代码。

您如何处理这些情况？作为“最低开发商”，您如何应对技术债务？

澄清：

• 您是层次结构中最低的“实施者”。

• 您看到了问题，但对此没有发言权。

• 我不是在量化技术债务或寻找工具。

• 关于第三个“重复”

  • 重构和重写-您被锁定在任务上。您无需支付额外费用。
  • 体系结构概述-您了解整个系统，但不了解体系结构。
  • 代码冻结-不是您的电话。您不是管理者。
  • 模块化-不了解架构。模块随需求的变化而变化。
  • 自动化测试-不存在。

每次您发现类似问题时，请在问题跟踪系统中输入新的故障单。

养成习惯，使用问题跟踪程序作为沟通此类问题的主要工具，因为从那里开始，很容易为您的高级同事/负责人/经理/负责跟踪项目中问题的任何人进行选择，评估和确定优先级。

使用正确的工具完成工作。我会一直这样做，强烈建议您也这样做。

例如，这是我一个月前创建的票证。完成特定功能后，我发现代码变得比以前复杂得多，但是我无法在为功能实现指定的期限内解决此问题。

（真实跟踪器中使用的功能，票证和代码的名称被遮盖，但文本照原样复制）。

简介：简化涉及的设计ParticularPieceOfCode

描述：
在按照TICKET-12345实施的过程中，涉及使用的代码会ParticularPieceOfCode产生一些复杂性，并且变得相当难以阅读，理解和维护（请参见下面的示例代码片段）。

找到一种方法来简化它。

可以在以下位置找到重新设计的代码示例ClassName#methodName：

<a piece of code like one behind the right door here:>

FWIW我的建议与您所处的“级别”无关。

我一直在您当前（“最低”）的水平上使用它，现在我正在使用它，因为我的水平与“最低”水平相差很远，并且您说的话我的满意度很高，我将使用它总是不管。

试想一下，没有层次，无论您拥有多少权限，都没有更好的办法。

如果您“说” 嘿，我们有一个问题，那就只是空气不畅。即使您的老板/负责人同意并说您是对的，我们仍然有一个问题，这没有改变-只是空气再次发出嘎嘎声，别无其他。

• ^{您可能会认为写好您的发言（例如，以电子邮件形式）会更好，但是如果您想到了，那实际上不是。如果您的项目有大量的邮件活动，那么一个月后写的内容将会丢失并且会被长期遗忘。}

使用正确的工具完成工作。对于您描述的工作，问题跟踪器是正确的工具。

您注意到了这个问题，将其输入专为跟踪这些问题而设计的系统中，并且它会以最好的方式处理其余的问题-仅仅是因为它是为此目的而设计的：

计算机软件包，根据组织的需要来管理和维护问题列表...常用...创建，更新和解决报告的客户问题，甚至是该组织的其他员工报告的问题...问题跟踪该系统类似于“ 错误跟踪程序 ”，通常，一家软件公司会同时出售两者，并且某些错误跟踪程序可以用作问题跟踪系统，反之亦然。统一使用问题或bug跟踪系统被认为是“一个良好的软件团队的标志”之一，¹ ...

无论您希望选择其他哪种沟通方式，在Tracker中拥有票证只会让您更轻松。

即使您喜欢喧嚣，说“我想讨论TICKET-54321 ...”也比“听我想谈谈我之前处理过的一些代码”提供了更坚实的起点。 ...”，您可以安全地通过邮件将引用传递给票证：即使邮件丢失，问题也仍会存在于跟踪器中，其中包含您要讲述的所有详细信息。

是什么让我对您的情况感到不满意，正是您在标题中以及问题文本中多次写道的：

您是产业链中最低的开发商

为什么这一点如此重要？好吧，首先，从纯粹的技术角度来看，您当然是正确的。您被称为事物的“执行者”，即根据给出的命令进行操作的工蜂。

但是，即使您是排名最低的开发人员，这仍然不太正确。这里的关键是要意识到，您只是认为自己是最低的开发人员。您是否曾经尝试过克服这种自我认知并真正承担起某些事情的责任？

采取！不要等到有人让你负责任。

• 您看到了问题，但对此没有发言权。
• 我不是在量化技术债务或寻找工具。
• 您已锁定任务。您无需支付额外费用。
• 不是你的电话。您不是管理者。

通常情况恰恰相反：一旦您证明自己物有所值，您就会得到更高的报酬，并且您的意见也会受到尊重。这是“先做后拥有”，而不是相反。

我对团队成员的期望恰恰是：对我们正在尝试构建的项目或产品以及与该工作有关的所有流程的责任感。每当我们团队中的某人通过承担责任给我留下深刻印象时，例如提出改进建议，甚至更好地自己开始改进事情，这些人都会得到提升。

换句话说，没有人提倡工蜂，人们被动地等待分配给他们的任务，甚至缺乏“ 因为他们没有得到报酬 ”的最细微的主动性，最后抱怨说他们从来没有机会。

当然，所有这一切都取决于您公司的文化，这与乔尔在亚瑟（Arthur）链接的“两个故事”中所涉及的内容有关。如果公司经理真的很愚蠢，无法阻止自己的员工取得进步，那么波动率可能已经很高，现在应该从中得出结论了。但是，如果不是这种情况，真正的问题可能就在您自己内部。

你是专业人士。您的雇主雇用您成为专业人士。所以，把你的关注，你会希望专业人士以同样的方式，你聘请来治疗他们的专业意见。特别是，您希望其他专业人员在此过程中进行必要的优化和更正，前提是这些优化不会意外地增加成本。

例如，假设您带汽车去修理厂更换了灯。机械师注意四件事：

1. 通往灯泡的电线磨损且危险。但是，可以在不显着增加成本的情况下对其进行修整。您可能希望他花几分钟来修剪导线，甚至可能没有注意到它。
2. 螺栓松动。这完全无关，他只是偶然看到它。他花了20秒钟的时间来抓住必要的驾驶员并拧紧它。所以，你希望他能做到。
3. 灯泡的机箱破裂，这会导致灯泡发出嘎嘎声。更换很昂贵。这不是必需的。因此，他给您打电话询问-如果您说“不”，他会在您的访问摘要中提出书面建议。
4. 汽车下方有大量制动液。他应该并且甚至可能被要求是专业人士，以防止您使用汽车，直到您允许某人修复泄漏为止。

这些场景中的每一个（我敢肯定其他场景）在软件开发中都有相似之处-特别是如果您认为自己是任何级别的专业人员。作为专业人士，除了很少的例外，您的工作是根据您的专业知识以特定的方式达到改进产品的最终目标。

1. 如果修复程序很简单，不管是否无关，请进行修复。
2. 如果修复程序很简单且不必要，请使用您同意的任何正式沟通/问题跟踪机制提出正式建议。
3. 如果可以得出解决方案是完成主要任务所必需的，但会意外增加成本，请通知范围更改。
4. 如果发现的问题严重影响了项目的成功，请明确说明。正式地。如果出于道德上的考虑允许问题得以解决（例如在医疗，紧急情况或运输系统中），请坚持在产品出厂前解决问题（如果出于道德上的考虑，请通知媒体或当局）。

您这样做的方式就像律师事务所的职员打架不道德行为，快餐店工人打架不卫生行为或停车执法人员打败警察腐败一样。

1. 成为一个很好的例子。 在可能的范围内，生成清晰合理的代码。如果有选择，请选择一个可以减少缺点的满足您要求的选择。（请注意，技术债务与抵押债务不同-仅拥有债务不一定是一件坏事。）
2. 传达您的担忧。您应该由某个人（团队负责人，客户或架构师）负责管理技术债务和分配企业资源的实际责任。当您发现自己认为不好的东西时，请与他们沟通。如果您不确定他们是否会理解，响应并给予好评，请以书面形式（即电子邮件）。
3. 不要紧张 技术债务很少导致企业的雇佣终止失败。只要您已经传达了自己的疑虑并进行了工作，那么诸如技术债务之类的架构问题就根本不是您的问题。是的，它们可能会影响到您，但他们的担心不过是警长连任，这是初级警察的担心。

在您提供的示例中，该add功能经历了完全的特征蠕变，请花几分钟时间并草拟将其改进的轮廓。将其发送给需要批准才能实施的任何人，然后继续。

假设您的企业是由非常有能力的人员管理并且结构正确的，那么您的问题将被路由到正确的系统设计者处进行决策，或者您将有余地执行建议。作为初级开发人员，与技术债务相比，我更担心的是要了解企业的​​运作方式，而且如果您知道前者，则如何处理后者应该是显而易见的。

我从未听说过一个不希望员工参加的组织。你说你只付钱去做任务。我真诚地怀疑您心中有正确的任务。因为您支付编写优秀软件的报酬。

承担这个责任。如果您不支持该功能，则拒绝添加功能。用您的专业知识为客户提供建议。现在就刹车，在为时已晚之前，您必须放弃整个项目，因为它将不再可维护。