在走向失败的项目中，我应该如何表现为开发人员？

#1 楼

在管理阶梯上以最简洁，最无对抗的方式传达您的担忧。总结风险，但不要强加于此。

管理部门必须始终可以选择做什么，但是评估和传达情况是您的工作。使用电子邮件，以便在事情向南走时留下纸迹。不知道有关该项目，其支持者以及背后的财务决策的所有信息。对您来说似乎愚蠢的管理决策实际上可能基于您看不见的智能推理。

#2 楼

保持书面记录（例如日记，保存的电子邮件等）。仅包括事实和客观观察。将所有结论留给任何人（如果有的话）阅读您写的内容。

作为开发人员，如果您不被视为阻碍该项目的障碍，那么您很可能会从中脱颖而出毫无疑问，这种指责会发生。您的经理可能没有那么幸运，但这在这里并不重要。

仅根据一般原则，更新简历，并确保您偶尔会见公司以外的其他开发人员。如果您不属于任何本地开发人员组，请加入2或3。花数年的时间建立朋友和熟人的网络，但从长远来看，这是值得的。请确保将其视为一条2条路-如果您可以帮助有能力的人填补公司的空缺，那和帮助您找到工作的人一样好。

#3 楼

我建议您花一点时间阅读2本书。

死亡三月是一本规范的书，描述了在软件开发中广泛使用的病理项目管理风格。由于计划压缩，功能过大或管理不善，许多项目最终都处于不良状态。它有助于了解您并不孤单，您的项目并不是唯一的死亡之路。作者Edward Yourdon将死角项目分为四个象限，每个象限都有不同的应对策略。有时，唯一的应对策略是走开。我认为这本书将帮助您弄清楚选择的范围，并缩小可以做什么和不能做什么。



为项目经理编写了更多内容，介绍了Disatanglement。它旨在弄清楚如何对一个破碎的项目进行分类：需要削减哪些内容，可以削减哪些内容以及如何向客户推销？ “常规”软件项目管理将我们带入混乱的项目，而我们也不会一开始就陷入同样的​​想法来逃避问题。这本书比《死神》更难读，但在书架上却是一本好书。

#4 楼

维持职业/理智的3种简单而愤世嫉俗的策略。


看到正在制造的火车残骸-下车：失败的项目会令员工士气低落，除非您具有忍者的向上管理技能将对您的职业产生负面影响。如果您看到任何软着陆，请立即跳转。
如果这样行不通，请保持警惕：人们将开始寻找要怪的人-别为他们感到轻松！尽管升级管理链上的担忧可能是正确的做法，但这既无效又冒险。您自己的经理不太可能将您的疑虑移交给他/她，这不仅会使你们俩看起来都不好，而且可能给您打上“麻烦制造者”的烙印，即首先应归咎于破坏项目的人等当然，这也意味着要专业，要花很多时间，但要不要冒任何英雄。
计划在T + 1紧急出口：给自己一些选择，为潜在的内部或外部转移做基础。与人交谈；当项目资金减少时，没有理由等待其他人决定如何处理您，或者在几个月内不可避免地被“移民”所淹没的人被淹没。

道歉，如果听起来听起来太愤世嫉俗，但是如果您正确地称呼它，那么您就不会感到不愉快。要专业，要乐观，但要切合实际。

#5 楼

这个即将失败的项目将对您在公司内外的职业产生什么影响？以我的经验，仅仅与成功的项目相关联并不能说明您个人的卓越成就。

您在逆境中表现出的特质，有时甚至是确定的失败，常常会被注意到上级人士比您想像的更多。而且，我所谈论的不仅仅是您的直属上司。

我个人经历过，我的直属上司因无能而被解雇，然后在同一天被提升为自己的职位。不愉快，但是它表明人们在看着我，喜欢我所做的事情。

通常，失败的项目会带来同样的混乱和混乱，为您提供闪耀的机会。

这样看待这个项目：这个失败的项目给我带来了什么机会，让我的所有长处和最好的素质焕发光芒？我从这次经历中学到了什么教训，这将使我成为一个更好的专业人士和一个更好的人？

本质上，从失败中汲取的经验总能推动真正的成功。 />注意：托马斯·欧文斯（Thomas Owens）问，一个人在这样的项目中可以做些什么。我有一些一般性建议，在这些情况下，这些建议已用作个人指导。它会帮助遇险项目奇迹般地成功吗？否-但是，我发现它帮助我对事物保持了正确的看法，尽管处境不佳，但也取得了个人成功。代码，符合更高的质量和功能标准。

