我正在进行90％的维护和10％的开发，这正常吗？ [关闭]

#1 楼

在一次实习中，我发现我花了很多时间进行错误修复。您必须认识到，作为入门级员工，您不会获得最性感的工作，而您将获得别人都不想做的艰巨的工作。不幸的是，但这是每项工作的方式。从公司的角度来看，您更改现有结构浪费了金钱，因为它们要重做已完成的事情并可能引入更多错误。通常，这些类型的公司不是计算机/软件公司，因此没有足够高的管理人员具备一定的技术背景才能知道有时您需要进行这些大修。就是说，如果您的公司由技术精湛的人员经营，并且他们了解良好代码的价值，那么您可能会获得更多回旋余地，尽管有时您需要选择自己的选择（毕竟，企业的主要目的仍然是赚钱）。

那就是说，您希望能够在软件上留下自己的印记并希望进行更有意义的工作并非没有道理。同样不幸的是，您必须同时处理这么多项目，同时要处理来自许多不同经理的请求。

作为程序员，生活的事实是，与从头开始编写自己的代码相比，您将花费更多的时间来维护和修改其他人的代码。如果这对您来说是个问题，那么也许您应该坚持发展业余爱好并从事不同的职业。如果您可以维护代码，但是觉得自己没有被有效使用或不知所措，那么您需要与经理讨论。如果您的问题比那更严重，或者如果您的经理感觉不知道如何有效地管理您的技能，那么考虑在另一家公司找到职位将是一个好主意。考虑到您所说的低薪，这可能是您最好的选择。

#2 楼

听起来管理人员在管理工作量和确定任务优先级时遇到问题。您应该与您的经理交谈，并让他们了解您超负荷工作，并且如果每个人都不断用他们想要立即完成的请求轰炸您，那么您就无法做有效的工作。然后投射到另一个对象上，这浪费了很多时间在您脑海中切换齿轮。为了进行有效的软件开发工作，人们应该能够将自己投入到一项任务中，并全神贯注于此。中断越多，上下文切换浪费的时间就越多。研究表明，沉浸并达到我们的大脑最有效工作的流动状态大约需要15分钟。如果您每15分钟遇到一次中断，就永远不会流连忘返，这对您和公司都是巨大的浪费。这应该包括对传入的请求进行优先级排序，并在某种程度上提前进行计划。所有用户请求都应按优先级排序在列表中。而且优先级不应该由请求者决定（因为自然而然每个人都认为他/她的请求是地球上最重要的），也不是由您决定，而是由具有足够业务知识和对您所维护的整个产品概述的人来决定（产品所有者）。

理想情况下，所有传入请求都应输入到JIRA或Mantis之类的问题跟踪器中。或至少邮寄给产品所有者，而不是您。他/她还应该处理用户的所有抱怨，这些抱怨是“为什么我的请求还没有准备好？！”，使您可以专注于开发工作。如果无法做到这一点，则在查看传入请求并处理它们时，至少应协商一些时间窗，为开发留出不间断的时间。

如果可能的话，下一步可能是在某种程度上提前计划。也就是说，估算实现最高优先级请求所需的时间，然后将您的时间安排在sprint中，每个时间可能要花一个或多个星期，然后将足够的任务分配给下一个sprint以覆盖您的时间。

您可能希望保留一部分时间来处理紧急请求，但其余时间可以提前计划。您可能还希望将不同项目的工作组织成单独的“条纹”，即在星期一进行项目A，在星期二至星期三进行项目B，在星期四上午进行项目C，在下午进行D，等等，以便进一步减少上下文切换。

通过这种方式，您可以大致了解下一个或几周的工作。而且，这也为您的客户提供了一个路线图：他们可以看到何时获得实施的请求。您可能会或可能不想在这里向经理提及“敏捷”一词-这基本上是敏捷开发，但是有些人反对敏捷，而实际上并不知道它是什么：-)

请注意，即使您当前的职位似乎对公司而言价值不高，您维护的项目越多，您的谈判能力就越强。

寻找和培训新员工来维护所有这些项目，对公司来说要花费大量时间（=金钱）。您可能会正确地指出，您的代码比这些应用程序的遗留部分要好得多，因此不能以相同的金额轻松找到具有类似功能的候选人。更不用说如果他们不改善工作条件，他们会让下一个男人受够了，并像您一样快地退出。使您在哪里开心：-)这可以使您有能力谈判上述条件，和/或要求加薪。

