【編者按】身處技術(shù)圈我們，時(shí)常會(huì)聽到“XX 已死，XXX 將一統(tǒng)天下”的論調(diào)，本文作者分享了自己入行以來，所經(jīng)歷的各種技術(shù)炒作。
我最早接觸到的一個(gè)技術(shù)炒作是 “用可擴(kuò)展標(biāo)記語言（XML）解決一切問題”。這個(gè)經(jīng)歷讓我有幸見證了前端技術(shù)的爆發(fā)，微服務(wù)的濫用，以及諸多荒誕的趨勢。
我剛接觸編程時(shí)，很多人預(yù)測 XML 將一統(tǒng)天下。HTML 將被 XHTML 取代，使用 DTD 進(jìn)行校驗(yàn)，利用 XSLT 實(shí)現(xiàn)轉(zhuǎn)換和展示，借助 SOAP 進(jìn)行通信。
面向?qū)ο缶幊蹋∣OP）的熱潮我并沒有親身經(jīng)歷，那是我上一代人的事，但我讀了很多文章，它們警告我要小心，因此我把這種心態(tài)應(yīng)用到了 XML 上：在全身心投入之前，我們應(yīng)該先觀望，看看事情是否真的如所預(yù)期的那樣美好。
對于文檔等事物，它是有用的，我認(rèn)為它最大的成功案例就是 MS Office 和 LibreOffice 的文件格式。它們其實(shí)就是 XML 的壓縮包。
我很幸運(yùn)，職業(yè)生涯早期就學(xué)到了這個(gè)教訓(xùn)：沒有完美的解決方案，任何工具，不論多么優(yōu)秀，都要從工程的視角來評估其優(yōu)劣。每種工具都有其代價(jià)，也需要作出妥協(xié)。這其實(shí)是一個(gè)投資回報(bào)的問題，如果沒有足夠的經(jīng)驗(yàn)，評估起來會(huì)非常困難。
總的來說，時(shí)間再次證明了其公正性，沒有什么能代替觀察復(fù)雜系統(tǒng)的演變，不管你對世界套用什么樣的模型。
最重要的是，我了解到極客們雖然自認(rèn)為是理性的生物，但他們實(shí)際上深受噪音，營銷，以及他們自身情緒的影響。他們甚至比普通人更容易受到影響，因?yàn)樗麄兛傄詾樽约翰粫?huì)受這些因素影響，從忽視了這個(gè)盲點(diǎn)。
當(dāng) MongoDB 出現(xiàn)時(shí)（它有強(qiáng)大的拓展能力），似乎啥需求都可以用 NoSQL 。即便是兩個(gè)毫無共同點(diǎn)的 NoSQL 系統(tǒng)也要硬擠在一起。這就好像把一個(gè)國家定義為“非英語國家”。即使當(dāng)時(shí) MongoDB 是一個(gè)可能損壞你數(shù)據(jù)的劣質(zhì)產(chǎn)品也無妨（他們已經(jīng)解決了這個(gè)問題，現(xiàn)在它是一個(gè)非常優(yōu)秀的數(shù)據(jù)庫）。大部分使用它的人并不需要自由復(fù)制，他們的數(shù)據(jù)完全可以放在 SQlite 文件中。
于是，我們看到新手可能會(huì)將沒有固定結(jié)構(gòu)、沒有嚴(yán)格一致性要求以及可能存在錯(cuò)誤或不完整的數(shù)據(jù)存儲(chǔ)在一個(gè)大的數(shù)據(jù)塊（blobs）。這就導(dǎo)致了許多項(xiàng)目的失敗。
此后，Node 時(shí)代來臨。在前端與后端使用同一編程語言成為大熱，你必須采用相同語言，將所有請求異步化。但 JavaScript 品質(zhì)不高，許多 JavaScript 項(xiàng)目僅為避免撰寫 ES5 而出現(xiàn)。缺少 import 與命名空間,范圍混亂, this 具雙重性質(zhì)，基于原型繼承，弱類型等等問題甚多! 因此，我們先后見到 CoffeeScript、Babel、Webpack、TypeScript、React+JSX 等技術(shù)的出現(xiàn)。
我們被告知要跟上最新的技術(shù)生態(tài)，這意味著我們需要應(yīng)對每兩個(gè)月就會(huì)有重大改變的情況。這也是實(shí)現(xiàn)最優(yōu)化的樹搖技術(shù)所需要付出的代價(jià)。同時(shí), 出現(xiàn)類似left-pad 問題也不足為奇，因?yàn)?map 文件生成錯(cuò)誤，無法調(diào)試和排錯(cuò)，進(jìn)一步增難問題。
但是，因?yàn)槟闳匀恍枰ㄟ^線路傳輸大量的數(shù)據(jù)，并且所有的事物都必須在客戶端上，因此 GraphQL 隨之誕生。當(dāng)然，這些會(huì)導(dǎo)致可訪問性差，SEO 問題以及首次渲染時(shí)間長，這又催生了 服務(wù)器端渲染 的大流行。服務(wù)器端渲染（SSR）在構(gòu)建 Web 應(yīng)用程序時(shí)，執(zhí)行了一種類似于公共網(wǎng)關(guān)接口（Common Gateway Interface，CGI）的過程，其中服務(wù)器在接收到客戶端請求時(shí)執(zhí)行一些額外的步驟來生成動(dòng)態(tài)內(nèi)容。前端開發(fā)社區(qū)為了解決服務(wù)器端渲染和客戶端渲染之間的差異，還引入了 hydration 技術(shù)，以實(shí)現(xiàn)更好的性能和用戶體驗(yàn)。
這導(dǎo)致了復(fù)雜性的增加，并且產(chǎn)生了大量一次性代碼庫，最終導(dǎo)致，項(xiàng)目的失敗和資源的浪費(fèi)。
因?yàn)? 大部分這些任務(wù)其實(shí)可以使用 Ruby on Rails、Symfony 或者 Django，配上一點(diǎn) jQuery 就可以完成。至少，它們可以用這些“老牌” 技術(shù)來實(shí)現(xiàn)項(xiàng)目。相反,失敗的項(xiàng)目開始積累,每一個(gè)精美的 Figma 背后都隱藏著許多公司墻壁后無人敢提及的失敗案例。
討論由于過度復(fù)雜性和使用新技術(shù)而導(dǎo)致的問題是被視為禁忌。你就會(huì)被視為那個(gè)無法理解或接受這些新的技術(shù)和趨勢的人。
當(dāng)人們在構(gòu)建基本的增刪改查應(yīng)用時(shí)引入過多復(fù)雜性時(shí)，可能會(huì)感到困惑或不解。
首先，一切都應(yīng)該是微服務(wù) 這句話開始流行起來。每一個(gè)小型網(wǎng)站都有至少一個(gè)提供 RESTful API 的容器,再加上一個(gè)負(fù)責(zé)前端的容器，以及一個(gè)負(fù)責(zé)數(shù)據(jù)庫的容器。各層之間疊加，為了這些層之間的通信，何不加入一個(gè)微型的消息隊(duì)列呢? 如 ZeroMQ、RabbitMQ...... 還需要一種優(yōu)秀的交換格式，比如 gRPC 和 protobuf。
你可能無法相信使用所有這些復(fù)雜的技術(shù)和工具來構(gòu)建一個(gè)簡單的待辦事項(xiàng)應(yīng)用程序會(huì)變得異常困難。所以出現(xiàn)了一個(gè)解決方案: 使用編排方案。先有 Docker Swarm, 后來又出現(xiàn)了 Kubernetes。
到這個(gè)時(shí)候，已經(jīng)投入了很多時(shí)間和金錢，人們開始把云服務(wù)視為救星：他們可以幫你處理所有這些問題，只需收取相應(yīng)的費(fèi)用。你只需要學(xué)習(xí)他們的各種操作方式，去調(diào)試他們即可，被迫局限在他們的生態(tài)系統(tǒng)里，然后使用先進(jìn)的模板化的 YAML 文件，更傾向于使用命令行界面（CLI）或編程方式與云服務(wù)進(jìn)行交互，而不是依賴圖形用戶界面，仔細(xì)優(yōu)化和配置整個(gè)項(xiàng)目。這樣，你在托管服務(wù)上的花費(fèi)可能只會(huì)增加 10 倍，而不是因?yàn)闊o從下手而增加 10000 倍。
然后，大數(shù)據(jù)時(shí)代的浪潮席卷而來。你需要記錄下用戶的每一次操作。你還需要進(jìn)行 A/B 測試，雖然這可能讓 10% 的用戶感到不便，給技術(shù)支持團(tuán)隊(duì)帶來了巨大的壓力和挑戰(zhàn)。但現(xiàn)在，你掌握了海量的數(shù)據(jù)！即使實(shí)際情況并非如此，你也要相信你擁有大量的數(shù)據(jù)，因?yàn)槟阈枰⒁环N數(shù)據(jù)湖。或者是時(shí)序數(shù)據(jù)庫。又或者是圖數(shù)據(jù)庫。總之，你需要某種類型的數(shù)據(jù)庫。
接下來，所有這些現(xiàn)有的系統(tǒng)開始變得遲緩。不是因?yàn)榧夹g(shù)決策欠妥，讓原本每秒只能處理 100 個(gè)請求的網(wǎng)站去采納了適合谷歌這樣規(guī)模的工程架構(gòu)。而是因?yàn)樗捎玫木幊陶Z言相對較慢。于是，我們開始考慮用如 Go 或者 Rust 重新開發(fā)所有代碼。
編譯過程開始變得異常耗時(shí)，以至于連續(xù)集成流水線的執(zhí)行時(shí)間已經(jīng)達(dá)到了 73 分鐘之久。這無疑成了壓垮駱駝的最后一根稻草。于是，開發(fā)人員開始逐漸回歸簡化的方式…… 實(shí)際上，開發(fā)人員正在大量使用無服務(wù)器計(jì)算服務(wù)（如 AWS Lambda）和可以在邊緣運(yùn)行的軟件即服務(wù)（SaaS）服務(wù)，因?yàn)閾碛凶约旱募夹g(shù)棧已經(jīng)不再是未來的發(fā)展趨勢。
與此同時(shí)，博客文章關(guān)于疲勞感的文章數(shù)量迅速增加，高層管理者被利潤的誘惑所吸引。
我很高興看到 YAGNI（You Aint Gonna Need It，一種軟件開發(fā)原則，強(qiáng)調(diào)只在實(shí)際需要時(shí)才添加功能和復(fù)雜性）再度興起。
37signals （一家私人控股的網(wǎng)絡(luò)應(yīng)用公司）再次成為人們關(guān)注焦點(diǎn)，因?yàn)樗麄円巡辉偈褂霉性品?wù)。
當(dāng)然，這種回歸簡潔的熱潮有時(shí)也會(huì)被夸大其詞。因?yàn)楹喖s主義的炒作，畢竟也是一種炒作。
你確實(shí)需要依賴云服務(wù)、容器、NoSQL、Go、Rust 和 JavaScript 來構(gòu)建系統(tǒng)。在現(xiàn)代軟件開發(fā)中，我們需要關(guān)注并滿足不斷變化的需求和期望，利用新功能和特性來打造出色的用戶體驗(yàn)。
然而，使用這些技術(shù)時(shí)要根據(jù)具體情況和需求進(jìn)行評估，而非一刀切地應(yīng)用于所有情況。
一位在美國科技行業(yè)工作了 5 年的程序員表示，這個(gè)行業(yè)總是充斥著各種炒作，新的趨勢接連出現(xiàn)，現(xiàn)代化的概念也在不斷變化，重構(gòu)的需求也越來越多。雖然他有自己的工作流程，知道如何構(gòu)建應(yīng)用程序，但有一天，運(yùn)營總監(jiān)卻完全改變了這個(gè)工作流程。他需要不斷學(xué)習(xí)新的技術(shù)和工具，比如 Terraform、無服務(wù)器技術(shù)、容器技術(shù)、微服務(wù)等等。這讓他感覺自己仿佛陷入了弗朗茨·卡夫卡的小說中，不斷地改變和重復(fù)著相同的事情，因?yàn)檫@就是新的工作方式。這種情況讓他覺得有些荒謬。
另一位程序員表示，在過去的 5 年里，他曾在兩家大型科技公司和一家大型對沖基金工作，這些公司都使用非常過時(shí)的技術(shù)棧，或者是沒有文檔的內(nèi)部技術(shù)棧。管理層不允許引入新的技術(shù)棧，因?yàn)樗麄冋J(rèn)為這樣做沒有商業(yè)價(jià)值，他們更關(guān)注發(fā)布新功能。如果他堅(jiān)持進(jìn)行重構(gòu)并采用新的技術(shù)棧，一旦出現(xiàn)問題，他將承擔(dān)責(zé)任。雖然他付出了巨大的努力成功地升級了幾十年的技術(shù)棧，但這對他的晉升沒有產(chǎn)生任何幫助。他表示，除了修復(fù)安全漏洞外，沒有任何動(dòng)力去升級任何東西。
還有網(wǎng)友認(rèn)為，如果技術(shù)棧過于陳舊，查找相關(guān)資料會(huì)變得困難，而且軟件也難以維護(hù)。也有網(wǎng)友認(rèn)為，維護(hù)成熟的技術(shù)比每隔幾年就進(jìn)行全面重寫更有價(jià)值，公司傾向于在維護(hù)和重寫之間權(quán)衡成本。
還網(wǎng)友表示，雖然現(xiàn)代 Web 開發(fā)比以前復(fù)雜了很多，需要掌握更多工具和技術(shù)，但是這些工具和技術(shù)的出現(xiàn)的確使得 Web 應(yīng)用變得更加強(qiáng)大和豐富,我們才有了 Figma、Spotify、Notion、Photopea 等優(yōu)秀的 Web 應(yīng)用。所以,盡管 Web 開發(fā)門檻變高了，但是 Web 應(yīng)用的潛力也因此得到釋放。
各位開發(fā)者，從你踏入編程行業(yè)開始，你都經(jīng)歷哪些奇奇怪怪地技術(shù)炒作呢？歡迎大家在評論區(qū)分享討論。
特別聲明：以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺(tái)“網(wǎng)易號”用戶上傳并發(fā)布，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。
反轉(zhuǎn)！留學(xué)女博士出軌致大流產(chǎn)續(xù)集，渣男玩太變態(tài)致子宮脫垂；還有吸毒致孩子死亡女主又又又發(fā)聲
法國騷亂進(jìn)入第五夜，人群洗劫大眾4S店開走汽車！裝甲車直升機(jī)緊急增援，司法部長警告，馬克龍最新表態(tài)
罕見 4GB 未拆封初代 iPhone 拍賣，預(yù)估成交價(jià) 10 萬美元
售價(jià)4萬美元、限量 24 臺(tái)，Caviar 定制高端蘋果 Vision Pro 頭顯
Canalys 預(yù)估蘋果 Vision Pro 頭顯五年累計(jì)銷量會(huì)超 2000 萬臺(tái)
COLORFIRE RTX 4060貓卡首測 功耗降60%性能升20%
