优秀的程序员，如何优雅地面对更改需求？

谢邀。

做程序开发工作，更改需求的问题是必须要面对的。本人七年左右程序开发经验，这里就个人经验做下分享。

时间管理

最重要的一点，做时间评估、开发计划时，一定要留有余地。

软件实现过程是多人合作的，而且经常出现多人多条产品线同时实现，所以正常开发周期中有各种变化因子会影响交付。

接口调试、设计变化和需求修改、技术难点、临时任务、测试问题以及多人配合，有经验的开发者和项目管理者会在开发时间上留有一定余地才能有时间应对一些可能的状况。

理解业务和扩展方向

需求变化一般跟业务息息相关，深入了解业务以及业务扩展方向，一方面可以在代码和框架上提前布局，另外一方面深入了解业务有助于快速了解需求，降低新业务理解和理解偏差返工的时间。

代码优化

一个项目经过数次迭代如果不经过一定程度的优化，代码逻辑混乱、维护和扩展困难是必然的事情。

适时优化代码，特别是后续预计会频繁修改和扩展的代码，必要时候只要可以提高效率甚至可以重新设计重构。

提升技术和工作效率

从容开发上面讲的都是术上的策略，最关键的还是要回到这里：提高技术和工作效率。

好的开发者知识面广，基础扎实，代码纯熟，坚持学习新技术。在做开发时候，技术选型、代码实现往往能够窥一叶而知全貌，能够思路清晰地从容实现需求。

提高工作效率保持专注的开发者，往往能集中精力，在高强度任务中也能够游刃有余。而有拖拖拉拉习惯的开发者很难留出自己的个人时间，让人总是感觉很忙，而工作量又不大。

了解更多互联网科技和编程知识，欢迎关注本人头条号：技术世界

很多程序员以为拿到需求就需要立马改，这是不对的。

以下讨论提出需求的用户，理解了用户才能理解他们的动机。

挑剔的客户

有些客户是能够拒绝的，有些客户是可以说服的，有些客户是可以教育的，但还有一部分客户是不可言喻的，不管是因为项目经理的原因，还是客户本身的原因，碰到这样的情况都是一个极大的痛苦。

理解用户

用户提出需求的动机正常来讲是想通过电子化方便他们日常的办公。

但还有一部分用户的动机是千奇百怪。

他们不关心项目做得怎么样，他们只要他们的领导满意就行了，他们会跟你说:你想让老人家怎么区分得开？

他们不关心项目做得怎么样，关键是有没有亮点，这是政绩。

他们不关心项目做得怎么样，关键是他们能怎么发泄一口恶气。

大部分客户是需要理解的，这部分客户后期对需求提出修改，极有可能是项目经理跟客户的沟通不足够，或是沟通方式不正确，也有可能是程序员本身误解了项目经理转述的需求，这就是非常强调程序员务必跟项目经理一起面对用户的原因。

以下讨论是否需要响应用户需求，把需求挡回去就能最优雅面对用户需求。

看合同

假如合同已经签署了，并且用户的更改需求不在合同范围内，斟酌帮用户改或就不帮用户修改。

看公司

有些用户是非常重要的，他们决定公司之后的长远发展，比如上级部门单位，这些单位即使贴钱也是要努力做好的，哪怕他们一个微不足道的需求都要严阵以待。

做这样的项目是最痛苦的，有时候用户的需求会跟软件的设计初衷完全相背，有时候用户的需求会把代码改得乱七八糟，有时候用户的需求需要对整个框架大动手术，但是有什么办法呢？

看框架

很多公司都有一套框架，很多项目都是基于这个框架进行修改的，这套框架可以满足大部分用户百分之九十以上的需求。

有一个强有力的技术负责人在维护这套框架，当用户有完全新颖的需求时，更多是在框架层面进行修改，而不是做一些无奈的修复（特别是代码打成库的时候）。

