我负面的实习经历能代表现实世界吗？ [关闭]

#1 楼

他们将其称为Real World™是有原因的。

您在现实的企业世界中遇到的99％都将被视为废话，我有充分的理由解释。原来不被认为是垃圾的1％最终将成为垃圾。

＃1编写代码，＃2 ????，＃3利润！

首先存在业务为了赚钱，它们不存在以产生完美的理论上干净的设计和原始的学术代码，这些代码存储在完美的黄金存储库中。甚至还不紧密，甚至是销售他们所产生的源代码的企业。

在商业世界中，代码是达到目的的一种手段。如果某些代码解决了业务问题并赚到了比创建和维护所需的钱更多的钱，那么对于企业来说这是理想的。聘请您编写代码只是企业获取代码的一种方法。

理论0-实践∞

理想情况下，维护应该是一个更重要的问题，但通常不是这样。 t，因为在短期内它不会在经济上取得胜利。从长远来看，软件通常具有相对较短的生命周期，尤其是基于Web的应用程序，它们很快就会过时并且需要更频繁地重新编写。

企业内部的应用程序很受青睐。由于许多基于动量的原因而被视为无尽的僵尸计划。这些项目实际上是他们持续进行的成功，因为它们继续使企业获利。


理论上，理论与实践之间没有区别。在
练习中。 -Yogi Berra


从理论上讲，完美构建的绝对干净的原始代码库具有100％的代码覆盖率可以为公司节省资金，实际上，它甚至几乎无法交付任何与有效的投资回报。

软件生命周期的物理原理

在软件世界中，还有一个强大的熵力在起作用。这是不可避免的一个黑洞，它谴责所有软件退化为大泥巴。

从BBM开始越远越好，但是每个软件系统最终都将在足够的时间到达那里。接近100％熵的速度取决于您从何处开始，您累积技术债的速度以及对它的兴趣有多高。

软件系统由于维护而不是由于维护而退化和腐烂。缺乏它。一个已经存在多年且没有定义更改代码的系统可以满足其所有要求和目标，并且是成功的。

需要不断变化的系统是因为它们刚开始接近最大熵，所以不断地对其进行戳戳和推动，而维护工作则在加速负变化。

/>足够好就是足够好

诸如不断变化的网站之类的短生命周期系统无法从昂贵的庞大前期设计中受益，因为在单元测试中100％的代码覆盖率不足，因为摊销时间太短而无法弥补成本。

像上述内部业务应用程序这样的长生命周期系统，也不会真正受益于100％代码覆盖率单元测试的大量投资，因为整个生命周期内的变化率该项目以非线性方式接近一个接近于零的常数。

这就是为什么寿命终止计划更为重要，并且应该在发布某些东西时（而不是在发布时）计划替换系统的原因通过了数年的总理和不支持，所以一个新的系统我必须赶紧就位。

据我所知，他们没有教过BBM，我从未遇到过一位应届毕业生，知道这是什么，更不用说为什么发生了。

这就是为什么“足够好”就是“足够好”，或多或少都没有。

软件贫民窟

有房地产贫民窟的领主是有原因的，他们从自己拥有的破烂的棚屋中获利。所赚取的利润超过了对破旧财产进行增量维护所花费的资金。如果他们不这样做，他们将拆除建筑物并更换建筑物。但是他们没有，因为增加的成本远远不及检修或更换整个建筑物。还有一些顾客（租户）愿意为破旧的房产支付费用。

没有建筑物的所有者，贫民窟的主人或不愿意花钱购买房产，仅仅是因为一些学术上的完美概念不会转化为相关成本的可观利润。

没有客户愿意为可以接受的软件系统升级付费。没有任何企业会花钱在编写和重新编写代码上而没有明显的可观利润。

微软是最主要和最成功的软件公司。 Windows直到最近才开始进行主要的基础重写。而且他们仍然没有从内核中删除所有遗留代码。对他们来说这没有商业意义，人们更愿意接受他们在过去十年中设定的低期望值。