2）关注个人指标-您编写多少代码会产生后续错误？将该比例降低到尽可能低的水平。当被要求为分配给您的任务提供估计时，您通常是准确的，还是您发现时间轴缓冲过多/不足？在实际分配任务时，您是否提供有关工作进度的良好反馈，包括提前和及时通知交付时间表问题？

3）关注团队指标-这些只是让我头顶上有些事情：其他团队成员是否因为对您正在执行的任务的依赖而落后？您是否擅长将任务/子任务委派或分配给团队中的其他人？您是否发现与团队中的一个或多个成员沟通困难？我致力于定期改进的所有领域。

#6 楼

在这种情况下，作为梯子的最低梯级，您只能做很多事情来帮助项目。


确保您的工作一尘不染
帮助找出最大的问题领域
尝试提供答案，而不仅仅是问题。看起来像是您要修复它们。

除此之外，您确实需要照看编号1。所有电子邮件，IM对话
尝试并找到一种可能的方法，脱离项目

#7 楼

失败的项目可能会损害灵魂，导致沮丧，过度工作和自卑。

这都是与观点有关的。

我曾从事过可怕的项目，而坐在另一个每天对他微笑的家伙的对面。哦，我想怎么打他脸上的笑容。他们享受自己的贡献，他们的任务，并在自己的兴趣范围内合作。而其他人则对当前的事物状态产生强烈的负面反应。这完全取决于我们对日常工作的预期期望。

您可能正在做自己喜欢的一些工作。当前项目中显然有您不喜欢的元素。

您需要确定那些问题所在，并加以解决。

截止压力
质量控制
专业精神
>管理层的指导

有很多团队和公司认为上述发展方面并不重要。我发现他们经常想到以下几点。

截止日期压力被认为是激励人们的一种方式。
质量付出更多，回报极限。
专业精神适用于业务的其他领域。
经理是计时员，而不是为发展做出贡献的人。

这些问题不是您的。这是他们的，您不应该在他们的行为上浪费任何精力。如果您不是那种在攀登悬崖时都会微笑并喜欢工作的人之一，那么您应该考虑寻找like minded开发人员的住所。

#8 楼

听起来像我参与过的大多数项目。但是，结局可能不会像您想的那样糟糕：

1）做您的工作。只要完成您的职责，就不必担心整个项目。

2）CYA。如果该项目确实失败了，并且您怀疑经理会开始责怪除了他本人以外的所有人，请确保您有足够的证据证明自己做了您所需要的一切（请参阅第1项）。

3）礼貌些改进建议。不要敲响警钟，不要厄运和忧郁，而要礼貌而含蓄。

例如，如果团队没有编写有效的单元测试（或任何测试），则写一些接近您想要看到的单元测试，并在因果关系上提及这样做如何帮助您解决一个问题。特定的问题，或节省您的时间。

如果您想影响变​​更，无论最终结果是什么，请着重于取得具体成果的积极步骤。这个项目可能永远不会成为赢家，但也许团队可以为下一个项目学习。

：

4）机会重构是您的朋友。

#9 楼

尝试积极主动地寻求新的方法来实现项目的成功。考虑如何提出一些替代方案。现在，您的老板可能会因为项目失败而被殴打，难道他不喜欢有人提出解决方案而不是问题吗？

也许有一种方法可以将功能拆分为交错的交付物？通常存在“必须具备”的程度，因此请查看是否可以优先考虑这些问题并将其分组为里程碑。在时间轴的末尾拥有一些产品总比没有好。或者考虑将团队划分为从事新功能开发的人员和从事稳定性工作的人员之间，这样您可以在两个方面都显示出一些进展。能够找到成功途径的团队成员，如果没有，您仍然会证明自己不会放弃，并将努力寻找解决方案。

#10 楼

努力工作；
保留所有关键设计决策的记录；尤其是与您的工作有关的事情。失败的项目”。每个人都喜欢在逆境中保持积极主动和奋斗的人。因此，尽可能长地尝试成为那个人。乐观的态度，勇气和决心对工作场所总是有好处的。在验尸会议上，每个人都将被追究责任。准备捍卫所有代码。 [注意：作为一般规则，您应该始终编写简洁的代码，以便日后捍卫它。]如果您的电子邮件或设计文档启发了您的决策，那就更好了。会议，尽量保持积极；并且仅在怀疑您的判断，努力或做工时出示您的电子邮件和设计文档证据。

