您如何判断高级开发人员的建议是否不好？ [关闭]

#1 楼

首先，作为一名高级开发人员，我希望我领导的项目初级人员能够直接直接地将他们的疑虑带给我。如果他们不同意，那对我来说完全可以。在某些情况下，我会针对他们的关注采取行动。在大多数情况下，他们的担忧被抛在一边，并简短地解释了原因，并不是出于对开发人员本人的不敬，而是由于其他一些原因，例如：


大三学生手头上没有所有信息来了解决策。在某些情况下，进行一些简短的解释可以帮助开发人员摆脱关注点并解决不理想的情况。
大三学生拥有BAD信息。实际上，请不要忘记您是大三学生。就软件而言，这相当于十几岁。我相信您有很多很棒的主意，但是您可能一无所知。我发现最有抵抗力的初级开发人员是那些坚信他们知道什么对代码，公司和整个世界最好的开发人员。谦虚会更好地为这些开发人员提供服务。
决定以某种特殊的方式来做事情是在年长者的头上做出的。最后，长者还是为别人工作。实际上，可能存在做某事的更好方法，写某事的更有效方法，或者有更好的软件/硬件来帮助完成任务。但是，企业仍然在驱动决策。业务经理，董事，副总裁等经常做出影响开发过程的决策。这些都是高级管理者无法控制的，当初级管理者抱怨时，他们所做的只是增加了高级管理人员的压力。
刚出手的长者没有时间考虑到这一点。有期限，有时在中途更改模式，实践和行为对于该期限而言代价高昂。由于在砧板上是他的脖子，因此与“完美书写”相比，使产品正常运行和按时交货通常更为重要。

这些只是我能想到的事情。有很多原因导致某个想法，实践或概念可能被比您高的人拒绝或丢弃。他们中的许多人都令人不快，但都归结为我们都是人类，我们都有意见的事实。目前，他的观点恰好在您的观点上要优于您。

考虑到这些概念，您应该继续将您的疑虑带给高级开发人员。寻找另一位能够填补空白的高级开发人员。许多高级开发人员处在他们所处的位置，因为与软件相比，与人相比，他们会更好。他们之所以在某些地方，是因为他们知道当实习生时要吻谁的屁股。寻找一个真正了解指导某人并获得其诚实意见的人。他们可能会不同意您的意见，并填写您没有的空白。他们可能会同意您的意见，并帮助您团结事业或改善局势。

任何时候都不要进行任何暴动。即使您内心相信自己的方法是对的，也已得到了要遵循的指示，并且应该遵循该指示（除非明显地这是非法的）。如果您在遵循这些说明时遇到问题，则可能要尝试找出原因，因为您将发现这种行为模式在许多生产任何类型软件的公司中都非常普遍。

最好的选择是继续道德和专业地做您的工作。以模范的方式获取要求您完成的软件，并通过升级退出该软件。如果没有晋升，您将获得大量的参考和经验，可以在其他部门或公司中寻求机会。

#2 楼

尊重高级开发人员。与您相比，他对项目成功的追求更高。由于他有责任，因此他也获得了权力。如果他说改变某事，那就去做。

话虽如此，当您遇到已经存在的问题时，请毫不犹豫地提出您的担忧。

最后，和他一起坐下来，向他解释与您在此处发布的相同问题。也许您错过了什么大事，也许他会为您的建议提供更多机会，无论哪种方式，如果您认为他的建议很差，请不要让他处于黑暗之中。

#3 楼

发生这种情况时，您需要与高级开发人员进行对话。也许他知道您对代码或技术/业务要求不了解。如果是这样，您应该学习它。

请秘密进行。可以将其视为具有挑战性的权威，最好将这些事情一对一地完成。表现出愿意承认和尊重他的资历，做出让步和合作的意愿，但要坚持不懈地回答您的问题。从协作框架而不是好斗的框架来处理情况。您可能会考虑请他指导您。

最终，您必须与他平衡自己的想法（公平地说，这是相对较新且未经检验的）。也许您确实是对的，但是您应该尽力向经验丰富的人学习，以便做出更明智的决定。优秀的高级开发人员欢迎与初级开发人员合作，指导和学习的机会，并欢迎以建设性的方式挑战他们的想法，因为他们也知道有时他们是错的。

#4 楼