预后

我从事软件开发20多年的一种模式。它不会很快改变。这不是人们希望它脱离某种信念体系的方式，而是企业外部力量的现实。业务驱动决策，利润不是邪恶的，因为它们支付您的薪水，短期或长期愿景无关紧要，这是定义上不断变化的短期行业。任何反对足够好赚钱的人都不了解业务。

我花了15年的咨询时间，很快了解到，足够好就是，其他任何东西都花了我钱。是的，我希望一切都完美无缺，但是除非您出售的代码库（即在出售解决方案的99.99999％的时间中），否则所有完美的，有条理的完美代码都将丢失，并且您只是在浪费时间，就永远不会得到报销。

进步与希望

敏捷方法论至少在哲学上是朝正确方向迈出的重要一步。他们以头等公民的身份应对混乱和不断变化，并接受它。他们拒绝教条式的实践，承认方法和实践以及需求和技术都应该改变。

他们接受由于缺乏时间或不断变化的需求，不断变化的员工以及具有技术债务概念的软件系统而引入的熵。

但是敏捷不是万能药，它不会改变物理学的基本定律，无论如何代码库都会腐烂。在腐烂完全失控和难以控制之前，应由管理层计划如何应对。

正确完成敏捷后，有助于管理熵，减慢其速度，跟踪它，对其进行测量并以计划的方式进行处理。

职业决策

如果这对您来说是一个真正的哲学问题，您可能应该考虑其他职业选择，因为事情的运作方式是有效的它背后的商业价值。开源项目没有更好的跟踪记录，而且在许多情况下，这些代码甚至比我所见过的大多数公司代码还要糟糕。

#2 楼

我很好奇我目前的实习经历是否代表实际行业。


不，不是。它代表了您的职业水平和经验。这是从内部质量控制的角度了解企业运作方式的全部内容。


作为背景，我正在读一所主要大学的两个计算专业和一个数学专业的更好的部分;我上过每一堂课，并且都崇拜过他们，所以我想认为我并不擅长编程。我曾在一家主要的软件公司实习，直到现在一半，我对代码质量特别低感到震惊。


您的技能，经验和教育对他人所做的工作质量没有影响。仅仅是因为您无权更改这些做法。不论你在大学里的好坏都没关系。这并不会改变您所在公司目前的运营方式。因此，虽然很棒，但您具有所有这些背景。这实际上是为了您自己的利益，而不是他们的利益。这就是为什么研究自己喜欢的东西很重要的原因。

我曾在一家主要软件公司实习，直到现在，我对其中的低质量感到震惊。码。注释不存在，全是意大利面条式的代码，所有可能出错的内容甚至更糟。我已经做了大量的辅导/ TAing，所以我很习惯阅读错误的代码，但是我一直看到的主要行业产品都胜过所有这些。


我在多年编程中所学到的是，“代码质量”和“可接受代码”之间存在差异。事实是，有权限的人发现源代码处于可接受的状态，或者发现源代码不可接受但有必要。如果我们都可以清理参与的项目，那将是很好的选择。分配业务资源来完成这项工作通常不符合企业的利益或预算。在第二天太阳升起之前，可以进行逻辑上的争论，为什么这将是一件好事，但是当管理层确定当前状态为“可接受”时，则无能为力。这一切都与谁管理事情直接相关。他们要么珍视良好的内部质量，要么就不重视。您很清楚它的价值，因此当前的状况困扰着您。

您会发现在依赖内部质量控制的任何行业中此类问题的例子。从软件开发到制造。您需要学习将其视为问题而不是问题，而只是将其视为源代码的当前条件。就是这样，要花X分钟才能找到东西，要花X分钟要修理东西。

企业要么不在乎这多余的时间，要么找到了可以接受。