您拥有多少谈判能力-这是一个大问题。您的管理层可能会或可能不会对这些想法持开放态度，并且可能会或可能不会足够尊重您以认真对待您的请求。但是，如果您打得很好，就有机会。如果他们拒绝...您总是可以寻找一个更好的工作场所。对于每个初学者来说，这种情况都不尽相同，尽管（可悲的是）您的经历很典型。但是确实有更好的工作场所。工作场所的质量与地理位置之间的关系并不紧密，但我的感觉是，在北欧，您的机会要高于平均水平。因此，如果您不能使当前的状况得到明显改善，则应该在完全受够了并精疲力尽之前立即开始寻找。有一个，因此您不必仅仅因为您立即需要钱就接受第一个报价。最终您会找到一个更好的地方:-)

#3 楼

附言我的薪水几乎等于甚至比超市的收银员的薪水还低。


我想写一些关于如何谈判的东西，直到读完为止。现在我只能说离开！假设这是拥有学位的开发人员通常收入的一半。假设情况有所改善，并且它们立即为您带来10％的增长，您就可以算出到达那里需要多长时间。看起来您在工作中什么也没学到，而且似乎也没有被出色的工程师所包围，所以这是在浪费时间。

#4 楼

我也处于类似的情况，我可以告诉你，如果您坚持这一步，它永远不会结束。管理层将继续为您服务，因为...他们可以。

我对此主题还有其他想法。


做自己喜欢的事。如果您不喜欢它，请做好准备，尝试发现自己可能喜欢的东西。
通信。清楚地传达您无法实现不切实际的期望的能力。根据我的类似经验，建筑师（铲铲工最多）说：“您必须管理其他人对您的期望。”如果您还没有倦怠感，请不要去吸引命运。它使您的生命和灵魂无法自拔。尽管尽了最大的努力，您的工作目标却变得灰暗，沉闷且毫无意义。我提供此建议是因为您必须不惜一切代价避免倦怠。
培训。这是一线希望。实际上，您的培训和经验虽然令人沮丧，甚至可能被低估，但对您的职业生涯却非常有价值。实现此目的是您的节省之选，因为您可以吸收尽可能多的知识，并延迟任何不可避免的玻璃天花板。

关注您正在发展的人才和技能...这些将带您度过职业的下一个机遇。

#5 楼

您正在这里处理多个问题...让我们从明显的内容开始...

这是正常现象吗？但是...这很常见吗？不幸的是，是的。

关于错误修复的挫败感

虽然这并不能为您要处理的其他麻烦以及它们使您超负荷的多个项目带来麻烦，我只是想简短地说明一下，“仅修正错误”的方法虽然使您对开发人员感到沮丧，但对于公司及其管理层来说却是一种非常明智的方法。错误和成本

您接触的代码越多，就越有可能引入错误，即使您打算改进它也是如此。这意味着将延长开发时间，测试时间和成本。而且，如果它进入到具有中等到高缺陷的服务版本，那对他们来说就是一个大麻烦。

日志中的噪声/雾

从SCM-从角度来看，如果您直接在服务版本的分支机构工作，这也很有意义，因为您希望对错误修正相关的更改有个清晰的了解。如果有15次提交，而实际上涉及一个错误修正的数千次更改可能需要更改1行代码，则这有点烦人。不要重构和/或增强软件，就我的观点而言，对您的错误修正尽可能“外科”是可以的。

您能做些什么吗？

现在，这并不意味着会有实现代码完整性和完整性的方法。所涉及的人们的思想。大三时，他们应该让某人检查您的更改，尤其是错误修正，并确保在将其应用于服务版本之前将其批准。这样可以防止或限制根本性的更改，并且更加安全。 >再次，魔鬼的拥护者在这里，但是只是表明您的初始请求包含一些无关紧要的比特。 。而且，在我偶尔这样做的情况下，它们是最近开始的项目或原型，而这些项目或原型是由出色的程序员启动的。但是，其中绝大多数惊人地看起来像胡扯，而其中可怕的是实际的胡扯。甚至是由优秀或优秀程序员开始的开发人员，最终都会被废话，截止日期和其他工作所吸引...

欢迎来到现实生活中的工业软件工程！知道有什么好玩的吗？在网络开发世界中，情况通常更糟。请享用！ :)

项目和请求太多，没有足够的手和时间

问题出在这里：



/>您的管理人员（可能在不知不觉中）虐待了您，

您的同事（可能在不知不觉中）在虐待您，

您的（也许是在不知不觉中）没有掩盖您的屁股并进行充分的战斗。

您的经理应该意识到您正在处理太多项目，无法管理。如果不是，请确保它们尽快。还请确保他们知道这不是公园里所有的挑剔问题，并且您感到压力很大，并且需要停下来。不能直接（通过说“ X能够解决这个问题”）或间接地（“我不是合适的人，找到其他人”）偏转您身上的更多任务和项目-最终成为您）。