#11 楼

我发现最有效的是Robert L. Read关于如何应对日程安排压力的建议。这是《读物》写的：


应对日程安排压力的关键只是将其转变为上市时间压力。这样做的方法可以使您了解可用劳动力和产品之间的关系。最好的方法是对所有涉及的劳动进行诚实，详尽，最重要的是可以理解的估计。它具有允许对可能的功能权衡做出好的管理决策的附加优势。

估算必须明确指出的关键见解是，劳动力几乎是不可压缩的流体。您再也无法在一个时间范围内装满更多的东西，而不能在该容器的容积之外装满更多的水。从某种意义上说，程序员永远不要说“不”，而要说“您会为得到想要的东西而放弃什么？”得出明确估计的结果将是增加对程序员的尊重。这就是其他专业人员的行为方式。程序员的辛勤工作将显而易见。制定不切实际的时间表对于每个人来说也是很痛苦的。程序员不能蒙蔽。要求他们做一些不切实际的事是不尊重和令人沮丧的。以及每个人需要多少努力。使评估明确，可理解和详细。将任务分成各个组成部分；尽可能详细地解释如何花费开发时间。

一旦这样做，您就有了与管理层讨论问题的坚实基础。一旦将您的评估分解为需要完成的所有特定任务后，您就可以证明该工作所花费的时间比您所花费的时间要多-可能更多。

与您的经理讨论此详细计划后，请准备好保持灵活性。您的经理可能会说“任务X不会花一个月；最多只需要一个星期”，或者“任务Y完全没有必要，请从计划中删除。”您当然可以讨论这些要点，但更重要的是要在您和您的经理之间就某个切实可行的时间表达成共识。这样，如果您没有被分配时间进行测试，那么您就有了明确的指令不进行测试，而不仅仅是“出乎意料”地耗尽时间。而且，您的经理绝对有可能愿意明确地偷工减料，以便按时发货-在很多情况下，这是一个非常合理的电话！

估算为您提供了辩论和讨论的具体内容。它使您处于同一页面上；它可以使您确信经理已考虑到您的顾虑。而且，如果您的经理明确地提出了不可能的要求，那么这对你们俩来说都是显而易见的。如果项目做得好，真正地注定了失败，那么您将清楚明白这一点，而您的经理将可以准确地决定他希望您如何度过的时间。

#12 楼

这里已经有大量实用（或其他）建议，但对我而言，这个谜题的关键是以下两项（强调我的意思）：

截止日期为1.5个月

和

...实际上，我们是在1-2个月前从同一开发人员领导下的另一个开发团队继承了这个项目（以及混乱）。
/>
所以....
欢迎复仇者联盟的Patsy团队
前任团队要做的事比失败要多。经理以某种方式同意了这一点。在接近截止日期之前更换团队并不是最好的项目管理措施，所以……这是怎么回事？
纠正：在截止日期之前约三个月更换了先前的团队。
- ->了解先前的开发团队是如何逃脱的，并做到这一点。 <-
仅用3个月的时间就可以在如此大的系统上加快速度，更不用说校正其体系结构，添加测试并完成它了。您需要更多的时间
如果不能这样做，除非您完全确定该项目将无限期扩展，或者在魔术精灵或其他某种东西的帮助下，否则您不想成为最后一个站着的人袋子。
严厉吗？是。但是尽管先前的团队/经理的糟糕计划（至少！）不是您的错，但“交付失败”将是您的错。前一支球队被踢到路边。这告诉你什么？它告诉我，您是周转团队...而您的经理正在依靠您的英勇来挽救一天。
一个5人的团队，需要1.5个月的时间。新团队只进行了1-2个月的项目，因此新团队甚至没有超出学习范围。粗略估算一下这个项目的规模，在我看来，即使该项目根本没有问题，新团队也不会超出学习范围。认为你被竖起来了。
如果是这样的话-只有您可以决定什么是真实的，或者您想相信什么-您不必欠任何人任何解释或道歉，以免遇到火车残骸。但是，您确实需要谨慎。
我严重怀疑经理是否没有意识到该项目处于危险之中，这意味着温和的解释只会给您带来负面的关注。除非您的经理是罗杰斯先生，否则您的未来将处于危险之中。