我每天工作10到12个小时，从不觉得自己无所事事，因为要花费大量时间来尝试找出未记录的API或确定某些API的行为（完全未记录）产品的其他部分。到目前为止，我每天都讨厌这份工作，而我非常想知道这是否是我一生中都想拥有的东西。


为什么可以接受您花大量时间在大学里学习一门学科，但是现在接受长时间的学习源代码是不可接受的吗？我确定雇主雇用您的原因是因为他们认为您可以处理。

让我给你一些建议。好的开发人员知道何时该向他们的跟随队友寻求帮助。不要以为答案总是在代码中。我只问了几个问题就节省了自己的时间。听起来好像您需要一些帮助以加快速度。

其次，我们不知道工作条件。在许多行业中，长时间工作是生活中不可或缺的事实。您需要自己解决，但我可以告诉您。讨厌工作绝不是好兆头。您应该处理这种感觉并扎根。抱歉，您觉得这种经历很消极。


我是不是在实习中吸了一根短草（薪水高得离谱，暗示这不是一个低素质的职位），或者这是什么？现实世界是什么样的？


你在学校的表现很好，但是现在你有一个实习机会，但现在做得不好。听起来您已经在现实世界中了。那是生活的一部分。问题是，您将如何处理？唯一重要的是我的朋友。我们无法告诉您该怎么办。您必须要下定决心。

我可以告诉您，您的年龄听起来比我拥有的任何机会都要好得多。在90年代，对我来说，生活是一场挣房租和寻找我的下一份合同的斗争。觉得自己很幸运。

评论

---

感谢您的见解！原谅我，如果我发牢骚或自以为是，我很清楚自己很幸运，仍然有很多东西需要学习。而且我想我做得很好（我可能会得到一份全职工作），我只是不知道这种经历是否应该说服我去其他地方看。感谢您对行业的了解！

–attemptAtAnonymity
2012年6月22日下午4:26

---

就像我父亲告诉我什么时候开始的。 “您永远不会停止寻找其他地方”。您应该始终与业内其他人建立联系。始终保持简历最新，并始终学习新的编程语言。像失业一样过着自己的生活，并且您将永远得到良好的就业。

–反应堆
2012年6月22日4:35

---

鉴于我现在有多喜欢，我看不到自己没有继续学习。很高兴听到那对我有帮助！

–attemptAtAnonymity
2012年6月22日4:39

---

+1表示“优秀的开发人员知道何时向其跟随的队友寻求帮助。”我在一家小公司工作，只有一个队友，他在编程经验方面对我来说还很初级，但是他经常会在我遇到问题的问题上很清楚。问！

–TecBrat
2012年6月22日上午11:02

---

@Jodrell更改“工作”代码是巨大的风险，“清理”是有良好意图的更改，但是通向善意的通往地狱的道路。很少有产品所有者/项目经理会同意仅出于更改的目的而进行更改，这会带来太多风险。

–user7519
2012年6月22日17:14

---

#3 楼

经过25年的发展和各种公司和行业，我可以说：
，这很普遍。
这就是为什么工程师的薪水通常很高，他们必须善于应付凌乱的大杂烩和仍然能够进行更改，同时抵制重构整个该死的事情的迫切愿望，并弄清楚它到底应该做什么。我在那里激起您的情感-对您遇到的代码有这种感觉是正常的！

您看到的代码通常会由不同的程序员以不同的方法和标准以及不同的方式经过无休止的迭代。命名约定等。

虽然发生的情况是$压力始终存在。长期以来，总是很想描述如何以及为什么更好的代码是唯一的方法，但是在很多工作中，短期的快速解决方案需要时间。只需一名工程师在短时间内破坏项目中的标准。一个非常优秀的经理需要知道如何防止这种情况并捍卫正确的方法（在合理可能的情况下）才能真正解决它。

