最近面临的一个遗留问题所引发的惨案。
此问题大概是说某功能在前几个版本中做的太麻烦，性能瓶颈非常难跨越，向后兼容也很成问题。最让我们这些开发觉得不可思议的是，几乎没有客户在使用此功能。怎一个惨字可以形容！讨论会上有种声音说，“开发人员当时在实现时，就应该察觉开发繁杂，而得出这个功能有问题的结论”。“是吗？”我问自己，然后陷入沉思——当需求来了，开发人员能做什么？
我仔细回想了当初在开发这个功能时的各种会议、讨论，试图去发现开发人员能制止这场惨案的机会。讨论中，产品工程师在PPT里展示着精心设计的流程，那几乎就是考虑到了客户的心窝里，我们开发人员抱着敬畏之心，无不啧舌。然后各组老大在原来的需求上加入新的要求，要支持更多功能，”要让我们的客户感觉更加灵活“。开发人员警惕起来，”这个功能好像很复杂，实现起来好像很复杂，真的要在这个Release里实现吗？”。声音太微弱，无人理会，于是新的功能加入了原来的规范文档。
开发人员开始实现了，组织技术攻坚，各种探针实验，画UML图，讨论类的职责、关系。为了实现“客户”的需求，体现团队的实力，若干星期后，功能实现了，但也意识到了问题，如果数据量特别大（millions of records)，会有性能瓶颈，加载会很慢，1G的内存也不够用。可测试过程，没有数据量特别大的case，偶尔出现的问题也有一些workaround可以解决。开发人员以为不是大问题，心放下了，产品也顺利发布！
之后发生的事如开头所述，客户的数据量都非常大，常常有几百万条数据。产品太慢了，之前的实现方案，完全不能应对！同时也发现客户几乎不用这些功能，用的也只是自家的产品工程师。
反思一下，需求来了，我们工程师能做什么？
- 积极地和产品工程师讨论，基本错误，违反常识的问题要指出。当然，谁都应该指出。实现难度太大，要让老大知道，摆事实讲道理，实事求是。
- 高级的需求描述，如操作流程，我们的意见往往无足轻重。产品工程师更了解客户，开发人员总不能因为难而不做吧？难免有捏轻怕重之嫌。此事之后，我想，也许应该多唱唱反调，让产品工程师多些思考。当然，也许谁都应该唱唱反调。
- 规范文档要更细致，包括常见的用例、性能指标；开发人员也要意识到实现的瓶颈。此例，如果这些能明确，也许问题早就发现了。
一切软件产品的根本是需求，最大的浪费是东西做出来没人用。夜有所悟，总结之！