#13 楼

因为您的经理知道它可能会失败，所以您比大多数人都富裕。我会考虑与经理一起工作，看看是否可以排除该应用程序的任何部分/功能。

我们经常认为每个客户的要求都是“交易杀手”，并竭尽所能保证交付。在某人与客户合作并深入调查之前，您可能无法做出这些决定。如果您无法执行此操作，请仍然尝试提供您认为最重要的内容。有时候，请求宽恕比获得许可要容易。

#14 楼

我参加了三个明显失败的项目。这些都是很痛苦的，但是回想起来，三分之二对我的职业生涯没有负面影响，甚至第三分也不是世界末日。 />
初级职位的开发人员（“按规范编写代码”，“修复错误”之类的东西）不会受到太大影响，除非他们由于团队士气低落而放松下来。在这样的职位上，明智的，有时甚至是成功的生存策略可能会尽力而为。修复了数百个已知的错误（再加上特别聪明的方法（由技术负责人推动这一进展））最终导致高层管理人员决定恢复该项目，并通过新版本为其提供另一个机会，从而取得了一定的成功。


更高级，有影响力的职位的程序员最好准备分享项目失败的负面影响。通常期望建筑师，技术负责人，高级开发人员产生足够大的影响，以至于应将其视为项目成功或失败的原因。 “，通过分析哪里出了问题以及可以做得更好的方法。

这些知识点，如果掌握正确的话，验尸课可能会很有价值，高级职位的成功职业取决于如何正如在WP这个出色的回答中所解释的，这些都是学得很好的：判断不是来自成功，而是来自失败。大多数公司都想雇用以前的公司为自己的失败付出了代价的人...



从更实际的角度来看，可以考虑将“下一个/更新版本”方法作为解决故障的一种可能方法。偶然地或不是偶然地（我认为不是），但这两个没有破坏我的职业的失败经历了非常相似的场景：发行版N完全是灾难，发行版N+1是可以容忍的，发行版N+2和后来的发行都是成功。 >
走路时，我很可能会花一些精力来准备/推广“下一个版本”的想法。制作（并进行交流！）类似的已知问题的暂定清单，您希望在计划发行后予以解决。为下一个版本起草非正式的粗略路线图。

考虑如何将这些想法传达给周围的人，以及如何影响管理层以考虑此计划。如果该项目的人员具有良好的营销技能，请尝试通过将即将发布的版本包装为更平滑的术语（例如“抢先体验”，“测试版”，“客户预览”，“介绍性发布”等），使他们参与摊销故障损失。

考虑一下备用计划，以防万一更高的报价对这个想法充耳不闻。还记得上面有关“修复一百多个已知错误”的故事吗？

现在管理层可能对下一版本的想法充耳不闻，但是面对有力的项目质量证据，他们有很大的机会重新考虑进展。


很可能在冻结计划发布的代码与完全放弃它的管理决策之间会有相当长的时间。那时候是您的机会：如果您将精力集中在解决已知问题上，并适当地“宣传”​​进展，这可能会有所作为（就像对我而言曾经如此）。

#15 楼

这对您来说是一个难得的机会！让我们对此采取企业家的观点。

假设管理层希望该项目成功，那么您将很有帮助。意识到这一点如此重要的原因是，您必须坚定信念和信心，使您看到的警告信号实际上会导致该项目的失败[1]。

这就是您的有机会练习系统思考和人际交流中的重要技能。了解并可视化遗漏的问题和潜在机会，以便您制定策略以尽可能清晰，简单地进行沟通。

在这里认识到您提高技能的机会。

[1]取消项目实际上是成功的。失败将是在失败之后花费大量金钱。

#16 楼

您可以做什么