可以肯定的是，“好的代码”一词也是如此主观有用。当然，这不受您的限制，您可以列出特定的原因/项目。但是其他人列出了他们认为很重要的不同项目和优先事项，甚至没有技术性的内容，因此这是主观的。

像德雷卡一样，这听起来令人沮丧，所以让我尝试更积极一点，因为肯定是这样的：-


有些组织，通常是技术成分最大的组织，它们在做正确的事情。
公司较新。 ..和代码...趋向于更清洁。意大利面条因时间和人而增长。
有些人会做TDD和BDD，而其他人不会。范围很大。
大约10年后，目前，整个技术基础发生了变化，因此那些留在行业中的人可能很难像新手那样努力。

最后，正如Anthony Blake指出的那样，总会有3个因素-时间，成本和质量。
我喜欢以下相关表达：“ pick 2”！

#4 楼

对此有很多意见，因为每个人的经历都不一样。

我遇到的大约一半的开发人员都是善意的，但能力中等。顶端有一群才华横溢的人，而底层则有一群正在尝试但基本上应该做些其他事情的人，因为他们没有真正做到这一点。不幸的是，还有一小组不称职的傻瓜，他们认为自己比其他所有人都聪明，通常在您面对时应该如何跟从他们。

在项目方面明智，我从事了很多工作，并立即被要求“照顾”一些已建立的项目，通常是企业在失去最后一个开发人员后才发现它真正需要的项目它。我通常会找到您上面概述的确切内容-未记录，过度设计的越野车意大利面条。有时我可以修复它，有时我只是重新开始。它甚至不需要是旧的代码，我已经在要求“帮助”的新项目中发现了这一点。

大多数公司将为实习生提供糟糕的工作，您必须对此感到振奋。有趣的事情是在您完成两件事之后出现的：1-证明自己和2-花一些时间从事除纠正别人的错误之外的事情。换句话说，您必须展现能力和主动性。

处理不良代码的真正诀窍是弄清楚什么是可挽救的，什么不是可挽救的。这来自经验和研究。

您的另一个职业选择是停止在老牌公司工作，而打算在初创公司工作。这样就不会再维护旧代码了，因此您将有机会帮助构建更好的东西。不利的一面是，交付到启动项目上的压力通常意味着在不应该使用快捷方式和hack的情况下。

程序员常常愿意承担技术债务，以便尽早或按时交付。不幸的是，这种技术债务的影响经常被开发人员和管理层掩盖，最小化，忽略或消除，直到为时已晚并且陷入麻烦为止。

如果听起来令人沮丧，对不起。我相信其他人可以做得更好。 :-)

#5 楼

这里有一些很好的答案，但是让我补充一下；

欢迎来到现实世界-不幸的是，这很常见。

请参见下图；
/>


使用公司软件，您只能选择2个或以上，并且必须牺牲一个。

您似乎已经发现，大多数企业界都追求速度和价格。

#6 楼

根据我5年以上的有限经验，并不能完全代表该行业。我会通过您的实习工作，并从经验中吸取尽可能多的教训。寻找标志和指示。例如，对于您的下一个职位，您无疑将必须进行一系列面试。这个过程是一条双向的道路，使您有机会体验一下公司。这非常重要，可能会导致您自己的幸福和福祉。

总而言之，找出故事的征兆；


谁在运行公司？它是单个经理，营销团队（如果需要的话，请远离），开发团队等。这个角度意味着您可能会或多或少地获得项目的杠杆作用，项目所花费的时间等。
技术欣赏？看一下管理层，主管和团队成员之间如何相处。我一直在接受采访，一旦技术负责人开始讲话，经理们就会做各种眉毛动作。之后，他们得知他们没有使用源代码控制-您无法足够快地向我展示这扇门。
企业目标？该公司是按照日常财务目标来日复一日地生活，还是有长期计划供您参与？软件开发通常需要几个月的时间，因此拥有一家具有精神分裂症性质的公司通常会导致软件混乱。
深入研究-在询问技术问题并查看人们是否洗牌时。源代码控制，文档控制，发布过程，错误报告，管理风格，条款与条件（T＆C）等。