这里的个人轶事：几年前，我进行了一次实习，就在我获得评估的最后一天，我的老板告诉我，尽管对我的整体工作非常满意，但其中一位经理感觉当他们本来希望我接他们的时候，就一直在另一个实习生身上卸下一些“不太有趣的任务”。当让他们感到失望时，我感到很生气，而当我的意图恰恰相反时，我似乎觉得自己在懈怠：我正试图抓住艰巨的任务，让另一个年轻的实习生减少头发-拉问题。我几乎没有意识到，如果我一直处于他的位置，我会因缺乏挑战而感到无聊，并且可能会感觉到他的方式。关键是，您需要进行交流以确保没有人对3个非常不同的事物做出错误的假设：




您可以做什么，

您想做什么，
以及您想做什么。

因此，让它成为这种方式也是您的部分错误。但这很正常，这是每个人都需要学习的课程。它用两个字母表示：N-O.

通常，您将它用作前缀，以获取更长但不那么费劲的答案：不，我不能这样做。不，我不知道该怎么做。不，我不确定我是否合适。不，我从来没有做过。

起初，很容易感觉到您可以说“是的，我会（最终）做到这一点”，然后把东西堆起来并拿来完成，也许要花一些额外的时间。这都是错误的。您需要了解，在您的技能之后，时间是您和公司最宝贵的资产。如果滥用，它将影响项目，截止日期和预算。就这么简单。

另外，您担心会有太多人要向其报告，这让人有些担心。可以与多个客户打交道，并且需要与多个项目所有者甚至主要利益相关者进行交流。但是，总的来说，尤其是当您是新员工时，您应该只向少数几个经理报告（很可能仅向您的直接经理报告，并且可能是主管或高级开发人员）。它是怎么得到的？我不知道。这可能是您公司的组织问题，也可能是您帮个忙，然后直接与您联系，而拒绝说“不”的结果。就我所知，也可能是您的直接经理遇到调度任务的问题（我确实在猜测，但是这种模式是可以识别的并且众所周知）。

我建议您这样做很快就可以做到以下几点：亲自去拜访您的直接经理，解释其他经理可能会有些急躁，或者（也许不太那么发牢骚）您
有太多的东西在堆积，而您需要他的输入（可能还有他们的输入）才能确定要优先处理的内容。

180度变更请求

这是另一个大问题。它们可能不是您的错，但是您可以尝试帮助他们解决问题。

精美而又准确地称呼它们为“ 180变更请求”，这清楚地表明需求是模糊的从一开始，没有人会尽力使它们随着时间的流逝而被清理和清理。

通常这是当有人需要打电话（或者更好的是，站起来）并抓住时利益相关者，并清楚地告诉他们：“那就是我们的身分，那就是您希望我们去的地方，您是否确定我们正在朝正确的方向前进？”。在一开始就没有明确的答案是可以的，但是时间越长，它们应该变得越清晰，或者这个项目正在等待灾难的发生。

通常，我会说要抓住所有利益相关者，将他们放在一个房间，引导他们解决诉讼问题，并逐步尝试解决这些问题-并在解决问题时获得优先考虑。但是，根据您的情况，这可能不是您的要求。但是您提到他们确实给了您项目的责任。因此，如果确实如此，那就要承担责任并做到这一点。并且不要回避说“我们不能那样做”，甚至“我们不会那样做”。限制项目的范围真的很重要。

如果没有范围，则讨论结束时没有明确的要求。

电子邮件超载

人们倾向于根据他们使用的通信介质来表现不同。就我个人而言，尽管我是一个很会说话的人（并且大部分时间都在国外工作，所以我最终也不想在电话上跟别人聊很多），但我还是喜欢基于生产率的优先顺序：



与人面对面交谈，
通过电话与人交谈，
通过IM与人交谈，
通过电子邮件与人们交谈。

电子邮件非常适合跟踪，获取确认，发送便笺。

用于安排，计划和讨论问题点，几乎没用。敲开他的门，直到他/她打开门，然后坐下来用记事本和您的文档副本进行澄清。完成后，请发送电子邮件并要求确认。如果返回否定答案或稍有隐藏的尝试在信封中偷偷摸摸的东西，请再次包围对话者的办公室。

这是软件工程。当您不用键盘敲打键盘时，通常可以提高工作效率，并且实际上可以减少您需要处理的废话。

使团队值得工作

您是否在做相当于团队的工作？也许。

您是否正在完成与团队工作相当的工作？

我的意思是，您的团队可能正在忙于工作，而您却过度劳累。这就是问题所在：您无所适从应该从当前项目时间表中推出的东西，或者交给有时间的人。


我是白痴吗？最初预期的情况会有所不同？


否；刚参加聚会。就像是第一次宿醉或恋爱。您会克服它的。 />
这对于混乱组织中的每个开发人员都是相同的，无论是初创公司还是成熟的巨头，都没有经验或信心让事情发生一点变化，以提示您生存的机会在右边秤。


PS我的薪水几乎等于甚至比超市的收银员的薪水还低。