您经常说的是通过常识方法。请记住，高级开发人员可能对项目有更多的了解，但对做事的正确方法可能并不了解。您必须衡量他告诉您的操作-如果他说的话面对他的优胜者声称的话（即比他高的人；不一定在您的公司中……），他给您不好的建议。著名的“名人”开发人员，他们经常发布或撰写有关进行软件开发的正确方法，或者至少是业界认可的最佳实践的书籍）。

这是“坏建议”的一个示例来自高级开发人员（或任何开发人员）的信息：如果他们完全不了解松耦合是什么以及为什么这样做是一件好事，并且被告知要在其中编写所有代码（例如，ASPX文件的代码隐藏），那就是显然，高级开发人员很笨拙，不应听取他的建议。

另一方面，如果他告诉您系统中特定模块的工作方式，那么通常最好再听一次，只要他告诉您不要吐唾沫。正确的开发原则。

这是我的经验法则：公司的高级开发人员可能只是任期最长的开发人员；他可能没有任何实际技能。他说的话是否与您所在领域的一些最受尊敬的开发人员所说的相悖（那些经验比他丰富得多的人，而且他们更有才能和受人尊敬）？如果他是他，除非有非常极端的情况，否则他的建议很不好。

对于极端偏见的观点，人们完全希望票数不符/分歧。

#5 楼

可能很难理解高级开发人员的优势，是的，他可能会把事情引向错误的方向，但是，对于大型项目，一致性更为重要。

有50个所有遵循自己的编码风格，标准，方法和设计模式的开发人员都将陷入混乱。如果事情做错了，那么始终如一地犯错总是比许多不同类型的错误和某些正确的事情要好。

进行维护，添加功能或修复问题时如果“错误”，那么如果预先知道现有设计中的问题就容易得多。

尊重您的意见是件好事，但最终最好还是排在前面。团队中流氓的任何人都不会被视为团队成员。

#6 楼

如果上级不能给您充分的理由说明他们为何忽略行业最佳实践，那么不要在这里浪费时间。您永远都不会前进，因为您太过威胁了，无论如何，您是否想花时间维护一堆不良代码？

大多数开发人员在离开大学后都会停止阅读。您还没有，所以您已经进入了前10％。这些天有很多机会。如果您所在的城镇没有就业市场，请寻找一个更好的城镇。

#7 楼

哇，这是一个绝佳的机会，让您发光并炫耀自己的技能。在我职业生涯的早期，我的上级主管无法做出任何决定，因此我无法利用这个机会来学习如何进行更高层次的工作。它让我升职了。您应该做同样的事情。

#8 楼

作为高级开发人员，这种被动的主动挑剔行为会让我发疯，而在面对之后，您会带我给您不好的评价。完美的解决方案是团队可以共同生活的解决方案。

至于风格，这应由您的风格指南和由您的来历决定的最佳实践决定。如果您充满激情，请为它辩护，但是一旦做出决定并在团队中与您一起工作，您就可以继续工作。

#9 楼

您的处境不太好，但是正如HLGEM指出的那样，您可以将这些职位化为祸福。您的问题是多方面的，因此我将分部分进行讨论。


我怀疑，他不知道。同时，他试图向我展示
骄傲自大，这样我就不会问他太多问题了。


这很可能是对的。从开发或指导的角度来看，已经从事该行业数十年而又没有强大的软件开发人员的开发人员大为不同（存在差异）。经验来自应对新挑战，尝试新想法和学习新技能，但是大多数程序员将自己的一生都花在了公司办公室的一角，用他们忠实的Visual Basic和Java工具来开发薪资应用程序，却从未见过如此激烈的竞争。他们那冷淡的灰色办公室。

这没什么错。对于许多开发人员而言，这是他们所想要的，并且完全适合这种情况-但是，这不是培养下一代程序员的理想情况，更不用说领导开发人员了。

Bravado和傲慢可以成为一种防御机制，试图弥补不足之处。您如何处理？不要直面它-如果您的领导能力不强，而老板不愿纠正这种情况，那么您将不得不忍受它。这并不意味着翻身而死，但您不能强迫某人成为一个好的领导。


但是，他只是查看我的代码，而他的大部分评论都是
与编码准则有关


