今天就来聊聊我们当初搞的那个“基路”项目。说起来那会儿可真是，一言难尽。
我们团队里头做项目，那叫一个五花八门。张三用他那套，李四搞他自己熟悉的，新项目一来，看负责人是谁，基本上就是一套新玩法。代码风格、工具选用、部署流程，全都不一样。每次交接或者有人离职，接手的人都得骂娘，对着那堆东西研究半天，还经常踩坑。
为啥要整这个“基路”？
导火索是有一次，一个挺急的项目，因为环境配置问题和依赖冲突，上线前一晚搞到凌晨三点多，差点耽误事儿。老板第二天脸都黑了，拍着桌子说：“能不能搞个统一的底子？ 每次都这么乱，搞毛！”
就这样，“基路”这个想法就出来了。意思就是，弄一个基础的、标准的开发框架或者说模板，以后新项目，尤其是类型差不多的，都从这个“基路”上开始走，别再自己瞎刨坑了。
我的实践过程
这活儿后来就落到我们几个人头上了。一开始也不是很顺利，大家想法多。
- 第一步：吵架，不，讨论。 先是拉着各个项目的负责人开了好几次会，收集痛点。你一言我一语，都觉得自己那套最别人的不行。吵了好几轮，才勉强统一了几个基本原则：比如日志怎么打、配置怎么管、基本的目录结构长啥样。
- 第二步：动手搭架子。 选型也纠结了一阵。我们没选什么特别新潮的技术，就挑了个大家相对都熟悉一点、社区稳定点的老伙计。关键是稳定压倒一切，别整那些虚头巴脑的。然后就是吭哧吭哧写代码，把讨论定的那些规范，用代码给出个样子来。什么数据库连接池，统一的异常处理，常用的工具类，都给封装
- 第三步：内部试用和找茬。 搭了个雏形出来，不能闭门造车。就找了两个关系还不错的兄弟团队，让他们的新项目试试水。果然，问题不少。各种吐槽，说这不好用那不方便的。我们就根据反馈，来回修改、打磨。这个过程也挺烦躁的，有时候改动大了，前面用的人又得跟着调。
- 第四步：文档和推广。 光有代码不行，得有说明书。我就负责整理了一堆文档，写清楚怎么用，有哪些约定，常见问题怎么解决。然后就是内部推广了，开了几次分享会，苦口婆心地劝大家用起来。
咋样了？
这个“基路”推行下去，也不是一帆风顺。总有人觉得束手束脚，或者觉得不适合他那个“特殊”的项目。但效果还是有的。
最大的好处是，新来的同事上手快多了，看一个项目，其他的也大概知道路数了。基础组件统一了，重复造轮子的事儿少了。因为规范相对明确，扯皮的事儿也少了一些。虽然离“彻底解决混乱”还有距离，但至少往前迈了一步，路面比以前平整了点儿。
现在回头看，当时搞这个“基路”，确实挺累人，协调沟通比写代码还费劲。但从长远看，这基础打一下，还是值得的。至少，以后再修路，起点能高一点，方向能准一点。
还没有评论，来说两句吧...