我为似乎很烂的工作提供了不错的薪水。计数不是支票上的数字，而是上下文。您的工作，年龄，居住和工作的地方等...

话虽如此，如果您的收入严重不足，工作过多且不完全是初中生，请要求加薪或找到新工作！

很简单：


如果他们重视您的工作，他们会很乐意同意加薪，如果他们不会，这家公司的前途看起来并不乐观（至少对您来说这很重要），所以不要为离开感到难过。

请注意，要求加薪是一件好事，即使一开始您都不会这样认为。它可以证明您跟踪自己的工作，并暗示您在仍然愿意留在船上的同时关注其他选择。习惯于要求他们是一件好事，因为它们就像工作面试或讨价还价的一般：这是需要练习的东西，而且如果您自己无法达到要求，它们也不会从天而降。一些公司会在没有要求的情况下定期分发加薪，但这仅仅是因为他们足够聪明，知道它使您半满为乐，不愿改变，并且他们想在您脚下割草（大多数人会感觉到对于直接提出要加薪的提议有些不安。）

如何处理此请求超出了此项目的范围，因此在此我不做介绍细节。但是我建议您准备一个记录，记录您的SCM提交ID，已解决的错误和成就，并准备与团队的整体工作进行比较的报告。这样：



您可以自己衡量自己是否有效地做得比同龄人更多，

您可以立足如果他们说您的要求不合理。

#6 楼

除了其他人的评论：


是的，为入门级员工提供其他人不想做的工作是正常的。
您应该将其视为

那么，你应该怎么做？为了证明自己是一名专业的开发人员，您需要确保工作的结构和计划是合理的，否则您可能会发现很难以当前正在做的事情为基础-因此，您应该尝试执行以下操作（如果您还没有）。


准确记录每个项目的工作。因此，如果您花一个小时来修复项目A上的错误，请记录此时间。如果您想讨论工作量，这对向经理显示很有用。
编写单元测试。您提到您维护的某些项目中充满了错误，因此我猜测几乎没有（如果有的话）单元测试。对于每个错误报告，编写一个复制该错误的单元测试，然后修复该错误。这将有助于确保不会发生退化，提高代码质量，并在有机会的情况下充当重构代码的平台（例如，它可以帮助您说服利益相关者相信重写某些部分可以改善
寻找新工作-您一次处理多个项目，从头开始编写代码，并且可能经历了整个项目生命周期-这些都是在其他地方应用的好经验。

#7 楼

您的情况有点前卫，但仍然很正常。但是您处理它的方式非常糟糕。这是您需要做的：


尝试与老板面对。您应该有一些证据（数字）来证明不良代码库实际花费了多少时间。如果他不了解技术债务之类的内容，请停止提及。这会伤到你的头，你可能会被标记为“态度不好”的家伙。教老板做工作不是你的工作。
维护自己的待办事项（看板）。当出现新任务时，将其结束，并告知完成时间。
增加您的响应时间，每天检查电子邮件两次。通常在午餐前和就在您离开之前。 （检查电子邮件后不应进行编码，因为这可能会伤脑筋。）
在每个任务中都要进行少量代码改进。改善您正在使用的代码，技能和工具只是您的工作。从长远来看，它也会提高你的道德。
白天没有项目切换。今天，您仅在项目X上工作，明天将在Y上执行其他任务。这意味着琐碎的小任务。如果此任务花费的时间超过10分钟（原因无所谓），它将进入待办事项列表，并且您通知经理，它将被延迟。当前，经理之间并不相互交流，只是假设您将以最大的优先级完成他们自己的项目。这会给您带来很大的压力，因为您处于争论的中间。您需要迫使经理开始协调您的工作。最后，您应该有一个不错且简单的待办事项列表，经理们应该在没有您的情况下互相欺负。

所以让我们做一些简单的角色扮演。有三个经理和项目（Xavier和X项目，Yvonne和Y项目，Zed和Z项目）。您有2周的积压订单，X为5天，Y为5天。


Z要求您完成某项任务（1天）
您回答说它将在11天内完成。
Z回答说这是一项简单的任务，不应花费超过一天的时间（注意Z施加了很小的压力）。之后工作。
Z回答您无论如何都应立即执行他的任务（压力增加，直接侵犯X和Y领土）。
您回答说，执行她的任务会延迟X和Y的工作。他应该先问他们。您也可以使用CC X和Y。会议...您应该离开，让获胜者为您分配任务。
什么都不会发生，Z将在两天后问您他的任务在哪里。您回答您当前正在为X工作，而他没有提及有关项目Z的任何内容。再次CCX。但是您的情况是不可持续的，无论如何您可能很快就会退出。仅当经理相互竞争时（通常），此解决方案才有效。您还应该保留工作记录（积压），以防有人抱怨您懈怠。

#8 楼

