刚进公司就负责项目，把老弟整蒙了！

又快到周末了，今天分享一些轻松的编程经验~

还记得我学编程的老弟小阿巴么？他目前大二，听说最近刚刚找到了一家创业公司的暑期实习。

前两天小阿巴又跑来向我诉苦了：鱼皮 gie gie，我不是找了份暑期实习嘛，结果还没到暑假呢，公司的老大就联系我了，说公司最近有很多新项目要启动，等我暑假再来准备估计来不及了，让我提前先调研一下新项目的技术选型。

鱼皮：这不是挺好的么？还没进公司，就已经成为项目负责人了哈哈。

小阿巴：好个毛 🥚 啊，以前我自己都是跟着网上的教程学做项目，把老师的代码拉下来改几下，这让我负责一个项目，我一点底气和思路都没有。还有他说的什么 “技术选型”，我都没听说过！彻底蒙圈了。。。

鱼皮：嗯，这确实是个问题，看来得跟你科普一下 “技术选型” 了。先考你一下，你知道什么是技术选型么？

小阿巴：emm，我猜就是用什么技术来开发这个项目？比如开发前端用 Vue、开发后端用 Spring Boot？

鱼皮：不错，如果把做项目比喻成打仗，那么技术选型就相当于打仗之前选择武器。你要选择合适的武器才能打胜仗，选择合适的技术才能更好地完成项目。

小阿巴：但有个问题，现在主流的开发技术不就那么几种么，像我上面说的 Vue、Spring Boot？有啥好选的？

鱼皮：你说的其实只是技术选型的其中一点，也是最浅的一层。技术选型不止有 “选择开发框架”，还包括很多不同的方面和细节。

由浅入深来看，技术选型包括：

1）用哪类技术？比如编程语言、开发框架、数据存储、缓存

2）具体用什么技术？比如编程语言用 Java 还是 Go？开发框架用 Spring 还是 Netty？缓存用 Redis 还是 Memcached？

3）技术用哪个版本？比如用 Java 8 还是 11？Vue 2 还是 Vue 3？Redis 5 还是 6？

4）具体用到哪些技术特性？比如 Spring 的 AOP、Redis 的 GEO 高级数据结构等。

小阿巴：我滴妈呀！这么复杂嘛，我之前根本没想过这些，好像也想不到。。。

鱼皮：这是很正常的，因为之前你都是自己跟着教程做项目，用什么技术、用哪个版本都是老师给你提前规划好的。

小阿巴：确实唉，我觉得有点太麻烦了。。。能不能不做技术选型呀！老夫直接用 Spring Boot + Vue 一把梭。

鱼皮：哈哈，技术选型当然不是绝对的呀，比如你在学校自己做项目，那你就用熟悉的技术或者想学的技术即可。但是等当你进入企业、尤其是负责项目时，就必须要跟团队同学一起确认技术选型。而且对于规模越大、越复杂的项目，你要考虑的技术选型的角度和深度要求就越高！不能再像自己做项目一样随便了。

小阿巴：我就随便，又怎样？

鱼皮：可以的，我看你是不到黄河心不死不见棺材不落泪欲穷千里目更上一层楼啊！给你讲讲我在学校的时候有次带团队做项目时，不做技术选型的翻车经历吧。

很多年前了，当时我们在做一个校园贴吧网站，记得我是用 React  来开发前端页面的。刚开始很顺利，但直到有一天需要开发帖子页面信息状态保存功能的时候，才发现 React 不像 Vue Router 一样有现成的 keep-alive，后来又花了好久才找到一个类似的组件，结果还一堆 Bug。。。

唉，当时确实是经验不足呀。如果最开始就考虑到这点，选择 Vue 系列技术栈，那么就能节省很多时间了。

小阿巴：我悟了！就是说在开发一个完整项目前，我们要先整体思考一下实现项目功能可能会用到的一些技术，这样不至于到后面才发现难以实现？

鱼皮：good，是这样。越是对项目侵入性强的技术，后期的改动成本就越大。比如我刚刚举的例子，等你页面都写了几十个了，再去切换开发框架，就会很麻烦；而且有的时候，你给项目引入新的组件或类库，可能会和现有的库版本冲突，导致后面项目跑不起来。这些其实都是技术选型不当带来的问题，也是我们做技术选型的必要性。

小阿巴：原来如此，那做技术选型有没有什么好的经验呢？

鱼皮：一句话，我们做技术选型的目标是 在有限的条件下、选取特定场景下的技术最优解。

有限条件包括我们团队同学会的技术、我们的时间和金钱成本。比如大家都只会 Java、项目又急着上线，那肯定优先选择 Java 相关技术栈，不要因为什么 Go 语言的性能高就让大家加班去学 Go。再比如公司很有钱，但是缺人手，那么很多服务（比如数据库）就不用自己搭建了，直接买大厂云服务即可。

特定场景是指我们的技术选型一定要围绕着业务和需求来做，可以思考以下几点：

1. 你的业务量级有多大：如果用户数巨多，要不要用 Nginx 或者 LVS 来做个负载均衡？如果存储量巨大，要不要使用分布式数据库、要不要搞分库分表？

2. 系统的核心业务流程和关键数据结构是什么？比如要做一个管理系统，那么数据库选择主流的关系型数据库 MySQL 就好。而如果要做数据分析系统，那么应该选择 OLAP 利好的数据库，比如 Postgre SQL、ClickHouse 等。

3. 系统更注重哪些性能？比如日志收集的场景更注重高性能和吞吐量，那么可以选择 Kafka 消息队列来采集；比如注重低延迟以及消息的准确性，那么可以选择 RabbitMQ 等。很多时候，我们做技术选型和设计算法一样，没有绝对的最优解，而是对时间、空间、稳定性、可用性等等的综合权衡。

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

鱼皮：哈哈，另外还有两个建议

1. 做技术选型时，可以通过编写最简单的 Demo 来快速验证下技术是否可用，不要直接拍板！

2. 原则上优先选择知名度高的、开源的、用户多生态好的技术，没几个人用的技术，估计你用的话就是踩雷去了。

小阿巴：我明白了，那我就先问清楚我们这个项目大概要做哪些功能、预计有多少用户和存储需求，再根据这些到网上搜技术选型！

鱼皮：糊涂啊！都 2023 年了，直接问 ChatGPT！