学习和生活，并考虑下一个角色。拥有糟糕的经历并没有那么糟糕，因为您将更好地了解工作和商业领域。

#7 楼

好吧，我已经开始从事第二个十年了，我可以告诉你，很少有完美的干净代码发生，而且一旦发生，就不会长久保持下去。总的来说，您会发现自己不断地尝试修复过去的错误，而（由于时间限制和领导能力不佳而不得不）犯下现在的错误。

除非您身处其中作为一种非常特殊的软件业务，将功能产品推向市场的压力超过了所有其他方面的考虑，超出某个特定点的优化被认为是没有意义的。如果程序在5分钟内运行，而我们只需要在5分钟内运行，那么没人会给您几个星期的时间来将运行时间缩短到2分钟。

奇迹，您将拥有称职的管理人员，目标，金钱，才华和时间的完美融合，并且您将生产出清洁，优质的产品……唯一能够保持这种状态的方法是，您再也不会碰它。维护和扩展几乎总是被给予非常低的优先级，总是总是需要在零通知的情况下进行更改，并最终以不合理的方式造成混乱。

我昨天在考虑这个项目。对我来说，这真是一个显而易见的梦想，我从门上弹了一个功能极少的废话。我认为这是浪费时间和资源。

所有人都喜欢它，而且效果很好。所以我跳回了绘图板上，并正确地做了。而且新版本很棒！但是随后出现了管理人员流失，整个事务都被废弃了，转而支持“新的业务方向”。

第二次迭代在公司内部进行了一次半定的部署，我从没听说过其他事情，这很有趣，因为我知道至少有约10个业务部门仍在使用它（该软件我们正在委托进行这项工作，比原计划晚了将近2年），而且显然从未中断过。

这将我们带到了最后一点。即使您确实创造了奇迹，它运作良好的事实也意味着没有人会最不熟悉它，而当它崩溃时（通常是因为他们做了一些愚蠢的事情），那么他们会骂您的名字比他们差曾经骂过那个写每三星期二休息一次的白痴。

#8 楼

很难说出您认为糟糕的低质量代码是什么，但是，是的，很少有程序员非常出色（根据定义）。随着软件的发展，人们会犯错误。随着时间的流逝，这些累积起来，业务压力（以及程序员的懒惰/无知）使重构变得不常见了。

#9 楼

我会尝试用一个简单的引号来总结这个问题的答案：

All code turns to crap given enough time and hands.

其余的只是故事而已...

#10 楼

欢迎使用预算编写代码！当管理人员推动开发工作过早，没有计划，偷工减料时，存在很大的差异。当我从大学毕业后第一份编程工作时，我也经历过类似的现实世界的震惊。没有文档！随着时间的流逝，我学到了很多时间，编写和保持正式文档的最新状态只是浪费时间。对我来说幸运的是，这是一支很棒的团队。这是由一个知道自己在做什么的人领导的，其他团队成员真的很关心以正确的方式编写代码。从那时起，我的经历一直与您相似。许多可怕的代码，许多不良代码，无知的“开发者”。对于每个好的开发者，似乎都有100个不好的开发者。

你注定不会永远讨厌你的工作。您只需要找到一家足够聪明的公司来认识长期利益并愿意预先投资即可。我已经设法证明以正确的方式而不是最快的方式做事是有益的，并且在我所工作的公司中，我对此得到了高度尊重和信任。随着时间的流逝，通心粉代码变得固定或过时，您的代码将接管。只是准备妥协。有时，最酷或最鲁棒的编程方法只是过分的杀伤力，可以快速而又肮脏的方式进行编程。

#11 楼

不能真正地与所有人交谈，但这就是我能说的。