七年前，我做了一段时间几乎100％的维护工作，并写了一篇关于它的文章：维护编程的艺术。您可能会发现其中有用的一部分：


开始喜欢它

任何人都喜欢维护编程吗？开发人员梦想着成为团队的首席架构师，而当他们最终维护现有软件时，感觉就像是一种惩罚。不必一定是：维护程序设计有其自身的挑战，并且需要很多创造力，适应性，耐心，纪律和良好的沟通。这也可能对您的职业生涯有好处：简历中包含“ Architected n-tier 24/7 enterprise application”等惊人的条目看起来不错，但雇主实际上很重视解决问题的人员；和维护编程可能是证明您解决问题的技能的好机会。

#9 楼

您的问题听起来像是您经常听到的某事。看来，这项工作很容易适合“每日WTF”。

许多组织更注重销售或功能推销，而不是质量。那些公司看不到的是，软件不仅具有外部质量。 Ward Cunningham创造了“技术债务”一词。

您可能还想读一下Steve McConnell的技术债务。他有一些有趣的观点。在Google Tech Talk中，Ken Swaber讨论了敏捷软件开发。很大一部分是关于一个与您相似的故事。他谈到了一个软件项目，该项目在经过各种程序员的10年编程之后，一直没有做任何重构就变成了“脑袋死”。我认为，如果您看到此视频，将会发现与您描述的内容有很多相似之处。

任何软件系统在进行扩展时都会降低质量。实际上为了征求意见，必须这样做。雷曼法则很好地解释了这一原理。最终它将归结为以下问题：“如何说服老板进行重构？”。

我如何处理类似的问题：


我遇到了老板，并解释说，随着我们的不断发展，代码质量会下降（雷曼法则）。
我试图向老板解释技术债务的概念。而且他让您工作的方式从长远来看会花费他的钱。
为了真正向他展示问题的严重性，我（用自己的时间）做了一个静态代码分析。老板不懂软件，但是他们懂数字。尽管代码指标有其缺陷，但最好还是有一些可以衡量的话题。尝试找出这些指标的正常读数，将其与自己的代码库进行比较时，您会感到惊讶。
如果没有任何帮助且没有任何变化，那么您唯一能做的就是说明某种新功能将需要对代码库的其他部分进行一些修改。解释一下，如果您有重复的代码，并且他们想更改某些东西，那么更改的成本也将重复。 “也许”这种返工是多余的。您将不得不解释，软件将始终必须进行更改。就像雷曼法律所说的那样；它必须进行更改才能继续使用。如果没有，其他进行过更改的程序将永远失效。那些期待改变并能够适应改变的人才能生存。这就是敏捷软件开发的全部内容。 （维基百科）

如今，我的老板使用技术债务的概念向客户解释说，有时我们需要对所构建软件的某些部分进行返工。只是为了证明-如果您有一个合理的老板，就有可能改头换面。

#10 楼

对于许多新生来说，您所面对的情况几乎（即使不是完全一样）。

这发生在职业的最初阶段。这里有个要点：我们必须克服这个问题，并向公司（无论是中型还是跨国公司）证明我们的价值。我们应该能够根据情况需要我们做决定。因此，只要您为工作付出努力并以个人身份工作就可以了。如果您物有所值，该公司将予以通知！ Adios，祝您好运。

#11 楼

我认为，禁止重构的公司不值得工作。重构是必不可少的软件开发技能，而版本控制工具使隔离开发非常容易，而又不会破坏“主干”（以防重构确实破坏了某些东西）。正如鲍勃叔叔所说的（释义）：“您不应该要求成为专业人士并做好自己的工作。”

#12 楼

我是五年前收到我一位朋友的来信的。 />
老板：“你知道辞职的意思吗？”

实习生：“是的，我愿意”

老板：“让我让你明白通过与辞职相比较来进行评估是什么？”

Email body:    

受训者：“是的，老板，我现在已经了解了我的未来。要进行评估，我必须辞职.. 。!!!“

#13 楼

如果您是我，我会在下班后花一些时间免费重建应用程序。这可能是一个有趣的任务。完成后，向老板展示。如果它有效并且您正在对其进行维护，那么他就不必担心。这将使您的工作变得更加轻松，并使更高层次的人才可以看到您在公司中的潜力。

我是一名全职大学生，以每小时10美元的价格从事兼职实习。我所做的质量检查工作很无聊，重复且容易。我认为自己非常幸运，因为我知道有一天这将为更大更好的地方敞开大门。

#14 楼

是的，您将始终必须维护由您和其他人编写的应用程序。唯一的例外是，如果您编写的程序永远不需要任何维护。因此，您最好擅长维护。

我认为您的方法存在缺陷，这有一个微妙的暗示。也就是说，修复错误不涉及改进代码。


但是后来我得知我不能改进现有代码
，只在报告错误时才专注于错误修复。