这就是让我认为您是对的，因为他可能不是一个好的程序员。这并不是说他目前没有比您更好的程序员（至少他会在这个行业工作这么长时间会拥有更多的经验和经验），但是，这并不能转化为成为一名程序员。有效的线索。准则虽然很好，但是仅次于代码的功能，有效性和效率。


在这种情况下我该怎么办？

我已将这种情况告知了我的经理，我已经请他
改变我的领导，尽管他每次都说“是”，但他不采取任何严肃的行动。


您是否已向经理列举了所有这些具体要点，并提供了具体示例来对其进行支持？如果您只是去找他说：“我需要一个新的线索”，那么他不会认真对待您，并将其视为“人际问题”，而不是技术问题。在这种情况下，许多老板的反应是忽略它，希望它可以“解决”。

这里有一些建议。



不要为自己的情况而烦恼-试火虽然不好玩，但会教给您一些关键的研究技能，供您在职业生涯后期使用。
开始推动领导更多地参与进来。请认真，尊重地执行此操作。继续努力并持之以恒，直到他屈服为止（这实际上在生活中的许多情况下都是有效的）。
如果您的领导不会介入，请看看是否有其他人可以帮助您。除非您在只关心挤奶时间的血汗工厂工作，否则您的公司不会介意具有更多经验的其他开发人员向您展示一些绳索并审查您的代码。
开始关注新的工作。我并不是说您处于“必须离开”的境地，但是在一个更加重视程序员发展的地方，这不会损害您的职业。

#10 楼

如果您有解决特定问题的更好方法，那就去做吧。

让您的代码/解决方案成为您的最佳选择。否则，请按照您所告诉的内容进行操作。

案例要点



当我还是大三的时候，我遇到了
特定部分
代码不是最好的。
我不仅仅是对它进行辩论，还只是对其进行了改进，然后向我的上级展示了
结果。他接受了，
因为代码始终是国王。

#11 楼

当然，作为一个没有经验的开发人员，我可能会错了，他的
方法可能会更好，所以我的问题是
我该怎么做才能更好地判断是否
资深的开发人员建议是好的还是不好的/过时的建议。


您可以成为经验丰富的开发人员。除非您这样做，否则您将无法判断您的初中直觉是否正确，那么那时就没有关系了。

同时阅读乔尔·埃瑟顿（Joel Etherton）的著作回答。

#12 楼

我强烈建议不要尝试“不按自己的方式实施”。

到目前为止，听起来您做对了。你很谦虚，提出了一个反对意见。从您的问题中我无法断定您是只是不同意他的方法，还是不同意并提出了替代方案。但最重要的是，当您尝试击落他人的方法时，始终要提供一个清晰且经过深思熟虑的选择。正如他可能看到的那样，您有一个可行的好主意，而他有一个可行的主意。

在任何位置，我们总是被迫做次优的事情。如果您真的不喜欢它，那么您可以照做并提出来。之后，是老板的路还是高速公路。从好的方面来说，您可以避免大三学生做出错误决定的风险。

#13 楼

选择战斗。如果您要花一个小时的时间，那么您将不得不不时更改代码，直到您逐步完成。下次您遇到大型项目时，请提前询问是否有机会在开始之前介绍您的想法。投入一些额外的时间，制作出惊人的演示或原型。

#14 楼

我所做的令人震惊的是，只是停止询问。当有其他选择的时候，我只是离开了，按照自己的方式做，但是增加了自己的天赋。将它作为学习经验来培养您的能力，并仍然满足他或她保持老派的需要。

最后，并不是每个高级开发人员都关注新的工作方式。他们有时采用古老的教学方式，这对他们20年前开始使用的语言非常有用，但被认为是骇人听闻的，或在当今世界“闻起来很臭”。

这听起来像是一种可怕的继续前进的方式，而且确实如此。但是我也从我的前辈那里学到了很多东西。但这实际上只是我的意见。最后，您必须对自己的工作感到满意，并将注意力和紧张情绪保持在较低水平。通过不反对，您会发现压力下降了。

#15 楼

不要因为年长而信任老人。尽可能多地挑战权威。主管当局应能够令人信服地回答任何问题。这就是首先使他具有权威性的原因，不是吗？

因为某人一生都有迷信的信念并不意味着他是对的。请记住，在中世纪，人们认为地球是平坦的，其中一些自以为是的驴子甚至有理由杀死怀疑者。原来，怀疑者是对的。差评太多了。