我在域名领域工作了30多年，但我看到的足以说几句话。一个项目的生命周期很像人类。经过20年的发展，最初的设计可能不能满足当前说一个项目的需求。就是说，在那么长的时间内，很多人更改了混乱的代码，并添加了最初不应该实现的功能。

很难想象遗留的丑陋代码项目或相当古老的项目。我们不能期望每个人都能完全理解初始设计。很可悲，但事实就是这样。

也就是说，您必须记住，重构遗留项目并不总是可能的，有时甚至是不希望的。我在一家公司工作，他们正在为我正在从事的项目开发替代产品。不允许我对项目进行过多的重构，因为担心它会比新项目更好。我敢肯定，这个项目不可能比新的项目更好。这个短语有点像“不要做得更好，就要做”。

最终，像我经常阅读和收听的那样，您通常不会有这种项目。您应该尝试与初创公司而不是大公司合作。初创公司非常有趣，如果您发现它并没有按照您想要的方式发展，那么您最终可以继续前进。

您也可以做一件事，我真的什么也没有保证，但是如果您觉得代码真的很糟糕并且需要重构。与团队分享。请记住，编写该丑陋代码的人可能正在与您一起工作。这不是在伤害人们的感觉，而是如果您看到正在处理的项目在一段时间后会崩溃，并且人们将花费更多的时间来了解它的作用而不是改善它。最好是大声说出来并传达问题，而不是亲自解决。如果足够幸运，您可能最终会重构项目。

如果最终重构项目，您可能最终会成为错误的设计选择所针对的人！然后您可能会理解为什么重构很少发生。希望如果整个团队都需要重构，那么没有人会指出。他们会解雇所有人=）

#12 楼

代码质量主要取决于两个因素。

首先总是钱。具有高生存压力的公司通常支付低工资，聘用经验不足的开发商，时间表紧迫，既没有时间也没有金钱来利用其开发商。

第二个人。首先，那些决定预算的人必须选择花在代码质量上的支出，然后他们必须吸引那些想要“实践”它的人。可以想象，将一个薪水高，五十岁，自上而下的Delphi程序员（无刻板印象，对不起）转换成负责CI构建和生产的最新Java开发人员可能很难松散耦合的代码。许多开发人员对（可能更年轻）研究员的课程感到反感，他们不喜欢有人在池塘里钓鱼-或在宝座上晃动。

这么说，并考虑到每个公司旁边都有遗留代码的事实，我想您会在现实生活中得到很多。您可以做的就像举一个童子军一样：走进树林，捡拾一些垃圾，清理干净。下次您将不再需要麻烦。

#13 楼

我在一家主要的软件公司实习过


并非所有公司都一样。在大多数公司中，您会发现糟糕的团队和糟糕的软件代码库。但是您也可以找到优秀的团队和出色的代码库。

我认为Solaris上的人员对大型公司中会发现的那种代码库做了很好而诚实的描述：http://hub.opensolaris.org/bin/view/ Community + Group + on / dev_solaris


到目前为止，我每天都离开工作，讨厌这份工作，而我
非常想知道这是什么东西
我的余生。


不，我已经编码超过15年了，但我仍然喜欢它。

那不是说一切都完美。我看过一些可怕的代码库，也有一些很棒的代码库。诀窍是为您找到合适的地方。

大公司与小公司大不相同。在同一家公司的团队A中，有时与团队B截然不同。找到一个对您而言具有适当平衡的人（例如，具有挑战性的项目，您喜欢的文化，高薪等）

好运！

#14 楼

您的消极经历是大型知名品牌公司的典型情况，与那些第一次有机会一起工作的人相比，许多开发人员学习时要更加谨慎和胆怯。基本上，您拥有的管理层越多，倡导的平庸程度就越高。中层经理不会向高级经理报告代码质量。他们报告了在X时间内交付的功能，并在neato UI功能上进行了简报演示，他们希望这些功能足够长的时间才能使它们通过。如果一个月后一切都崩溃了，那通常是别人的问题，他们知道。

