最近参与了一个十分仓促的SAP项目，无论是需求收集、功能设计、程序实现、测试、用户培训，几乎每个环节都有不小的疏漏。最终匆忙上线，自然也导致了悲剧性的结果：上线第二天就发现了几百个订单错误，用户的投诉纷至沓来，后续又持续地产生其它错误和误解。在接下来的一周里面，项目相关人几乎每天都要加班到深夜，而且每天中午都要上线一个“十分重要”的补丁，来解决前一天发现的问题...在六七天的努力过后，风波总算渐渐平息。
客观来说，时间不足，资源不足，是项目中的常见情况。有时是因为人的失误造成的，有时是因为一些难以抵抗的因素。一味怨尤并不能解决问题。针对这个让人印象深刻的失败，我决定把作为开发者得到的一些经验和反思记录下来，当做教训。
本文链接：https://www.cnblogs.com/hhelibeb/p/11247004.html
原创内容，转载请注明
1，持续重构
每一次需求变更都有可能增加程序的复杂度，使设计变差。在时间不足的项目中，这种修改往往尤为频繁，因为来自上游的需求很可能是在缺少足够思考和沟通的情况下产生的。为了对抗这种趋势，必须要时时依据最新的情况重新思考抽象，尝试重构代码，以保证代码至少不向更糟糕的方向发展。
在这个项目中，我花了大力气对一些核心逻辑进行封装，并且在程序因为需求变化需要修改时不断地尝试重构，寻找更好的命名、对齐代码、拆分臃肿的类、去除重复代码。结果，在上线后这部分代码运行得相对良好，只有2个比较轻微的代码bug，都是上线前两天的临时改动造成的，忙碌导致的开发人员头脑混乱是bug的主因，程序的设计本身还算过关。此外，虽然上线后产生了一些紧急的需求变化，但因为相关程序的可读性较好，耦合度不高，程序层面的变更就得到了快速、有效的实现。
但在有一个“不太重要”的批处理程序发生了严重的翻车事故。早先，我们对这个程序的期望是用来处理一些数量极为有限的“例外”订单，它出场的次数不会很多，即便有bug，影响范围也应当十分有限。由于我自信在上面的核心逻辑的实现中已经取得了成功，傲慢和焦躁的我只是草草写完了这个程序，对后续的需求变化，也只是简单地找到看起来正确的程序位置，注释重写几行代码，或者插入若干if-else之类的语句，并没有关心重构问题。可上线之后，实际情况很糟糕。由于需求沟通的失误，“例外”订单的数量大大超出预期，批处理程序没有正确地处理异常，反而因为程序bug造成了进一步的异常。通过对它的检查，我发现，这个短短几百行的程序中包含多个低级错误，各种if-else的交织远比自己当初想象中的要复杂...我不得不把这个程序改了又改，修改多次之后才勉强保证它能正常运作。这便是不重构的恶果。如果有足够的重构的话，问题也许早就暴露了——或者即便不暴露，也会很容易地被修复。
能否持续重构是决定代码层面成败的关键因素。有两个原因决定了这点，
- 人会犯错，也会学习，持续的重构可以帮助改成错误、提高自己。
- 需求会变，变化会破坏设计，导致程序出现不必要的复杂度，从而难以修改和维护。需要通过重构把被破坏了的设计改善，这样才能保持良好的设计，避免因为额外复杂度导致开发时间更加紧张。
一个现实的问题是，时间不足的项目里，可以用于重构的时间会更少，如果用于实现功能的时间都很少，还要怎样重构代码呢？
在这方面，我的经验是，
- 时间不足的项目往往有管理不善的因素，而管理不善，通常意味着各个过程的衔接可能会有问题。工作衔接上的问题会造成沟通不足和低效等负面影响，但也很可能会在某些阶段让开发者有一些空闲时间。抓紧利用这些时间重构吧！
- 好的抽象是重构的基础，在对代码实际重构前，心中首先要有个好的抽象，而抽象是不包含很多具体细节的，这意味着开发者不一定要面对代码才能思考重构，理论上，吃饭、走路、洗澡的时候也可以进行相关思考。当然，前提是开发者确实还要有精力做多余的思考。
2，重视问题的处理顺序
让我们感到很遗憾的一个情况是，有好几个重要问题其实在上线前就已经被部分同事想到/发现了，但由于各种原因，它们都没有引起足够的重视。
在项目问题逐渐被修复的过程中，一个参与项目较晚的同事问我：我曾经在反馈过一个测试中出现的bug，为什么你们都忽略了？结果现在导致了很多问题。
我回忆了事情的经过，这个问题没有引起重视的原因是多方面的，
- 该同事参与项目太晚，,对很多东西不清楚，之前提出了数个错误的问题，导致其它人对她的新发现信任度不高。
- 问题表现在外部系统，这使得大家对它的热情很低。
- 时间紧迫，似乎有必要优先处理更明确的问题。
这三点都不无道理，但我们忽略了一个更重要的问题，那就是一旦这个问题确实存在，将造成严重的影响。相比之下，上面的三个理由都是相对主观的理由，而仅仅是“可能造成严重后果”这一个理由，就应该足以引起大家的重视了。所以，在确定问题时，不应只按照“可能性”确定，也应按照结果的严重性确定。我想，在项目时间紧张，面临大量需要处理的问题时，也许应该按照以下顺序处理可能性和严重性不同的各种问题：
- 确定的、后果严重的：最优先处理，对其进行修复。
- 不确定的、后果严重的：次优先处理，对其进行调查。
- 确定的、后果轻微的：延后处理，对其进行修复。
- 不确定的、后果轻微的：延后处理，对其进行调查，或忽略。
下图是我画的一个问题管理象限图：
3，保持乐观
在进度的重压下，保持乐观的心态十分重要。我是容易唉声叹气的类型，但是我发现一些优秀的同事往往更能苦中作乐，在大家疲惫不堪的时候想出很多笑话，让大家稍稍变得开心和放松起来。这在无形当中给了大家很多帮助，值得我学习。
困难总会过去，保持乐观，也许能帮助我们更好地度过难关。
总结
用三句话来总结三段内容，
- 通过持续的重构，不断消解额外的复杂度，保持健康的代码设计。
- 按合理的顺序调查和解决问题，准确确定真正重要的问题，让时间花费更有“性价比”。
- 乐观，坚持。
参考文章：
时间“四象限”法