不要害怕不好的评价。你会相信一个盲人判断肤色吗？

#16 楼

上面的好答案会补充说，“最佳实践”或“更易于维护”之类的回答是学习知识的机会。您说：“您能举个例子说明为什么这种方式是最好的，这样我才能理解其中的区别吗？”或“在什么情况下这种方式比其他方式更易于维护，因此我可以学会像那样提前计划？”

如果上级是正确的，举个例子将很容易。如果他是一只鹦鹉...给他一个饼干来阻止南瓜，然后做你认为最好的事情。除非另有命令。

如果长者的角色是指导，他将在被问到时解释原因。

#17 楼

正如HLGEM和Jarrod之前所说，这确实是变相的祝福。他们的答案都很好，我想补充一点。

由于您的领导者不在您的域中，因此您需要对应用程序部分做出一些重要的决定，因为您的领导者对中间件并不了解。您还将与经理保持联系，以了解应用程序的运行方式，产品用户的需求以及经理将如何解决产品团队向他提出的情况。告诉我有多少人将在应用程序上获得这种知识。

当您在一个大团队中时，您肯定会从您的队友和/或您的领导那里获得帮助，但是您将不了解经理的想法或产品团队的想法，因为这种事情通常会经过您的领导，并且可能是团队中的一些高级开发人员。
我同意一个人的项目很难携带，但是如果硬币的另一面如此之大，为什么要错过机会。学习您可以学到的东西，在可能的情况下享受乐趣，如果遇到困难，请像Jarrod所说的那样说服您的经理，或者根据情况找到新的工作/项目。

#18 楼

您将在整个职业生涯中都与这样的人打交道。在许多编码问题上，您将与许多人不同意最佳方法。我认为多年来对我有用的最好的事情是，如果他们不断强调一个问题，请与他们保持联系，并告诉他们您已经在各种可能的解决方案中考虑了他们的解决方案，并且您认为该解决方案在这种情况下，您认为这是最好的方法。

现在，如果您每次都反对他们的建议，那么有时您可能需要不时屈服并使用他们的“建议”，以抚平一些皱褶的羽毛。只要他们不觉得您每次都拒绝他们的意见，那将对保持你们之间的和平大有帮助。

还请考虑他们是高级开发人员，并且拥有在该环境中工作的时间比您更长。现实生活中的编码通常与最佳实践或社区公认的标准不符。他们可能建议您以某种方式进行某些操作，以致他们无法充分表达自己的观点。因此，即使您不同意他们的意见，也请确保不要仅仅基于您认为自己的解决方案更好的事实就忽略了他们的建议。

这一切都与平衡有关。不只是编码平衡，还有团队平衡。许多项目失败的原因不是因为开发人员没有能力，而是因为他们找不到友好地合作的方法。

#19 楼

我想从我的个人经验中提供一些东西，这些东西应该被视为jzd在此处发布的内容的补充答案。


问另一个高级开发人员，
自己做研究。

在一次专业约会中，我应该由一位资深的老师指导。他知道一些东西，但说实话还不多，不幸的是他不知道，所以他对自己的答案非常有信心。我莫名其妙地觉得他的话是错误的。当他所做的事情与我所采取的MS认证中提到的最佳实践不符时，我有一些证据：-)。之后，我开始询问其他公司的其他人员（当时stackexchange尚未启动并开始运行），并开始阅读博客以比较答案。

如果我错了，那太好了，因为我只是改变自己的行为，但事实并非如此。

#20 楼

在过去的几年中，我注意到了一些事情，几乎我所从事的每个公司，我从事的每个项目，几乎每个新员工（无论技能/经验水平如何）都希望做点“与众不同”的事情。 />
可能是编码标准或总体体系结构或语言或方法。但这总是东西。很多时候，这只是在说明一个显而易见的事实：“对于我们的最终用户而言，是否应该对所有内容进行更好的记录？”

我对您的建议不是那个人。

有朝一日，您将成为一名受雇并付钱做出这些决定的高级人。那天到了，去吧！直到那一天，意识到你的位置是什么。我有一个老板，就我而言，我的整个工作就是让老板高兴。这不是第二次猜测我的薪水等级以外做出的决定。如果您不确定，请与您的老板/主管交谈并找出答案。

