其实，我一直在想，我们程序猿在项目发展迭代中的角色与定位到底是什么？也许，在多数的情况下，我们或许做的还不够。也许你会说，我总是努力的完成工作，参与需求讨论，认真的制定执行方案，及时交付产品。如果，你觉得这样做就够了，那么请你认真的回答我以下的几个问题?
(1) 你是否遇到过某种严重到要花费数天来做本来只要数个小时即可完成的混乱情况。
(2) 你是否遇到本来只要做一行修改，结果却涉及到上百了模块的情况。
如果你遇到了，或许你应该反问自己一句，“为什么好代码这么快就变质成糟糕的代码了？”
这时候，我想你会给出很多理由吧。
你也许会说，需求变化背离了原有的设计。
你也许会说，时间太少，进度太紧张，没法干好活
你也许会说，这都是愚蠢的产品设计，没用的营销方式。
我们总是有太多的理由，太多的抱怨。让我们抛开抱怨，冷静的思考一下，难道作为程序员的我们，就不应该付一点责任吗？
也许这时候的你，又要问，难道这不关项目经理，不关产品设计，不关营销的一点关系吗？难道是我们自作自受？
也许他们的需求制定的不合理，也许他们的改动影响了项目，但是请问代码是谁也写的呢？答案是“程序猿”。
经理人和营销人员指望从我们这里获得必要的信息，然后才能做出承诺与保障。即使他们没有问，我们也不应该羞于表达自己的想法。PM指望着我们验证需求是否都能在系统中实现。项目经理指望我们遵守进度。我们与项目规划脱不了关系，对失败富有极大的责任。特别是，失败与糟糕的代码有重要的关系时。
激烈的辩论需求，向经理提出意见，会不会引起经理的不满？我想说，多数的经理想要知道事情，即便他们看起来不喜欢事情。多数经理想要好的代码，即使他们总是痴迷进度。他们会奋力维护进度与需求，因为那是他们该干的事情，而作为程序猿的你，应以同等的热情护卫代码。
在说明白些，假如你是为医生，病人请求你在做手术之前别洗手，因为那会花费太多时间，你回照做吗？本该病人说了算，但是医生应该拒绝服从。为什么，因为医生比病人更了解疾病与感染的风险。如果听了病人的话，那就是一种不专业的态度。
同理，如果程序猿遵循不了解混乱风险的经理人的意见，或者懒于告知未来可能存在的风险，异或者程序能跑就行，不管以后。这也是不专业的做法。
混乱的代码是要付出代价的。
