剛進公司就負責項目，把老弟整蒙了！

2023-04-27 10:41 作者:程序員魚皮 0人讀過 | 我要投稿

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

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

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

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

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

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

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

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

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

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

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

由淺入深來看，技術選型包括：

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

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

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

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

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

魚皮：這是很正常的，因為之前你都是自己跟著教程做項目，用什么技術、用哪個版本都是老師給你提前規(guī)劃好的。

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

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

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

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

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

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

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

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

小阿巴：原來如此，那做技術選型有沒有什么好的經(jīng)驗呢？

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

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

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

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

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

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