大雪纷飞的日子
铭记今日，2018年12月六日。今日大雪纷飞，从昨日已经开始雪花飘落，公司的一位“胡建”的小哥哥看到雪那叫一个兴奋呐！哈哈哈，今天的雪比昨天更大一点，今天发生的事也比昨天大一点。
1.最近我的代码要上线
11月中旬开始开发公司的新的业务模块，一个pc端的springboot项目，因为我现在是实习生还未毕业，能力没有那么好。加上新项目，里面的坑实在是太多了，一次上线四款保险产品，其中一款真的是业务逻辑复杂的要命。首先它有三个状态，保单状态，审核状态和支付状态。保单状态有4种，审核状态有4种，支付状态2种，还有退保退费状态。组合起来。。。。（此处捂脸表情）
2.踩坑之路
其他三款产品还好，审核通过之后不许修改了。但是有一款是反反复复的修改，各种改，状态五花八门。。。然后需求也跟着变更。心态在开发途中一路 boom、boom、boom 。后来还要兼职修改excel文档格式。。。然后大约开发加测试后端的接口终于在今天测试通过可以上生产了。然而刚刚开始最坑之路。。。
3.现有svn开发短板
- 目前公司开发的模式有瓶颈，开发是在trunk上一条线开发，然后后端的小伙伴都在这个分支上开发提交，所以当有的feature可以发布测试的时候就会把别的小伙伴的代码带到测试上去，然后大概率出现测试环境服务器没有开发环境的配置文件，这时候大多数为了图方便就会把自己的配置文件先加到测试上去，因为这样不用修改trunk上的代码了，所以把配置文件加一下，然后这些本来不应该带到生产环境的代码就被带上去了。
- 还有一种情况，是你发测试的是你从trunk上的代码，然后在测试线测试了好几天然后在这中间又有其他的bug或者新的feature要上线，这时候你的测试环境的代码并不包含这部分代码，然后当你这个feature上线的时候可能会把别人的代码冲掉，只保留你的feature的代码，这就导致功能不全的问题。当然，你也可以把生产的代码拉下来然后和测试环境的compare一下，但是这其中很大可能是很多人都动过这部分代码，然后时间一久就不知道哪个该上哪个不该上了。所以根据墨菲定律来说，100%会出问题。
4.最新的方案
我们公司特别厉害的CTO和我们目前的后端的老大，在讨论了一天的情况下定出了一个方案。把trunk净化一下，然后以后开发新的feature从干净的trunk上拉出一个branch来作为一个新的feature开发。这样就会有点小问题，就是一个人负责多个feature时，本地要同时跑多个项目，但是这样会避免同事之间代码冲突问题。当你的feature发测试时，直接把branch的代码发到测试，等到测试通过之后把代码merge到trunk上面。然后立即打tag，然后再用几个核心的测试用例把merge后的tag代码测试一下，然后没问题直接发布生产。
这样的好处是你的代码完全隔绝了别人的feature，不会导致你的代码把别人的代码冲掉的问题。