虽然总的来说，让每个人都采用过时的方法要好于采用过时的方法的团队的一半，采用某些新方法的团队的1/4和采用新方法的团队的1/4更好。团队试图开发一种尖端的全新方法。

#21 楼

我认为所有这些潜伏着的东西都应该明确指出：不要好斗。保持与他的关系。接受他的建议，并在诸如此类的书籍和网站上进行验证非常好，但不要攻击他。如果他是一名高级开发人员并且经历过许多项目，那么他不是白痴，还有很多可以向他学习的东西。看起来您已经完成了，表达了理解他的观点的愿望。即使您确定他错了并且您是对的，也要接受相反的可能性（似乎您已经了解了这一点）。试着弄清楚你在吵架是因为你想更好地理解他的观点，而不是因为你试图证明他是错的。

如果他不马上回到你身边您问他一个问题，或者如果他的回答含糊和/或无益，请不要以为他让您失望。正如这里已经提到的，他可能很忙和/或感到压力。

耐心也很高兴。在您的脑海中列出一些您认为应该做不同的事情，并在适当的时候提出。除了“这是最佳实践”之外，请确保您对该建议有正当理由。并且要小心行事，不要犯任何错误，这样以后当您提出观点时，您就具有信誉。

#22 楼

到目前为止，我一直在尝试通过倾听他的观点来提出
问题，提出一个
反对点，然后他再次提出他原来的
观点（大多数时候他会
说最好的做法，更易于维护
，但没有走得更远），我...
在家里考虑一下，但是...我仍然不相信
。但是最近他...看到我的代码并问我
为什么我没有将其更改为他的
建议。这是
2--3周中的第三次。


（对动作进行了轻微编辑。）

这部分与我有关。判断自己是否正确的一种方法是理解他在说什么。我读到的内容（根据我自己的历史，其他人可能会有所不同）是一个初级开发人员，不了解指导者在说什么，也不要求澄清。您能弄清楚的一种方法是请他澄清：这比这更好吗？还是为什么这比我们的代码更具可维护性？如果您不知道他的答案，那么您真的不知道他是否提供了很好的建议。

让我真正担心的部分是，他要求您多次更改它，而你还没有。从他的角度来看，这是一种可能的方式：他要求您进行更改，您问为什么，他给您（在他看来有效）的原因，而您拒绝进行更改。您不需要澄清，因此他假设您了解原因，并且太懒惰或太顽固而无法更改-对于高级开发人员来说，考虑您并不是一件好事。相信我，问问题比以这种方式获得声誉要好得多。

#23 楼

一些想法：

1 /是否有效？
他在工作吗？是他的方式会逊色的客观原因吗？

出于客观原因，我的意思是可以衡量而没有歧义（性能，错误，代码长度...）。如果他的解决方案有效并且没有客观指标表明这是一个糟糕的解决方案，按他的方式去做。他的方法更好……因为它可能与代码库的其余部分更加一致，并且使他更容易使用/重用您的工作。您可能不喜欢它，但这不是它的意思，是吗？

如果它不起作用，或者在重要指标上表现不佳，请实施它，将其解决方案与您的解决方案进行比较，然后告诉他您已经尝试了他的方法，但是无法使其表现良好（给出指标）并询问他是否在实现中犯了错误，或者是否有您不知道的要求

2 /明星程序员说...
为什么要该死？您会发现著名的程序员在许多基本主题上彼此矛盾，例如规划，设计，OOP与过程，单元测试，异常处理，源代码控制等等。

如果两个解决方案之间的唯一可操作性差异是谁喜欢它，请跳过它。通过不喜欢的范例进行工作，您可能会从所需的心理锻炼中受益

#24 楼

基于您只应向想要成为别人的人征求意见的想法，答案是，如果您想成为他/她，高级建议是好的。

#25 楼

我解决的大多数问题都是通过发布到论坛上并得到其他人的答复来进行的，
我已经生存了大约一年了。
在这种情况下我该怎么办？

老实说，这就是很多技术工作的样子。您需要成为一个自我启动者，如果需要的话，可以自己解决难题（在互联网及其居民的帮助下）。
从获得代码审查和获得体系结构设计帮助的角度来看，即使我有好的管理人员，除了“静态变量应以s_开头”之外，我从来没有进行过太多的代码审查。
抓住机会学习和学习如何学习；这些将是您将来可以使用的技能。

#26 楼