我不敢相信有人告诉您“您必须在不改进代码的情况下修复错误”。这既困难又不可能。您不能做的就是仅仅因为您不喜欢或很难理解现有代码库中使用的方法而重新编写应用程序。

我的建议是学习重构。每当您修复错误时，就有机会至少改进一些代码。重构多少代码库取决于错误是什么以及代码的好坏。但是，如果您要修复错误并故意在各处散布代码的味道，那么您就没有做自己的工作，并且正在积淀技术债。

实际上仅通过重构就可以修复一些错误，有时重构对于帮助您理解代码很有用。这是因为重构应该改善代码的可维护性和一致性。

当我估计一个错误修复程序时，我通常会决定是否进行大型重构是实现此目标的最佳方法，并对此加以考虑。单元测试也一样。这两件事都应该是您编写代码的一部分，而不应是涉及额外时间的可选内容。

因此，您不应该问“修复错误后是否可以改进代码？”因为你还是应该。您不应该问“我可以使用重构来修复该错误吗？”因为如果迫切需要重构导致应用程序错误的代码，则无论如何都应该这样做。您不应该问“修复此错误后可以编写单元测试吗？”因为您甚至应该在尝试修复错误之前就编写回归测试。

NB：我觉得这个答案应该归功于杰夫·阿特伍德（Jeff Atwood），因为我链接了他的3篇文章。

#15 楼

这全是关于金钱的。我的猜测是，作为一个入门者，对于那些已经获得了超出其支付能力的客户，您可能会太客气了。

了解为新要求报价的价格。这远非易事，客户经常会尝试您。如果可以的话，请寻求经验丰富的项目/产品经理的帮助。如果您当前的客户提供全职资金，则不应选择新项目。但是您会理解，管理层仍然会尽力欺负您。

如果您确实对公司有价值，那么您将获得议价能力。您可以要求他们雇用更多的人，获得更少的新项目，帮助您减少维护工作量或增加薪水。

#16 楼

如果禁止您改进现有法规，则不应该由您的雇主决定对您进行微观管理。使用您自己的专业判断。当您估计工作量时，如果将来会提高生产率，我会考虑额外的时间来进行一些重构。


您有证据表明重构可以节省成本。起草一个重构项目的提案，并演示该业务可以节省多少时间和金钱。精确地概述您将对代码进行哪些更改以及需要多长时间。如果您不按计划进行，这将为您提供保护。
慢下来。这似乎有点反直觉，但只有快速进行所有操作，您的时间才会被浪费。如果您少做事，人们会更加尊重您的时间。例如，我每天只检查一次或两次电子邮件。否则，您可能会精疲力尽。
考虑到您的工资水平，不值得头疼。确保您每天准时离开。不要在没有额外补偿的情况下加班。唯一的例外是，如果有不错的晋升选择，或者公司的声誉会大大提高您的履历，那么您只需要吸纳这份履历即可。您尝试与经理保持更加开放的态度。也许开始增加您的任务估计。不断提醒他们您的工作量有多忙。另外，您应该与老板会面，并说明您希望在未来六个月内增加薪水，并询问如何改善业绩以实现这种加薪。

祝你好运。

#17 楼

以我的经验，学术界或以技术为导向的初创公司的头6到12个月是仅有的两个可靠的领域，您会遇到真正的空白。它们都有自己的成本，但是如果您喜欢编码，并且经常被野外发现的代码质量吓倒，则应该开始将职业指向这些方向之一。

#18 楼

尝试与您的雇主交谈，看看是否可以解决此问题。听起来您对此事束手无策，并且与成为一名糟糕的程序员没有关系。

较小的网络公司往往会同时进行许多项目，从很多方面来说，这都使您处于困境。尽量利用自己的情况，或者如果可以的话，尝试寻找新工作。我保证那里会有更好的编码工作，所以请不要让第一个吓到你。

个人经历

像这里的许多人一样，我也承认您的情况。我基本上是第一个低薪的编码工作，并且不得不维护很多结构较差的内置代码。起初，我发现学习新知识很有趣，但是当我最终要维护很多项目，要制作新项目以及白板的规模越来越大时，我每天都没做完，我意识到

忍了两年之后，我辞职了，几个月后又找到了另一个编码工作，非常适合我。

无论如何，很多时候，可能不仅仅是问题所在。当我得到工作的认可和尊重时，我发现自己在工作场所更舒适。您所处的情况的问题在于，您的雇主可能只注意到由创建的项目引起的错误，而不是您花费时间来消除所有其他错误。 >
如果您想要更多的钱，通常可以得到。我设法在不到两年的时间内将我的薪水谈判提高了33％。如果他们负担不起您所赚取的薪水，那么公司要么需要查看他们的支出，要么意识到他们的业务无法正常运转。