以您自己的卓越表现来对待它，这是“他们的”项目，也是您的，即使您知道它会失败，也要拥有所有权。为什么？因为a）您可以帮助它减少失败的几率，b）在遇到挑战的时候，这是您学习最多的地方c）您应该通过自己的卓越标准来衡量自己，尽力而为可能不会节省项目，但是可能最终仍然以自己为荣
与其他开发人员交谈，看看他们的想法，如果仔细做的话，您可能会发现很多人也有同样的挫败感（不要让人认为您要发动叛变。等等），那么这不仅对您有帮助，对其他人也有帮助
忽略这个问题并不能消除它，谈论如何克服各种困难，例如至少获得一些体面的必备品，或者正确完成主要的“哇因素”用例，可能会使该项目的失败少一些痛苦。怎么做？好吧，很少有关于“何时变强硬”的想法，或者“绝望的时代证明了绝望的措施是合理的”和其他陈词滥调，例如：大量使用OSS，极端编程/敏捷方法，周末黑客马拉松（仅限志愿者，不强迫人们周末工作）。在这个时候，您可以表现出领导才能（如果您不在团队领导/高级职位中，请小心），但您可以利用这一优势并成为他们的嘲笑者，只是让人们感到他们可能会比失败少一点大家都知道会的。您可以在此处显示一些领导技能，这些技能可能会在以后帮助您，将问题视为挑战。
确保您的管理层知道，但是非常非常小心，如果他们知道，他们将不胜感激，您以一种非对抗性的，冷静的方式告诉他们，如果他们不这样做，他们将更加欣赏，并且想知道为什么没人告诉他们之前关于它。您应该告诉他们这是一项服务，没有任何情感方面的支持，只是简单的事实，也没有议程。如果他们问您您认为他们应该做什么（这是一个好兆头，但很少见），请参阅下一节

您不能做什么，但您的管理层可能应该


他们不应该在项目中添加更多的人以“帮助”。

立即致电客户并告诉他们坏消息。为什么这是个好主意？好吧，我将引用敏捷软件开发的宣言，但是即使没有宣言，甚至瀑布爱好者也不会感到意外。如果客户提前知道该项目注定要失败，他们会很不高兴，但会高兴得多，因为您告诉他们在问题浮出水面之前有问题，并且您已经做好了准备，并竭尽所能它。客户可以做很多事情，但是大多数事情并没有比在最后一分钟发现他们没有交付物（或者他们做到了，但是质量不高）要糟糕。客户会对此表示赞赏，因为他们将能够延迟聘请测试人员，离岸IT人员，更改他们的内部培训计划，以及仅仅是因为您对他们诚实。
和客户一起，想办法从项目中做出一些事情，最常见的方法是对项目进行范围界定。例如，有些功能可能太难以开发其设计方式，如果客户同意一些小的修改和简化，那么某些功能将变得更简单。
更新他们自己的高级管理层，它将帮助他们保持良好的工作状态。

您不应该做什么


要求向项目中添加更多人（请参见此内容）
退出/寻找另一份工作（至少现在还没有），这是您可以从中学到的东西，这将使您有一天成为更好的开发人员或更好的经理。您将学会更好地欣赏许多事情，更好地管理时间，更好地设计，更好地编写代码，以及更好地与同事和管理层合作。如果您不喜欢在那工作，不是因为任何其他原因，请在这两个月结束后找工作。
对于项目，管理，您继承的不良设计，您必须指导的新手开发人员需要3个小时来解释他们做某事需要1个小时，因此请尽可能地积极。
批评管理并成为制造麻烦的目标，他们同舟共济，他们可能知道您不了解的事情，您所能做的就是更新它们（始终更新您自己的直接经理，永远不要绕过她/他）
责怪别人（或你自己），这无济于事，永远不要
把它当回事，除非是医疗设备，否则如果错过最后期限，没人可能会丧命，这是软件，我们错过了谋生的最后期限，放松身心。

这只是我的两分钱，YMMV

#17 楼

找到项目遇到的问题，并尝试客观地明确量化。使用每个“指标”进行量化时，请确保定义您认为该指标很重要的原因。您想让您的经理了解如果某个指标不在“可接受范围”内将带来的后果。您需要为每个指标提供一些指导，以指示哪些值是“良好”，“可接受”，“有问题”或“不良”。预先定义每个条件。如果可能的话，您可以描述一个项目成功所需的最低限度需求，并将其与当前项目进行对比。


静态代码质量可以通过许多静态分析工具来量化。您可以根据自己的需要保持简单或详细。我建议您从以下指标开始：

循环复杂度
代码的大小（例如，每个函数/类的行数Nr，文件数，表数...）
找出哪些模块太大
重复。
遵循代码样式


缺陷率

