本人博客:http://chen-shang.github.io
在公司有幸自己搭建了一套项目,牛刀小试。挺感谢组长,在搭建的过程中他跟我分享了许多他以前的经验和教训。
** 搭建一个好项目的终极奥义是为了别人写代码的时候爽！！ **
你搭建的项目最终还是由其他人来开发业相关务代码的，所以要让别人在你框架上写的开心才行。
搭建项目这种事,在牛人眼里是最最基础和最最简单的事情了。对于我这样的初学者,搭建项目需要考虑的问题还是蛮多的,我第一次搭建项目也不是很熟悉,现在这次实战的经验做出以下总结。
如今 saas 项目已初具规模了,大家在这套框架上写代还是比较愉快的。
这篇文章只是搭建项目中需要考虑的情况和遇到的问题的总结,重在思想的概括,不涉及具体技术的使用。
主旨
- 项目的定位
- 使用技术的选择
- 搭建过程中考虑到的问题
项目定位
首先是项目的定位,也就是这个项目是为什么服务的?
你是给前端喂接口呢,还是与供应商对接呢?你是内网访问呢还是要把服务对外公开呢？
你首先要有一个清醒的认识那就是你做的是个什么东西。
我需要做的 saas 项目就属于一个给前端为接口的一个项目, vendor[我公司的其他项目组的项目,其主要职责则是与供应商对接然后对内提供基础服务的]则是属于与供应商对接的项目, HL(Hyperloop)[我公司的另一个项目组的项目,我也在里面呆过,也是里面的元老级人物了] 则隐藏在内网中不准备对外暴露接口的项目
清楚了我是要做一个喂接口项目,不是 web 项目,所以没有必要非得给应用加上 web 页面的功能,但要考虑到以后有可能会做扩展,未雨绸缪总是好的,开发过程中唯一不变的就是变化!
使用技术选择
做开发,用什么技术都能实现, 选择 scala 或者是 java 都行,选择 play框架或是 spring 框架也都行,关键在于你所处的大环境。往往有些时候,你学的和你用的技术往往都不大相关,就像我学汇编出身(因为我们专业就教这个),我工作后用 java(因为公司的前辈全都是java儿),我来北京分贝通后用 scala(因为之前的员工非常之讨厌 java 和非常之喜欢 scala 这门语言)。
我们最后讨论选择了
spring + spring mvc + mybatis + postgres
软件开发语言最终还是放弃使用 scala了(scala 的 slick 框架对事物的支持并不太友好,这个其他同事很是反感) 转而是用 java(毕竟好招人啊)
最终还是没有沿用 play 框架, 转而使用了 spring 那一套(还是大家之前都是 java儿,想都没想都想用 spring 了)
既然使用了 spring 那持久层自然选用呼声较高的 mybatis了
项目管理工具使用 gradle(因为我上一家公司就用这个,我还是比较熟悉,而且比较新,在我的强力要求下使用--其实是努力争取下)
数据库沿用公司其他项目使用的数据库 postgres 考虑到与其他项目兼容问题吧
搭建过程中思考的问题
鉴于其他项目组暴露出来的问题,争取在 saas 项目中避免
抽象的重要性就提现出来了
提供统一的接口来处理一些共性的问题，这样大家写的代码也比较整齐，不会对同一功能，你写一套，他写一套
1、既然是提供接口,那就得记得打印输出日志吧,日志系统需要健壮并完善
2、日志的requestid
3、http交互
4、测试框架
5、发版系统
6、全局参数,全局属性,配置文件读取
7、与其他系统交互是的鉴权
8、命名和编程风格
9、统一的异常处理体系
首先是日志这一块儿,一个良好的日志可以快速定位问题所在。选用 logback 来辅助, MDC 来生成全局唯一的 requestid,考虑到并打的时候,日志的打印是无序的,需要一个全局的 requstid 来将请求串联起来。
再就是这个系统肯定会于其他系统或后台交互,所以需要提供一套与网络交互的 api 方便其他同事使用
开发过程中,随手写测试是很重要的,mock 的技巧会使你轻松很多。
写代码中免不了会用到配置文件,提供一个公共的类来使用。
最后写好开发文档,像这些功能最好有一个详细的文档,当新同事来的时候可以快速入手,避免重复制造轮子,因为新同事来的时候项目已经很庞大了,没有人会一个一个类的去看你是做什么的,当他也需要读配置文件或者使用网络请求的时候很有可能就会按照自己的习惯和风格开始另起炉灶,导致系统越来越庞大。
总结
最后在在说一遍, 变化是唯一不变的事情！！尽量考虑到变化和扩展,我也只能尽力了！！加油