今天看了一個很有意思的blog， 作爲程序員面對需求變動是常有的事情，哦，你是怎麼應對的呢？
正文：
“哦，對，需求說明書上有點問題，但我們需要馬上去做這個東西。系統上線時少不了它。每個人都需要它。它只是個小小的改動。這一定很容易辦到，你們很快就能做出來。”
-項目經理
你跟項目經理、市場人員一起坐在會議室裏。你聽着他們根據著名的“need, must, easy, fast”猜想而得出的要求。你該怎麼回答？你被逼到了牆角。
在這樣的會議後，你們有多少人昧着良心做了違反開發原則的編程活動？有多少人明知這樣圖省事、抄近道的做法會成爲將來做大的麻煩卻還是做了？
我就這樣幹過。
幸運的是，經過這些年，我多少也學會說些“不”了。
“老大，我不建議現在做這種修改。這樣做顯得不是很專業。如果我們現在做了這樣的修改，雖然完成的很快，但總有一天會需要有人把它改成正確的方式。我不願爲將來這個人制造這種麻煩。
然而，我不是老闆，如果我們非要按這種方式做，我建議我們必須至少花幾個小時的時間爲這個問題寫一些文檔說明，開發一個自動功能測試單元，來提示我們這個問題依然存在。如果你認爲這是個如此重要的功能，我們是否該在之後花上一兩天時間把事情改正確呢？“
通常這樣說會起作用。如果不行，這就到了把事情提到另外一個層面上的時候了。”那好，你真的希望我這樣不專業的做事嗎？“。
程序員們，每次我們使用沒有意義的變量名稱都是對我們的同事的一次傷害。每次我們拋出一個毫無意義的錯誤提示、或沒有對這個錯誤進行標註說明，都是對技術支持團隊的一次傷害。每次我們寫程序不寫文檔、圖省事抄近道，最終都是對參與這個軟件開發的所有人的一次傷害。
如果我記得沒錯的話，人們在取得行醫資格時的希波克拉底誓言中有這樣的話：
我會根據我的能力和我的判斷爲我的病人開出有益的藥方，絕不做對他們有害的事情。
能把一個專業的開發者的工作跟一個專業醫師的工作相對比嗎？很多人並不認爲它們是對等的。然而，現在醫生們使用的那些工具可都是開發人員爲他們開發出來的。
你是用什麼方法來防止自己被”強迫“做那些不專業的工作的呢？
原文鏈接： http://www.aqee.net/2010/10/18/no-i-wont-do-it-it-would-not-be-professional/