敏捷開發人員的責任

當客戶要求你給出一個快速而骯髒的解決方案時，作為一個開發人員，你的職責是什麼？是因為客戶是付錢的一方，所以要洗耳恭聽，遵照要求走捷徑；還是遵守自己的意願，堅持技術上“最佳”的方案？或者，這二者可以折衷？

James Shore在《我們的專業職責》一文中簡述了客戶和開發者之間職責平衡的發展歷史：

在過去使用瀑布式開發的那段黑暗歲月中，程式設計人員得提煉出需求，進行設計，並用技術上最便捷的方式來實現設計方案。開發者就是神一般的存在。計劃也完全都是他們制定的。也可能是開發者的大老闆來制定最終期限——或許是由政策方面的壓力所動，或是根據他曾幾何時在某個彪悍週末中的程式設計成果所留下的傳奇式回憶——然後程式設計人員就為此疲於奔命。

是的，我是在過分簡單化一個複雜的情況。但這沒什麼不妥。

敏捷開發對此作出了回應：“嘿！等一下！不能這麼幹！我們並沒有給客戶帶來價值！”於是，計劃遊戲推動著一切趨於平衡——客戶掌控價值，開發人員掌控開銷。

但有些敏捷團隊把鐘擺向另一邊推的太遠了。他們放棄了自己的職責。他們說：“客戶說了算！不管他們說什麼我們都要照著做。”

這太離譜了。

他認為，開發者不能充當掌控者的角色，但與之同時也應該擔負起開發高質量程式碼的職責。理應永遠如此。

如果有人說，“你能不能走條捷徑，乾的快點？”你需要凝視著他的眼睛說：“不。”“不，我們不能這樣幹，否則就會破壞進度。不過我們可以一起找找，看有什麼辦法把這些特性簡化一下，這樣就能更快完工了。”

Reg Braithwaite在《工程學和醫學中讓我敬佩的專業精神》中說到，有的時候，如果客戶想要一個快速而骯髒的解決方案時，聽從他們的意見也不算什麼壞事：

我不贊同當客戶要求你去為了趕時間寫一些骯髒而又難以維護的程式碼時，你可以對他說不。這種想法是好是壞，要靠你自己判斷。我的做法是在我與客戶或是僱主的關係限定範圍內，儘可能的編寫整潔的程式碼。我也在積極推廣這種方式。

但是，我並不認為我有權在僱主或是客戶堅持立場時，徹底回絕他們的要求。他們會因軟體難以維護而遭受損失，所以，是他們，也只有他們在這個話題上有最終的發言權。

他的底線並不是質量，而是道德。

在從事軟體開發的時候，如果我被要求開發一些不安全、會將私密使用者資訊置於風險之中的程式，我會做出自己的選擇，對這種要求說不。

當然，我並不會受到法律保護。如果我被因此而解僱，我也無處求援。我甚至也沒法拿到失業救濟，因為我會被認為是因為某些原因被開除的。記住，是你主動選擇了這個行業，所以如果你將此作為謀生之本，那麼你就必須要以高標準要求自己的道德底線。

Robert Martin（Bob大叔）在《商業軟體是混亂而醜陋的》一文中則陳述說，這種做法是錯誤的。他的客戶裡有一名經理說過這樣一句話：“商業軟體是混亂而醜陋的”，對此他反駁道：

不！絕非如此！商業規則可能很複雜、毫無章法而特殊性又很強；但是程式碼不一定非要也寫成這樣子。實際上，商業規則越複雜、越特別、越毫無章法，程式碼就應該越整潔。當一些亂七八糟的事情左右著整個規則，你怎麼可能把無序的規則變的有序！要想從凌亂的規則中抽絲剝繭理清脈絡，唯一的途徑就是在力所能及的範圍內，寫出最整潔、最清晰的程式碼。

最後，在InfoQ上曾有一篇新聞寫道：重構是必要的浪費（Refactoring is a Necessary Waste），很多讀者都圍繞著何時進行重構、何時不應重構進行了評論。

那你認為開發人員真正的職責是什麼呢？當需要走捷徑時，他們應該“僅僅說不”嗎？他們應當順從客戶的要求嗎？還是應該靈活一些，但又必須關注那些會影響到客戶的事情，與之同時堅守自己的價值觀和道德？

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/14639675/viewspace-369130/，如需轉載，請註明出處，否則將追究法律責任。