哦，对，需求说明书上有点问题，但我们需要马上去做这个东西。系统上线时少不了它。每个人都需要它。它只是个小小的改动。这一定很容易办到，你们很快就能做出来。”
–项目经理
你跟项目经理、市场人员一起坐在会议室里。你听着他们根据著名的“need, must, easy, fast”猜想而得出的要求。你该怎么回答?你被逼到了墙角。
在这样的会议后，你们有多少人昧着良心做了违反开发原则的编程活动?有多少人明知这样图省事、抄近道的做法会成为将来做大的麻烦却还是做了?
我就这样干过。
幸运的是，经过这些年，我多少也学会说些“不”了。
“老大，我不建议现在做这种修改。这样做显得不是很专业。如果我们现在做了这样的修改，虽然完成的很快，但总有一天会需要有人把它改成正确的方式。我不愿为将来这个人制造这种麻烦。
然而，我不是老板，如果我们非要按这种方式做，我建议我们必须至少花几个小时的时间为这个问题写一些文档说明，开发一个自动功能测试单元，来提示我们这个问题依然存在。如果你认为这是个如此重要的功能，我们是否该在之后花上一两天时间把事情改正确呢?“
通常这样说会起作用。如果不行，这就到了把事情提到另外一个层面上的时候了。”那好，你真的希望我这样不专业的做事吗?“。
程序员们，每次我们使用没有意义的变量名称都是对我们的同事的一次伤害。每次我们抛出一个毫无意义的错误提示、或没有对这个错误进行标注说明，都是对技术支持团队的一次伤害。每次我们写程序不写文档、图省事抄近道，最终都是对参与这个软件开发的所有人的一次伤害。
如果我记得没错的话，人们在取得行医资格时的希波克拉底誓言中有这样的话：
我会根据我的能力和我的判断为我的病人开出有益的药方，绝不做对他们有害的事情。
能把一个专业的开发者的工作跟一个专业医师的工作相对比吗?很多人并不认为它们是对等的。然而，现在医生们使用的那些工具可都是开发人员为他们开发出来的。
你是用什么方法来防止自己被”强迫“做那些不专业的工作的呢?（欣才PHP培训机构）