假如代码是一次性的，做完这个项目就废了，工期又紧迫，那么何必花大时间去优雅地完成用户需求呢？代码优雅了，你已经累成狗了，还会被领导责骂。

以下讨论原型模式的作用，确保需求一开始就符合用户。

用户的不成熟

假设用户是理性的，但用户也不是专业的提出需求者，你没有把项目做好放到用户面前，让用户使用一段时间，用户也无法知晓他真正的需求是什么。

现在很多的需求设计工具，软件工程模式都是让用户尽快使用上系统，在使用中用户才能提出更加符合用户自身要求的需求。

原型

原型是非常重要的，特别是重要功能，即使功能还不完善也要先把界面做出来，让用户可以进行尝试，当用户看到活生生的界面的时候他们才会知道他们需要什么。

敏捷开发

敏捷开发的关键就是让用户不断看到进化的原型，让用户全程参与软件开发过程。

敏捷开发理论上是好的，但实施起来却困难重重。

能跟你对接的用户都不敢拍板。

能跟你对接的用户只是把这项工作单纯看成是工作。

能跟你对接的用户是非常不成熟的，极其善变。

我们希望敏捷开发一劳永逸解决用户的需求，却发现敏捷开发也不是银弹。

以下讨论设计模式、过度设计、重构等技术层面东西。

迷信设计模式 迷信完美设计

设计模式可以给框架带来更多优雅的实现方式，方便将来的扩展，但请记住假如预测错误了将来的需求，你做的各种完美的设计就会变成一个笑话，它让你的框架变得极其沉重，极其不优雅。

重构 测试驱动开发才是银弹

只有不断适应用户的需求，根据项目的进展情况做出相应的修改，才能不变应万变。

重构给框架代码留了一条后路，代码的优雅绝对不是一次性写出来的，而是改出来的，只要勇于迎接变化才能拥抱变化。

要做到不怕重构就需要编写大量的测试，这样改起来才能做到心里有底。

经常听说优秀的产品经理应该懂一些技术，以便于更好的和程序员沟通。殊不知，优秀的程序员也是要懂得产品的。

虽说靠谱的产品经理不会太频繁的更改需求，但是没有一款产品是从来不增加或修改需求的，如何优雅面对，那就需要程序员GG们自带产品能力了。

例如在数据库设计的时候，我们必须明确"模型"之间的数量关系，一对一，多对一，多对多等等。

举个栗子，在选课里，课程和人应该是多对多的关系，即每个人可以选多门课，每门课可以被多个人选择。所以在设计数据库表的时候就需要中间表。否则，如果你仅仅在学生表里用一个字段表示所选课程，当产品经理让你统计每门课程的学生名单时，就等着抓瞎吧。

很多时候不是产品经理改需求，而是你的设计太不灵活。

再举个魔兽世界的例子，这个例子会复杂的多。

这个游戏有多复杂呢，游戏里分了多个种族，多个职业，种族有天赋，职业有技能。技能有主动有被动，有伤害有buff/debuff，有物理有魔法，有一次性伤害有持续伤害，有指向性有范围。

天哪，这怎么实现

也许你自以为设计模式学的越好，崩的越快。错综复杂的逻辑关系让你难以梳理类的继承关系。更重要的是，产品经理会改啊。

如果某一天，产品经理告诉你某件装备可以改变某个技能的性质。你悲痛的发现继承关系崩了，咋办。无奈，打上一个个补丁，代码很快就没有可读性了。

让我们看看暴雪的设计师如何解决这个问题

伟大的设计师们利用数据库完美解决了这个问题。

法术ID 动画效果 作用范围 作用类型 属性 特殊限制 强化类型 特殊设定

设定一个包含上述字段的表格，再写上一个解释器，技能释放的时候通过各种公式输出结果，完美避开了面向对象的混乱性。

学无止境，所以别再随意抱怨产品经理了，往往是我们自己不够强大！