正如在这里许多人提到的那样，我同意，您是公司难题中非常宝贵的一部分。地狱，你可能是唯一可以解决这个难题的人。 :)

#19 楼

由于我是该Stack Exchange网站上的潜伏者而无法发表评论，因此我将仅添加此处的信息。除非您去过像Microsoft，Amazon之类的大公司工作，否则它不会很出色。但这不应该是杂货店员工！不要长期忍受，获取经验做自己的事情，并在出现更好的机会时继续前进。
对于入门级演出，这很正常。您的工作量太高，但是工作类型是预期的。要成为更好的开发人员，您必须学习别人的错误。您看到的越多，您就会变得越好。但这意味着您正在寻找可以学习的东西，而不是学习不良习惯...
维护与项目工作的比例应随时间而变化。如果不是，那意味着您所在的公司没有意识到如何留住优秀的开发人员。他们打算让您日复一日地做同样的事情。为自己设定一个年度目标，明智地安排自己的薪水和工作期望，并相应地行动。生命太短暂了，无法与愚蠢的人打交道。

祝一切顺利。

#20 楼

您开始使用问题跟踪程序来跟踪待办事项列表。

这不仅可以帮助您跟踪关键问题，而且可以帮助用户和老板了解当前情况。工作量是。

此外，如果他们再雇用第二个开发人员（或者您退出并且现在的替代品会占用您的工作量），这将有助于管理工作量，并且您可以避免逐步在彼此的脚趾上。

#21 楼

打破这种链条的唯一方法是开发新的基础架构，这些基础架构的设计旨在提高灵活性，并经过完整的单元+集成测试。 1：1会议中的概念），那么您就可以慢慢达到一种状态，其中大多数应用程序的代码都在基础结构中，并且易于扩展和维护，而实际的应用程序重量轻且可以很快地编写。

基础结构的发展可能使得首先替换现有应用程序的一部分，然后过一会儿（可能要花几年时间）替换整个应用程序。

从长远来看它可以大大减少新应用程序的开发时间，并大大减少未来现有应用程序的维护时间。

新开发将需要至少80％的奉献精神（最好是更多的奉献精神），并且要有一个以上的开发人员（几个头脑胜过一个）。所有开发人员都将需要能够创造性地思考并打破现有的先入之见。 />
根据您的工作条件，要求领导一个新的基础架构团队来处理这些问题（基于您的定义和设计），并请新的开发人员维护旧的东西，同时在必要时为您提供帮助（向上）到10％到20％的时间。）
如果管理层同意这个想法，您可以要求重新谈判您的条款。如果他们拒绝，请准备寻找另一份工作。 （请记住，您的工作需要技能，知识和经验，要像您付给他们的信任一样，您不那么容易被替换。）

#22 楼

您的经理是否了解所有这些变更请求（维护请求）？他（她）是否意识到您的时间已经花在了您无权批准的请求上呢？还是您只是在经理问您时才进行更改？没有人应该直接来找你。问题应该通过这样的领域来解决-通常是一个支持团队。通常，您会在较短的交接期内（通常是一周左右）来支持代码。在任何将自己归类为“中等规模”的公司中，更改都应计入成本并收取费用（转移费用），而且这似乎已被绕过（难怪它们会淹没您-您就像舞会上的荡妇）。

应该有适当的请求程序来提出问题和更改请求。支持/维护是关于修正错误和问题（符合原始规范，但由于代码中的错误或外部事件（例如，断电或上游系统损坏等）而失败）。

如果您的公司不提供任何服务，并且希望您应对无数的随机请求并对此负责，那么您就必须认真考虑。薪水总是最差的-在我的第一份编程工作中（差不多25年前），我在同一家公司工作了8年，薪水涨幅很小（尽管它总是比收银员高得多！）。离职后的两年内，我的收入翻了一番-两年后，我的收入是我开始时的十倍（但后来成为独立承包商）。与往常一样，赢得马刺，学习贸易并跳船到温暖的环境。

#23 楼

也许您可以去找经理说：“看，我会很坦率的告诉我。我的薪水太差了，在X担任入门级程序员，我的薪水是N倍。 br />我要对A，B和C做太多事情，我无法维持这一点。老实说，也没有冒犯我的意图，我要带着固定的辞职书或辞职书走出这个房间。剩下的一封信。现在这一切都已经浮空了，我们如何才能共同努力实现这一目标？”

#24 楼

答案是尝试用可以理解的术语对其进行解释；


就像换油一样。它们不是紧急的。...但是必须定期进行操作
在锈上涂漆，它看起来很棒。直到流血通过
，在不加强支撑的情况下建造新的屋顶露台屋顶桌。它可能会工作一段时间。然后它将崩溃并伤害人们，您将承担责任。
a / c很棒。一个窗户单元适合一两个房间。试图在一栋公寓楼中放置146扇窗式空调，您将遇到问题。
教5个孩子很好。 10还不错。但是有限制。尝试非正式地教75个孩子，您会看到的。

