優秀的程序員如何優雅地面對更改需求

更改需求是不少程序員兄弟頭疼的事情，由於需求的更改最直接的影響就是工做量的陡然上升，對於已經工做量很大的咱們來講無疑是一件雪上加霜的事情。然而，咱們老是會聽到領導說「客戶就是上帝」，當客戶有更改需求的須要，做爲技術人員也必須主動迎合客戶的須要，這同時也給咱們帶來較大的工做壓力。那麼，做爲程序員，如何優雅地應對更改需求，以便更好地適應職業發展的須要呢？
在提出具體的建議以前，筆者認爲對項目開發的需求規劃和可行性分析作一個較爲詳細的討論是頗有必要的。
在軟件的生命週期中，需求規劃是一項重要環節，在軟件項目開發的過程當中，若是忽然更改需求，勢必會打亂軟件的生命週期，從而使開發過程陷入一種比較尷尬的境地。在網上也有不少關於吐槽更改需求的帖子，把更改需求比喻成將咖喱牛肉炒飯改爲蛋炒飯，再從蛋炒飯改爲番茄雞蛋炒麪。這樣的更改需求無異於將需求規劃推到重來，讓以前開發人員所付出的辛苦付之東流。因此爲了不這樣的事情發生，在作開發以前須要將系統的功能「實現什麼」做爲鐵板釘釘的目標。
將「實現什麼」肯定好以後，才能夠去討論「如何去實現」。經驗豐富的程序員都可以作到將客戶需求的更改轉化爲實現方法的調整，這樣可以避免將本身的開發思路打亂。在對「實現什麼」整理的過程當中，將須要實現的目標規範成描述完整、清晰規範的文檔以及相關的性能，固然，還有各類可能發生變動狀況的預案。
說到這裏，如何優雅地應對更改需求就能夠轉化爲如何成爲一名技術過硬、經驗豐富的程序員之一問題了。
技術篇——準確的需求評估與合理地可行性分析
準確的需求評估源於對對需求的深入理解，如何將普通人的想法轉化成程序員的編程思想，這就須要將需求深刻到設計層面。不只要會委婉地拒毫不合理的設計，還要能提出能夠替代的、合理的方案。所作的這一切都是爲了不出現開發過程當中的頻繁更改。尚學堂陳老師指出可行性分析能夠幫助咱們在作好需求評估的基礎上讓需求更好地固定下來。
首先是技術上的可行性：肯定好需求的實現是在團隊的技術能力範圍內，例如前端、後端、服務器、數據庫的開發人員配備，有無之前可用的經驗，這些最好作到清單化。在此基礎上，就能夠開始對系統的架構進行梳理，作到安全性、可維護性、可擴展性。因此不要急於寫代碼，梳理好思路，編碼效率更高。
其次是風險的可控性：若是發生需求的更改該如何應對？最好的辦法是在架構不變的狀況下，擴展功能，豐富接口。開發好預留地，可讓咱們在開發的過程當中應對自如。
還有就是高質量的代碼：整齊美觀、註釋充分，有良好的可讀性和複用性，即使沒有文檔的輔助也能夠隨查隨改，這樣可以大大提升在開發週期中編碼階段的效率。
經驗篇——從容淡定地應對開發過程當中可能出現的狀況
從容淡定，源於對技術的自信，做爲開發者，紮實的技術結合着經驗面對各類開發需求才能練就火眼金睛。
避免盲目自信，準肯定位問題：從事開發不是爲了炫技，避免追求簡便而爲後續更改形成沒必要要的障礙，諸如頻繁地調用、多層套嵌都需謹慎。在客戶未提出更改需求以前不要被本身存在的問題所打倒。因此，debug技能對於優秀的程序員來說必不可少。
善於溝通，引導客戶：客戶提出的需求天然有他的道理，因此和客戶溝通的目標是要探尋客戶的需求邊界。敏感地捕捉客戶的需求點，讓客戶成爲咱們開發流程中的合做夥伴。產品經理是咱們的戰友，在某種程度上，咱們說服的對象更多的是PM。要知道，世界上沒有任何一套軟件系統或信息系統是天衣無縫的，因此沒必要爲了完美而和PM爭論得面紅耳赤，讓更改需求更多的是一種對軟件的改進，這樣才能在開發過程當中應對自如。