剛進(jìn)公司就負(fù)責(zé)項目，把老弟整蒙了！

大家好，我是魚皮，先把封面圖送給大家：

又快到周末了，今天分享一些輕松的編程經(jīng)驗(yàn)~

還記得我學(xué)編程的老弟小阿巴么？他目前大二，聽說最近剛剛找到了一家創(chuàng)業(yè)公司的暑期實(shí)習(xí)。

前兩天小阿巴又跑來向我訴苦了：魚皮 gie gie，我不是找了份暑期實(shí)習(xí)嘛，結(jié)果還沒到暑假呢，公司的老大就聯(lián)系我了，說公司最近有很多新項目要啟動，等我暑假再來準(zhǔn)備估計來不及了，讓我提前先調(diào)研一下新項目的技術(shù)選型。

魚皮：這不是挺好的么？還沒進(jìn)公司，就已經(jīng)成為項目負(fù)責(zé)人了哈哈。

小阿巴：好個毛 🥚 啊，以前我自己都是跟著網(wǎng)上的教程學(xué)做項目，把老師的代碼拉下來改幾下，這讓我負(fù)責(zé)一個項目，我一點(diǎn)底氣和思路都沒有。還有他說的什么 “技術(shù)選型”，我都沒聽說過！徹底蒙圈了。。。

魚皮：嗯，這確實(shí)是個問題，看來得跟你科普一下 “技術(shù)選型” 了。先考你一下，你知道什么是技術(shù)選型么？

小阿巴：emm，我猜就是用什么技術(shù)來開發(fā)這個項目？比如開發(fā)前端用 Vue、開發(fā)后端用 Spring Boot？

魚皮：不錯，如果把做項目比喻成打仗，那么技術(shù)選型就相當(dāng)于打仗之前選擇武器。你要選擇合適的武器才能打勝仗，選擇合適的技術(shù)才能更好地完成項目。

小阿巴：但有個問題，現(xiàn)在主流的開發(fā)技術(shù)不就那么幾種么，像我上面說的 Vue、Spring Boot？有啥好選的？

魚皮：你說的其實(shí)只是技術(shù)選型的其中一點(diǎn)，也是最淺的一層。技術(shù)選型不止有 “選擇開發(fā)框架”，還包括很多不同的方面和細(xì)節(jié)。

由淺入深來看，技術(shù)選型包括：

1）用哪類技術(shù)？比如編程語言、開發(fā)框架、數(shù)據(jù)存儲、緩存

2）具體用什么技術(shù)？比如編程語言用 Java 還是 Go？開發(fā)框架用 Spring 還是 Netty？緩存用 Redis 還是 Memcached？

3）技術(shù)用哪個版本？比如用 Java 8 還是 11？Vue 2 還是 Vue 3？Redis 5 還是 6？

4）具體用到哪些技術(shù)特性？比如 Spring 的 AOP、Redis 的 GEO 高級數(shù)據(jù)結(jié)構(gòu)等。

小阿巴：我滴媽呀！這么復(fù)雜嘛，我之前根本沒想過這些，好像也想不到。。。

魚皮：這是很正常的，因?yàn)橹澳愣际亲约焊坛套鲰椖?#xff0c;用什么技術(shù)、用哪個版本都是老師給你提前規(guī)劃好的。

小阿巴：確實(shí)唉，我覺得有點(diǎn)太麻煩了。。。能不能不做技術(shù)選型呀！老夫直接用 Spring Boot + Vue 一把梭。

魚皮：哈哈，技術(shù)選型當(dāng)然不是絕對的呀，比如你在學(xué)校自己做項目，那你就用熟悉的技術(shù)或者想學(xué)的技術(shù)即可。但是等當(dāng)你進(jìn)入企業(yè)、尤其是負(fù)責(zé)項目時，就必須要跟團(tuán)隊同學(xué)一起確認(rèn)技術(shù)選型。而且對于規(guī)模越大、越復(fù)雜的項目，你要考慮的技術(shù)選型的角度和深度要求就越高！不能再像自己做項目一樣隨便了。

小阿巴：我就隨便，又怎樣？

魚皮：可以的，我看你是不到黃河心不死不見棺材不落淚欲窮千里目更上一層樓啊！給你講講我在學(xué)校的時候有次帶團(tuán)隊做項目時，不做技術(shù)選型的翻車經(jīng)歷吧。