如果您一秒钟认为管理层不了解您真正有能力完成工作，那么您可能是错误的。管理层也可能知道，如果他接替您并接管您的工作，那么您现在的领导将是完全无用的。

他们没有调动您的真正原因是，尽管您面临所有挑战对他们来说，您仍然是最合适的人选。他们显然很珍惜您的工作，以至于冒着将其移交给其他人的风险。

别低估了管理层的智慧...

它们比大多数开发人员所提供的要聪明得多。他们相信。直到开始管理，我才明白这一点。他们可能也知道您的潜在客户实际上是多么无用，但他们可能无能为力。解决这个问题。

让我为您描绘一幅，在公司工作5年的Lead A并不称职。经理知道这一点，建议他的上司裁员A。上司问他，如果他这么不称职，为什么几年前没有与他打交道。经理现在看起来很糟糕，尤其是因为线索A的薪水过高，却没有任何报酬...

这是另一种潜在的情况，线索A与重要人物是密友。无论从哪方面来看，他在政治上都太热情了，

无论如何，长期存在错误，例如大型组织更容易将不称职的人扫下地毯，给他们忙碌的工作和虚假的权力适合他们无法承受太大伤害的“经验”年限。不幸的是，许多组织宁愿这样做，然后才真正解决问题。

当然，原因是这种组织的经理总是最好在短期内处理不良人才。而不是解决这类人可能给组织带来的长期问题。

因此，尽管它是短视的并且可能不道德，但您必须承认，它比许多开发人员实际认为的要聪明。

#27 楼

啊啊。这个问题使我想起了很多事情。首先，我要说的是我无法与上一个工作场所的一位经理相处。这不是人格问题。这是一个沟通问题。我说XYZ和那个特定的经理会打断我所说的ABC。除非我与该经理一起工作了一年以上，否则我将无法很好地沟通。

这个过去的周末。一个人就单身人士与我争论/不同意。我说它们不好，永远不要使用，绝对没有理由使用它们。我将他链接到http://www.gmannickg.com/?p=24，并在文章论证后的几天内将其链接至更深入的文章。另一位程序员（DudeB）提到他只在合适的时候使用单例（我在“ never”中添加了单例）。 DudeB没说什么，但是DudeB确实说DudeB在一个有内存争用的项目中，因为所有线程都在访问单例。在提到这一点之后，展示文章并提到与我争辩的那个人所说的内存争夺，我们必须同意不同意我同意的观点，因为我不喜欢谈论单例（但我正在写这篇d'oh）。

要点是。有时您可能会像这个家伙一样犯错（也许有人会在评论中对我单身人士持异议）。在我的经理（我的高级程序员）的情况下，我只是做了明确要求我做的事情，而且我再也没有认真对待那个工作场所的质量。当允许时，我确实做了我喜欢做的事情，但总是按照要求做，但是如果我不同意，我会至少提起一次。

#28 楼

我对此有完全不同/有争议的看法。

人们常常不了解最终目标，对于大多数行业而言，最终目标是实现利润最大化和损失最小化。我知道这听起来很无情（因此有缺点），但是如果您不打算取得成果，那么经验和睿智就无关紧要。

人们可能会陷入极其间接的细微事情中，对此qui之以鼻对公司的直接结果影响很小。

如果您认为某件事是对的，那么最好的选择就是展示如何产生更好的可测量结果。

#29 楼

最初，我会尝试坚持下去，直到一天结束时，对长者的抵抗至少在您获得更多经验和尊重之前可能是徒劳的。以此作为学习经验，如果您仍然有相同的想法，请在2年以上的时间内-转到另一家公司。那是您可以结合使用您的和上司的好主意来打动新雇主的时候。当然，您可能会在职业生涯的早期阶段就开始意识到一些错误决定的原因，并且有时您可能会有初级开发人员为您工作。

#30 楼

[转贴：因为我不知何故在这里创建了第二个帐户]


但是最近，他再次与我联系，看到了我的代码，并问我为什么不将其更改为他的建议。


您应该清楚这些是建议还是命令/指令/指令/其他内容。

建议=我认为这样做最好；但这是您的选择。

订购/等。我想这样做；这是我的选择。

如果这确实是一个建议，请按照您的意愿做，让您的代码站起来。如果是命令（并且此导师以这种方式对您具有控制权），请按照他们的意愿进行操作。