有後端開發經驗的程序員都知道，對於同樣的功能，有著不同的實現方式，可以用不同的技術方式去實現，最後都能達到實現功能的目的，但是用哪種技術，哪種方式去實現在開發成本，時間成本，可維護成本，以及是否方便以後的擴展方面就有著很大的差異，因此在前期的技術選型時還是很有必要多花一些時間認真考量一下，只有想的全面一點，才有可能為以後項目的進行奠定良好的發展條件。
近期，一名公司的技術總監因為一個技術方面的選擇，就吐糟了他手下的程序員，他說，搞java的都是老態龍鍾的麼，區區不到十個鏈的lambda表達式吐槽不好維護應該寫存儲過程，這樣的觀點讓他覺得這是回到了上個世紀，在這名技術總監看來，使用存儲過程的這種方式十分不值得提倡，也不方便後期維護，那麼針對這樣的觀點，讓我們一起看看其他網友是怎麼認為的吧，來看看他們是否有不同的觀點。
網友一：我覺得這是常識吧，直接在數據庫裡用sql幹掉的事情，為什麼還要接出來用java？
上世是朵花：關於這個事情，也不能一概而論，不同人有不同的見解，如果只是從性能角度出發，在數據庫直接做肯定是要比後端語言處理效率要高，但是現實場景中除了效率之外，還是有好多因素要考慮的，比如，可維護性等。
網友二：sql不好維護，過長的sql毫無閱讀體驗
上世是朵花：有類似的感覺吧，不過不同人可能對此看法並不相同，比如有的人擅長看複雜的sql, 甚至他們覺得比看代碼容易的多。
網友三：我覺得也要看lambda表達式的可讀性吧
上世是朵花：沒錯，是要衡量一下，需要看具體情況，另外結合項目具體情況去考慮比較好。
網友四：好不好維護，管老闆什麼事？
上世是朵花：沒錯，是否好維護與老闆關係的確不大，但是也不是完全無關係，是否好維護就決定了技術團隊的產出效率，最終還是要決定了經濟效益，還是與老闆有關係的。
網友五：java不懂，C++而言，lambda表達式真不好看
上世是朵花：這名c++的朋友是這麼認為的，針對這樣的事情有不同的觀點很正常，可能看問題角度與自身的環境有關。
網友六：因為數據庫的最根本的作用就是存儲，計算只是額外附加的。而複雜的sql難免涉及到運算，比如多表聯查等等，通常情況下用數據庫的計算能力無所謂，但如果要求壓榨數據庫的存儲和查詢能力的話，就要將數據庫的計算開銷給節省下來，這時候就得將計算部分轉移到服務器。簡單說數據庫只留單表查詢
上世是朵花：認同“數據庫最最主要的作用就是存儲”一說，不過數據庫的有些功能既然設計出來了，那也是存在即道理的，可能使用人群並不多，但並不代表完全沒用，在比較特殊的一些環境還是可以用到的。
網友七：兩種方式半斤八兩，都不是好維護的東西
上世是朵花：軟件設計的高境界就是沒有複雜的代碼，每個程序員寫的都是curd, 看著方便，好維護，但這些curd湊到一塊便是一個偉大的項目，這個設計的精妙之處就是化繁為簡，把那些不好維護的東西逐漸拆分，分解，最終都變成了curd類的代碼。
網友八：你是領導，你可以定統一標準。不能每個人都習慣、比較熟悉的東西完全一致，這就看你怎麼調配了。數據庫有存儲過程並不是不可以，一般數據庫的服務器配置都比較高，資源不是緊缺的情況下，這只是一種選型。如果有很多服務器，緩存、消息、隊列，分佈式、分表分庫全上，異步存數據庫，但這個費用確實不少，還是得看實際情況
上世是朵花：沒錯，在有的事情上，沒有哪種方式是對的還是錯的，都可能摻雜一些利弊在裡面，這種情況都需要有技術領導人站在全局的角度去做決定，保證整個項目的規範與統一。
針對技術方案的爭論，既然存在爭議那很有可能說明難以取捨，往往是每種情況都存在一定的利弊，所以才具有爭議，如果其中一種方案與另一種方案相比，具備絕對明顯的優勢，那就不存在什麼爭議了，對於比較有爭議的情況，技術管理者就需要站在更高的角度去做決定，也不能說誰想怎麼用就怎麼用，整個項目必須有人制定統一標準規範，只有嚴格規範項目，才能讓項目後期有著更良好的發展。
以上所有圖片均來之互聯網
大家好，我是“上世是朵花”。如果你有什麼好的看法或者觀點可以在評論區展現你的才華，互動交流，如果想進一步瞭解我，那就關注我吧！