很多年前了，當(dāng)時我們在做一個校園貼吧網(wǎng)站，記得我是用 React 來開發(fā)前端頁面的。剛開始很順利，但直到有一天需要開發(fā)帖子頁面信息狀態(tài)保存功能的時候，才發(fā)現(xiàn) React 不像 Vue Router 一樣有現(xiàn)成的 keep-alive，后來又花了好久才找到一個類似的組件，結(jié)果還一堆 Bug。。。

唉，當(dāng)時確實(shí)是經(jīng)驗(yàn)不足呀。如果最開始就考慮到這點(diǎn)，選擇 Vue 系列技術(shù)棧，那么就能節(jié)省很多時間了。

小阿巴：我悟了！就是說在開發(fā)一個完整項目前，我們要先整體思考一下實(shí)現(xiàn)項目功能可能會用到的一些技術(shù)，這樣不至于到后面才發(fā)現(xiàn)難以實(shí)現(xiàn)？

魚皮：good，是這樣。越是對項目侵入性強(qiáng)的技術(shù)，后期的改動成本就越大。比如我剛剛舉的例子，等你頁面都寫了幾十個了，再去切換開發(fā)框架，就會很麻煩；而且有的時候，你給項目引入新的組件或類庫，可能會和現(xiàn)有的庫版本沖突，導(dǎo)致后面項目跑不起來。這些其實(shí)都是技術(shù)選型不當(dāng)帶來的問題，也是我們做技術(shù)選型的必要性。

小阿巴：原來如此，那做技術(shù)選型有沒有什么好的經(jīng)驗(yàn)?zāi)?#xff1f;

魚皮：一句話，我們做技術(shù)選型的目標(biāo)是 在有限的條件下、選取特定場景下的技術(shù)最優(yōu)解。

有限條件包括我們團(tuán)隊同學(xué)會的技術(shù)、我們的時間和金錢成本。比如大家都只會 Java、項目又急著上線，那肯定優(yōu)先選擇 Java 相關(guān)技術(shù)棧，不要因?yàn)槭裁?Go 語言的性能高就讓大家加班去學(xué) Go。再比如公司很有錢，但是缺人手，那么很多服務(wù)（比如數(shù)據(jù)庫）就不用自己搭建了，直接買大廠云服務(wù)即可。

特定場景是指我們的技術(shù)選型一定要圍繞著業(yè)務(wù)和需求來做，可以思考以下幾點(diǎn)：

1. 你的業(yè)務(wù)量級有多大：如果用戶數(shù)巨多，要不要用 Nginx 或者 LVS 來做個負(fù)載均衡？如果存儲量巨大，要不要使用分布式數(shù)據(jù)庫、要不要搞分庫分表？
2. 系統(tǒng)的核心業(yè)務(wù)流程和關(guān)鍵數(shù)據(jù)結(jié)構(gòu)是什么？比如要做一個管理系統(tǒng)，那么數(shù)據(jù)庫選擇主流的關(guān)系型數(shù)據(jù)庫 MySQL 就好。而如果要做數(shù)據(jù)分析系統(tǒng)，那么應(yīng)該選擇 OLAP 利好的數(shù)據(jù)庫，比如 Postgre SQL、ClickHouse 等。
3. 系統(tǒng)更注重哪些性能？比如日志收集的場景更注重高性能和吞吐量，那么可以選擇 Kafka 消息隊列來采集；比如注重低延遲以及消息的準(zhǔn)確性，那么可以選擇 RabbitMQ 等。很多時候，我們做技術(shù)選型和設(shè)計算法一樣，沒有絕對的最優(yōu)解，而是對時間、空間、穩(wěn)定性、可用性等等的綜合權(quán)衡。

小阿巴：大哥，我悟了，您別念了！

魚皮：哈哈，另外還有兩個建議

1. 做技術(shù)選型時，可以通過編寫最簡單的 Demo 來快速驗(yàn)證下技術(shù)是否可用，不要直接拍板！
2. 原則上優(yōu)先選擇知名度高的、開源的、用戶多生態(tài)好的技術(shù)，沒幾個人用的技術(shù)，估計你用的話就是踩雷去了。

小阿巴：我明白了，那我就先問清楚我們這個項目大概要做哪些功能、預(yù)計有多少用戶和存儲需求，再根據(jù)這些到網(wǎng)上搜技術(shù)選型！

魚皮：糊涂啊！都 2023 年了，直接問 ChatGPT！

我的編程導(dǎo)航網(wǎng)站：https://www.code-nav.cn