如果是大公司的普通程序工程师，那么，代码驾驭力很重要。

驾驭代码，如同带兵，如何像韩信，多多益善。

大部分情况是，产品提出需求->编写代码->产品需求变化/原需求上加新需求->改写代码。还有产品发布日期。

需求变化是一个不争的事实，需求经常变化更是司空见惯。

重构，设计模式。

等等，还有两个关键字，协作，清晰。

看着自己努力打造的代码，被推倒；或者一想到自己的亲生代码，要进行大手术，实在是一件不爽和痛苦的事。

不爽在于，原先明明说好要那样做，为什么现在又变了(产品人员也很无奈，现实逼的)！你自己产品没说清楚，现在才来纠正（太多东西，产品人员没注意到）！

痛苦在于，按照我现在写的代码结构，照产品需求这么改，是革自己代码的命。还有个发布日期等在那边，它就是个时间轴的死亡线。

如果没有银弹，至少来个缓解痛苦方子吧。

战略上，你写好代码，实现一个可单元展示效果，便给产品人员测试。如同你写好一个可单元测试的方法，给测试人员。

战术上，重新整理业务逻辑，清晰它，为它构建一个健壮灵活的结构。然后开始重构，用万变不离其宗的设计模式原则重写代码。

想法是丰满的，现实是骨感的。

大家一起合作，还是能丰满的。