如果是大公司的普通程序工程师，那么，代码驾驭力很重要。
驾驭代码，如同带兵，如何像韩信，多多益善。
大部分情况是，产品提出需求->编写代码->产品需求变化/原需求上加新需求->改写代码。还有产品发布日期。
需求变化是一个不争的事实，需求经常变化更是司空见惯。
重构，设计模式。
等等，还有两个关键字，协作，清晰。
看着自己努力打造的代码，被推倒；或者一想到自己的亲生代码，要进行大手术，实在是一件不爽和痛苦的事。
不爽在于，原先明明说好要那样做，为什么现在又变了(产品人员也很无奈，现实逼的)！你自己产品没说清楚，现在才来纠正（太多东西，产品人员没注意到）！
痛苦在于，按照我现在写的代码结构，照产品需求这么改，是革自己代码的命。还有个发布日期等在那边，它就是个时间轴的死亡线。
如果没有银弹，至少来个缓解痛苦方子吧。
战略上，你写好代码，实现一个可单元展示效果，便给产品人员测试。如同你写好一个可单元测试的方法，给测试人员。
战术上，重新整理业务逻辑，清晰它，为它构建一个健壮灵活的结构。然后开始重构，用万变不离其宗的设计模式原则重写代码。
想法是丰满的，现实是骨感的。
大家一起合作，还是能丰满的。