所以，是的，在这样的地方生活的开发人员往往不太在意。如果他们做到了，他们将无法在那里生存。我听说硅谷说过，如果您想变得懒惰，那就为其中一位知名人士工作。如果您想要激动人心的工作，请寻找一家还不是家喻户晓的较新的创业公司。我在芝加哥工作，可以在这里证明类似的现象。

作为一般规则（我敢肯定会有很多例外），对于较小的公司，您会发现他们对质量代码有更高的评价并由仍继续编写代码的人管理或拥有。报酬通常较少，但我认为工作通常会带来更大的回报。

作为入门级开发人员，您起初不太可能对自己的工作对象有很多控制权但是我要说的是，在您的简历上拥有大名鼎鼎的一年或更长时间肯定会激发招聘人员和人力资源人员的兴趣。此外，您可以学到很多，否则您将无法学习，否则会在头六个月左右为完全糟糕的人工作，这还可以帮助您更好地掌握哪些最佳实践实际上很重要，以及为什么以及哪些只是技术时尚。

当然，当使用更多主流流行的公司工具时，您会趋向于发现中层人才水平将变得非常糟糕。如果您的主要技能是Java和C＃的某种结合，请稍微扩展一下自己的视野。在中级写作Erlang或Python或：o JavaScript时，您可能会发现一个更幸福的位置。

不要让任何人告诉您任何不同。在如何进行方面，您可能别无选择，但是废话代码很贵！@＃$ ing。

#15 楼

我见过和你相似的东西。我有两种情况发生的案例。



当开发太受项目驱动时。唯一重要的是按时交付功能，然后注销。下一个更改将由其他人，其他拥有新预算的团队/项目经理完成。
如果只有几个人长时间维护一个软件，开发人员往往会变得懒惰，因为他们仍然知道他们的软件。学术原则距离很远。

很可惜，但是在某些地方就是这样。

看看您是否可以做一些小的改变，习惯或改用另一家公司，要求在面试时筛选一些代码：-)

#16 楼

这将是一个简短的答案。

教育对于使您感到有资格和理想化非常有用。这是一件好事，您应该尝试坚持理想主义。

如果您完全有目标，并且将来可以回顾自己的工作，那将不会一个非常充实的体验。除非您对自己撒谎或没有学到任何东西，否则您将看到许多方法来改善自己的工作。

一般来说，全世界都会在您周围这样做。因此，当您回顾过去的工作时，除了例外情况，它会显示为次品并且需要即兴创作。如果您不喜欢这样，则意味着您做错了工作，或者工作做得太好了。

好消息是，您可以从别人的错误和与以往的比较中受益。如果所有应用程序都运行良好且易于维护，则不需要新开发人员。我认为，保留其他一些开发人员知识是一种有用的学习经验，应该是所有蓝天开发人员的必修课。

#17 楼

您的问题集中在实习上。我从来没有编程的人，但是在广播电台实习的，在这里并不适用。

您的问题还提到您在实习期间的经历。经过27年的写软件工作（从1985年6月中旬开始），您的实习经历和迄今收到的答案几乎可以概括我的经历。

我从不相信在学校的时候，我们的指导老师说比实际编写代码要思考的更多。他们是对的。而且，如果您试图弄清楚别人的代码，那么在没有注释的情况下会变得更糟，而在注释的情况下会变得同样糟糕。尝试维持一个没有注释，没有文档，没有正式构建以及没有源代码控制的本地市政税收系统。

只要您能在不直接违反标准订单的情况下做好，那就做好。永远记住，对您未要求许可的事情进行道歉比不被授予许可并违反直接命令要容易。

不要忘记教给您的标准在学校。它们并不是无用的，但是这些标准很有可能是微积分极限中的渐近线。您始终可以尝试接近它们，但是您可能永远无法达到它们的价值。

祝你好运。