如果这些没有引起共鸣。离开-写作的当天，而不是第二天！拥有新工作后，请零通知离开。从字面上看就是那天不来。但是，请确保您有一个或两个知道您的工作的同事。如果可以帮助公司，这实际上可以通过向他们表明他们的不尊重和傲慢是有代价的来帮助公司。上一家公司，我在6个月内就进入了四项技术三项殊荣，没有工作可去。它至少发表了一个声明，并给离任者一次很好的机会，说：“是的，很高兴您每天都说，但是您已经很忙了，我什至没有让您满意我的通知。

最后，一定要知道，这件事是NORM和20年前的标准，然后敏捷，tdd，bdd和重构才成为标准。您可能正在与高级人员交谈，他们会立即做出反应：“好吧，我自己做了，这很好，等等，等等，等等。”好吧，肯定的马车在150年前就运转良好。在技​​术领域，20年前的技术与150年前的运输一样过时。如果他们拒绝这项罚款。只需知道，他们将永远不会聘用任何会留下来的体面的现有技术开发人员。他们会遇到最坏的情况，这将严重损害他们的业务。如果他们依赖技术并且无法适应，那么它们将失败，最终这可能是您的最佳回报。只是功能不健全的组织可以持续很长时间，这可能需要一段时间。

#25 楼

听起来您的管理层从根本上不尊重您或不了解您的工作负担。

您不应该实现所有通过的功能请求。您的经理应该充当您和传入请求之间的缓冲（也许最简单的中断/修复请求除外）。然后，他或她应与您坐下来，确定所有批准的请求的可行性和优先级。

另外，您应该赚到他们所付钱的2倍左右（至少）。您，但是用他们付给您的钱听起来不太可能。您想在团队的某个地方工作，并且管理层可以与您一起完成项目。尽快下沉那颗沉船。

成为一个团队中的英雄只会使你筋疲力尽。

#26 楼

我只是一个学生（仍然），但这很正常（根据我的实习经验）。这就是在支持和Web应用程序中工作时得到的。

我建议您在开始编码之前了解客户（经理）的需求。这可能很棘手，因为有时他们自己不知道，所以与他们一起工作直到他们达成共识。在编写最终解决方案之前，请确保双方都同意。

此外，如果您是维护者，则可以在代码中进行几乎任何更改-只要确保它不会更改行为或引入错误。我希望经理们不会“允许”您进行任何更改，因为他们已经习惯了并且对现在的状况感到满意，并且他们不想为任何新的更改付费。

最后，不要担心是否因为做其他事情而无法处理某些事情。我建议您让人们知道您不堪重负，他们的要求将需要时间。如果您不这样做，经理只会认为您很懒。让他们知道您已经在工作，他们可能会雇用更多的人。他们没有其他方法可以知道一个人的工作量太大。

#27 楼

这是一个项目管理问题。使用某种项目管理来决定要处理的最高优先事项。

a）您需要积压的工作项。您将改进代码的计划放在了待办事项列表中。

b）所有错误都在待办事项列表中

c）待办事项列表具有优先级。

d）您可以按优先级顺序进行所有操作。

很可能会优先考虑错误。但是，一旦修复了所有问题，您就有时间花在新功能或重构设计上。 br />
如果您只是逐步进行改进重构，那将是最简单的方法，因为您可以跳过存在问题/错误要修复的部分。然后您可以告诉管理层：“我必须修复A，但是B基本上被破坏了，我必须执行解决方案C来解决所有问题，以便将来D变得更容易/更便宜”。其中A =错误，B =反模式，C =解决方案，D =未来收益

如果您不能将工作证明为值得进行的投资，那么商人永远不会接受。

#28 楼

这和往常一样。只要您继续在那里工作，您就会被剥削。继续使用此模型，而不是让您对自己的工作感到满意，符合公司的最大利益。归根结底，他们并不在乎。这是关于为他们创建可靠的代码，如果您是单人乐队，那么他们肯定会帮助您。他们为什么会改变？

好消息是，即使他们不知道，您还是他们的VIP。我建议要做的是在跳船之前排队更多的机会，然后抓住机会，要求更高的薪水。如果不能再寻求更好的机会。我认为，您应该很快就能找到更多激动人心的工作。力求最高。进入开发人员商店后，您会更快乐，例如Google或一些有趣的创业公司，那里有协作的开发人员文化，您会真正感到高兴。猎人承包商组织，并迅速在我的管理下获得了许多很棒的经验，从一个转移到另一个，同时仍然保持承包商的稳定工作。它可以防止您感到无聊和挑战。最终，在业余时间，我建立了一些小公司，后来发展为实际业务，然后我从从事合同工作的工作中跳了出来。