一句话需求

在我们的系统设计目标和技术方案确定之后，接下来我们要进入到研发阶段了,对程序员来说再也不用弄那些乱七八糟的文档了，简直爽到起飞。

可是我们没有需求呀，你可能会有疑问，没有需求是如何做的技术方案呢？

当初我们拿到需求的时候，就只有一句话：打造高并发，高性能的系统，自动分配奖券的接口满足20000 QPS，兑奖接口满足50000 QPS。 这就是真实的工作场景，在工作中有很多事情都不是按部就班的，不一定是符合你的想象的，但这就是工作，作为编程者，我们要做的是尽最大努力去解决问题。

虽然没有需求文档，但我们有没有其他可参考的呢？源代码，这是对我们最大的财富，如果没有源代码，我是万万不敢重建的。

有了源代码，我们能看到原来的一些逻辑，但我们不是按照原来的逻辑搬运一遍，否则没有重建的意义。我们要做的是除了要打造高性能之外，还要简化业务逻辑，如果复杂的业务逻辑是根本无法支持高性能的场景。

试着想象一下一个创建订单的事务里操作了5张数据库表，如果业务流程不简化，无论我们怎么优化，一定是无法满足高性能的要求的，因为这是一个大事务，一定是非常耗时的。

简化业务逻辑

基于以上条件，接下来我们面临的挑战是 如何简化业务逻辑。

在简化业务逻辑之前，我们需要摸清楚现状，目前线上的系统已经被交接过好几手了，很多逻辑目前正在维护这个系统的人都不清楚，更不敢随意修改，懂这个业务的同事早已经离职了，这个系统基本就是勉强维护阶段。

这对我们来说无疑是雪上加霜，我们该怎么办呢?

说实话没退路，只能硬着头皮往前冲，只能一行一行的看代码，遇到不明白的，不清楚的，尽量能找以前的同事问问，不过正如我之前的判断，很多同事都已经搞不清楚这个事情的来龙去脉了，更不用说解释了。

所以我们更加小心翼翼的看每一行代码，任何一个逻辑都不敢漏掉，如果不小心漏掉了某个逻辑，那可能会埋下隐患，日后造成灾难。

就这样我们花了大概三个月的时间，终于把每行代码的含义搞清楚了，终于松了一口气，这样我们就可以大刀阔斧的去做优化了，我们设计方案也不断的再完善。

不知道你和我没有同样的经历，遇到这样的事情我想你内心一定是骂娘的，觉得前任太不靠谱了。 从这件事情上，我们知道很多事情并不是一蹴而就，而是慢慢的在混乱中找到一条主线，顺着主线不断添加羽翼，直到整体完善。

内心受挫

在我们方案的设计中，我们也一次次的跟不同的同学，包括不仅限于研发在不断评审我们的方案，每次的会议基本上我们都被批评的体无完肤，不是这个问题就是那个问题，总之很受挫。

但只能眼含热泪，打起精神来不断往前走，因为那是唯一的出路。

在我过去的经历中，经常会遇到一句话需求的情况，也也许你会说怎么这样的事情都全让你碰上了，那谁知道呢？

遇到这种情况很多同学会心里非常不爽，当然这不是研发人员的责任，这更多是公司的责任，想想为什么当初在做系统的时候没有留下需求文档和技术文档，公司在归档上并没有做好，这也是我们这个行业不健康的地方，上一任的开发人员如果有些责任心会想着自己写的东西该如何维护，但如果没有责任心的话，只想着现在怎么维护，至于接手的人该怎么办跟我没有关系，这是非常不健康的行业习惯，甚至是不健康的个人职业习惯。

不管如何，既然事情交到你手上了，唯一能做的是不让下一任跟现在的你一样摸不到头脑。