每个KLOC按模块和/或子系统（确定系统中有问题的部分）
可以计算出每个团队成员的数量，但我认为您应该自己保留
解决与发现
解决bug所需的时间（也许如果有此倾向，请绘制此图）估计如果以当前的速度继续下去需要多少时间


计划

推断用于构建功能的时间。考虑到功能的复杂性。这不必很精确。您要传达的内容是“特征A，B和C与D，E和F具有相同的复杂度。如果计划时间，则ABC使用170％的特征。如果没有变化，我们期望相同DEF需要时间”或“平均功能花费比计算时间长X％的时间。我们没有理由认为其余功能更易于构建，因此我们应该在以后的计划中对此进行补偿
尝试有一些每月甚至最好是更短的发布时间表。如果只是内部发布，这可以帮助您进一步推断项目所需的时间。这也可以使您免于做出不切实际的承诺（如果您在发布完成之前不承诺进行新工作）。已添加到当前循环中。）


测试范围：说明“否rmal”测试覆盖率值，并显示您当前的覆盖率是什么
文档：实际记录了多少％？效果如何？
模块化：

基于类（耦合和内聚）
基于包
基于子系统（有多少个通信路径？）

#18 楼

无论是否成功，您都应该去上班，对任何项目做您想做的事情。您将获得报酬执行您的工作。尽力而为。假设您不是项目经理/负责人，则决定是否取消程序不是您的责任。您决定松弛的决定与您决定取消项目的决定相同。那不是您的职位描述的一部分。

但是，从更大的角度看，这并不意味着您应该每周工作50、60或更多个小时才能达到时间表。再次，这是管理层的工作，以弄清楚如何实现项目目标。每周工作50小时以上不是一个合理的选择，除非他们愿意支付加班费并且您愿意保留家庭生活。再次，制定可实现的时间表是管理层的工作。他们不能假设他们会强迫员工无视他们的家庭生活以满足不切实际的时间表。

此外，时间表可能还剩1 1/2个月。那可能不是“死亡”日期。某些客户可能会在那个日期之前拿走您拥有的东西，即使不是全部。一些客户可能已经想出了额外的资金，因为他们已经在该项目中投入了大量资金。有时，公司本身可能会承担额外的费用，以确保客户满意。所有这些都是您无法控制的。尽力而为。这将为管理选项提供帮助，从而使灾难项目成为一个成功的故事。我已经看过很多次了。

#19 楼

我只能重申别人所说的话，但我着重强调：始终为您的最佳工作而努力，并保持书面记录。出于CYA和技术原因。
任何失败的发生都取决于管理层的个人个性；但是，让我告诉您，面对无能的说谎管理者，这真是太糟糕了。但最糟糕的是，您会保持完整的自我（和同伴）尊重。当您遇到不可避免的面试问题时，您是否参加了失败的项目？为什么会失败，您怎么做才能阻止它？骨头管理不是答案-即使是原因。

#20 楼

认为这是不可避免的完全失败而只是放弃项目可能是一个简单的方法。
作为顾问，我经常受邀为处于退化，失败，各个阶段的项目提供帮助

您认为完全失败的事物，可能不会被所有人认为是完全失败，这取决于视角。

/>在理想的世界中，每个功能都可以完整地完成，并优雅地进行编码，并且独立于其他系统和经过测试的每一行代码。
我还没有看到一个像第1版中那样的项目。
在现实世界中，交付项目意味着需要做出一些妥协，甚至可能会丢失一些关键功能，但是该产品可以交付，即使它充其量是Beta版质量，至少您会得到关于首先要解决的问题的反馈。
这方面的好处是，它可能会通知管理层软件从未完成，而不是尝试在真空中开发某个v 1.0最好以敏捷的方式进行迭代和响应。这些条件-记录下来，自己编写测试，如果必须的话（尤其是对于外部依赖项），并利用对系统的了解来传达哪些功能真正关键和必须具备，哪些功能可以等待一周或一个月。 br />让自己对您的问题大声疾呼，并像对待我们一样对它们进行辩护。
与其准备B计划，不如准备一个事实，即您和其他可怜的人可能会解决所有的错误而不是编写代码产品上市后-如上所述，这意味着以模块化解耦的方式编写代码-如果您认为持久层代码不好，希望您可以在下一个版本中完全替换它。
最后，请不要失望-处理这种情况是您所要获得的报酬的一部分，并且这是一个学习过程。不管这个特定项目的结果如何，这都将是未来的宝贵经验。