為什麼開發者總是選昏招

當前，軟體開發者在設計和實現系統時總是面臨很多選擇。我們時常被過多的選擇轟炸並習慣於應付像NoSQL、雲、REST、Map-Reduce等流行詞。然而，負責設計系統的開發者很容易被誘導而採用沒有明顯優點的新技術，反而忽視了那些看起來不夠現代和時髦的簡單方案。看來KISS原則(Keep it simple,stupid!)雖然常被提起，但在支援企業級方案時卻往往被忽略。這是為什麼呢？

原因可能有很多，下面我總結了幾條，我想能覆蓋大部分情況。作為職業開發者，我強烈認為，我們有責任為僱主提供最好的、長期的解決方案，當我們的個人喜好與此目標衝突時，我們應該控制自己。軟體開發仍舊不同於醫藥或工程領域，但我想我們確實需要學習這些領域中的工作所帶有的專業精神、責任和義務。

原因#1-厭倦重複 開發者經常重複的解決同類問題。不是所有人都能一直從事新工作，就算有機會，也很可能還是老環境下的；類似的問題常常已經被全球的軟體開發者解決過成千上萬次了。

即使之前我們能熟練的解決某一問題，我們還是想嘗試新的事物，這並不奇怪。我們是天生的難題解決者，而且有時僅僅是想嘗試下新的難題。我確信很多有幾年經驗的人都看到過這樣的現象，採用不同技術的新實現將原功能系統替換掉，而此舉除了滿足新開發者的個人喜好之外實際上沒有什麼明確的原因。

我們應該如何處理呢？我們該如何控制自己對新事物的渴求？比起嘗試最新的NoSQL平臺來，關聯式資料庫真讓人煩躁。誰在意是不是我們未能有效利用它呢？哦，我想我們還是有幾項可選的。比如，採取主動，找到可能受益於新技術的平臺構建方式。為什麼不利用業餘時間做一些試驗性專案來滿足自己對新技術的渴望呢？畢竟我們的工作是交付高質量軟體，而非取悅自我。

這裡要說明一下，我並不是要勸阻任何人使用新技術，只是建議一定要了解技術的優點，並確認這是否是你的最佳選擇；如果說離了這個新技術幹不成事，那就盡情去用吧！

原因#2-簡歷加料 這可能是使開發者選昏招的最悲哀的原因，主要會影響決策過程不良的團隊。這個原因也是很常見的。

目前，軟體開發中的合同和職位經常變動——開發者一兩年跳個槽很正常。忌諱跳槽的時代早就過去了。正因如此，開發者通過不斷的跳槽向上爬。對平均水平或者不夠熟練的開發者而言，通過跳槽獲得提升比在一家公司等晉升要容易的多。

因此，開發者希望採用新技術並獲得一些經驗，以此為自己的簡歷增加閃光點。至於新技術對平臺到底有多大用處，重要性倒在其次。通常，真正用到多少並不重要——找新工作的時候沒有人能假裝他們沒有誇大自己的技能。所以，平臺在從小變大的過程中，往往因為各種原因而死掉，比如使用了未經測試的技術，或者使用了內部人士都沒有真正理解的技術。隨著開發人員跳到更有前景的地方，公司剩下的就只有因使用了太多技術而無人維護的系統了。

我想大多數開發者不會這麼做。當面對要做出錯誤選擇的開發者時，有反對意見的人要努力阻止他們。

原因#3-同伴壓力 同伴壓力可能是最難抵制的原因了。我們都願意相信，我們是獨立的、可以做出明智的決策的個體，但我們都是人，即使最敏感的人也是社會性的動物，也想有一個開心融洽的團體。

當面對新的或者時髦的技術時，很多人都有點害怕去抵制實現那些看起來並未必多好的想法。我們要儘量壓制這種感覺。如果在你所處的環境中，討論和爭論是重要的（就像人們所期待的那樣），你要隨意的說出你的擔憂，即使你不完全熟悉最新的和最好的技術。別忘了雖然軟體技術變化不定但基本原理幾乎保持不變。要是有些東西看起來不合理，那就說出來。即使你是初級開發者，也應該自由的加入你的看法——有經驗不代表就正確。此外，在決策過程中你也可以獲得一些洞察力。

原因#4-缺乏理解 技術選擇可能是在開發者不瞭解平臺如何工作，甚至他們都不想去了解的情況下做出的。

比如，你因為沒有高效能關聯式資料庫經驗，而又擔心實現的東西不具有可伸縮性，所以傾向於選擇NoSQL路線。雖然往往這種擔心是沒有任何理由的。如果你錯誤的使用了工具，當然它就起不到好的作用。不要在缺乏理解或認識的情況下就輕率的採取行動。如果事實上採用關聯式資料庫的方案可以很好的實現系統，並且你的平臺已經在使用這種方案，那麼僅僅因為你對當前方案不熟悉而引入新的依賴是愚蠢的。

為了避免這樣的問題，你需要多加閱讀和學習！如果你在做技術選擇，請檢查你的假設是否成立。就討論中的工具與有經驗的開發者溝通，並詳細諮詢工具的優缺點。學習可用工具的更多資訊並不是浪費，你的行動很有可能在未來得到益處。

原因#5-誤解或者解決不存在的問題 這點與前一點有些聯絡，但這個問題非常重要，值得單獨討論。

當開發者定位新技術時，通常都會因為該技術可以做X和Y，還能對抗Z而選擇它。但實際上，大部分情況下X，Y和Z根本就不是問題。例如，如果我們有一個只讀的資料集需要快取到叢集中的多個節點上，有人可能選擇一個支援分散式資料集且每個節點上元素都不同的快取技術。但是，如果資料集很小且我們不修改資料集，那分散式快取有必要嗎？我們將為不存在的問題而引入了速度慢、可靠性差且複雜度高的新技術。

為了預防這一點，開發者需要確保自始至終都理解問題域，也需要反覆核對假設以確保其正確性。有時我們假設的事情可能並非事實，所以反覆核對非常重要，從而避免覆蓋假設情況的誘惑。非必要的情況下不要增加功能。增加功能也是要耗費力氣的，而我們把在後期做修改的代價看的過高了，卻沒有意識到我們現在投入相同的努力僅僅是為了避免在以後付出同樣工作進行修改的機會，其實這種機會往往很少出現。

我們應該做什麼？ 當選擇技術時，怎麼做才是正確的呢？首先，你需要回顧下面幾點，儘量形成團隊決策。投入越多，越不容易漏掉那些可能讓你改變決策的資訊。

• 複查需求——確認一致性、容錯、效能等需求點。
• 評估一下現有的東西能否滿足需求，如果能，那它基本上就是最佳選擇。
• 調查其他技術如何滿足需求，並考慮額外依賴和潛在失效點帶來的成本（沒有免費的午餐，新技術可能都有較大的維護成本）。
• 徵求團隊中的專家意見——支援你真正理解的。
• 考察任何其他的關注點，比如價格、時間表等。
• 團隊討論並列出贊成和反對的理由。

這只是一些指導原則，你可以採用任何你喜歡的方式，關鍵還是仔細和理性的做出決策。

希望不要有人把本文的意思誤解為新技術是可怕的或者說要避免新技術。其實我已經在實際中使用過NoSQL技術。我相信它能很好的滿足既有需求，並且我之前曾經用它來解決過具體問題。有時我想我們是糾纏於新技術裡有趣的地方而忘記了我們的最終目標。記住你的目標，儘可能做出最好的、長期的選擇。

原文標題：Why Developers Keep Making Bad Technology Choices 原文連線：http://www.carfey.com/blog/why-developers-keep-making-bad-technology-choices/