我们平时都调侃着，面试的时候在造飞机，工作的时候就在拧螺丝，然后我就想着哪天能写一写自己一天的工作，虽然大多数也是在拧螺丝，但偶尔也会有些浪花。
上午
起床一直都是一件困难的事，但班还是要上的，起！洗漱下，烧杯热水，然后随手拿本书，出发去地铁站，虽然带了本书，通常是看不了的，因为人挤人啊，眼镜在包里都挤断了两次。到达公司在小卖店买碗糊辣汤，加上两个包子差不多9点能打卡到工位上，然后边吃早饭，翻翻书，等着开晨会。晨会小组简单总结下昨天做了什么，哪些还没有解决，今天做什么。
开始编写代码
开完晨会之后开始写代码，代码主要分为两大部分，一个是后台，一个是给app等客户端的接口。为了节约成本，我们的测试环境通常是一个机器上布署了好几个应用，经常出现内存不足程序挂掉的现象，可能有些小伙伴以为要搞jvm分析调优了，其实并没有，打开secureCRT,进到服务器，ps aux | grep $应用名 看看应用名是不是真得挂了。真挂了，就上jenkins重启下应用。当然测试环境也不是说几分钟挂一次，一般来说坚持个两三天还是不成问题的。
如果不是服务挂了，这个时候要进到具体应用目录，我们应用都是打 war包，用tomcat进行布署，所以这时候进到tomcat/logs/目录下，用tail -100f catalina.out日志，看看是不是哪里异常了，根据Exception的提示看看是哪里错了，很多时候都是祖传老代码，好长时间没有人修改过的，所以一般也就是依赖别人的服务挂了，或者缓存/数据库出了问题，别人的服务就在群里面发下接口，问问谁的，然后那个人重复上面的操作。数据库出错的可能性不大，很多时候是redis 出了问题 测试环境为了节省资源，一台机器用不同的端口启动了好几个redis实例，如果是redis服务停掉了，就重启，如果是里面的值有问题就 get key取到对应的值，看看是哪个数据出了问题，然后对照代码看看是不是set的时候出了问题，然后del key清掉错误的数据让对方再试一遍。 如果以上还查不出问题，那就先喊一句：我的接口怎么可能会有问题，一定是你调错了！撑撑场面，然后让对方把请求的url+参数 或者接口名+参数或者app/客户端操作步骤。启动本地应用，根据不同的类型准备不同的debug姿势
http类型的
get请求就直接在浏览器里面粘贴url+参数，代码log级别调到debug，这样可以看到执行的sql语句然后代码对应的地方打断点，一步一步看看值都是怎么变化的
接口名+参数
这种一般是dubbo接口，这样如果涉及到多个项目还真不好本地联调，只有写单元测试,在最开始开发的时候就要做到对每个接口都有单元测试，然后找到这个接口的单元测试，然后把对方反馈的参数复制到单元测试里面，然后打断点，看看值是怎么变化的
app/客户端
这个就稍稍麻烦点，要先打开一个代理软，charles如果是ios的话，因为现在ios限制只能调用https的接口，还要配置ssl代理，所以一般我都是找android机进行测试，如果android正常，那就是ios开发的问题，如果两端都有问题，则就是接口的问题
这样差不多解决了问题，然后开发新功能，写单元测试，整理文档给app，周而复始
偶尔的浪花
有些小伙伴看到上面这些之后，肯定深有同感，对，每天都是在做这些重复的事，这就是做业务开发，先把功能完成。但是我们要善于把手上的业务代码不断进行优化，如调的接口多了，是否可以改成future,completablefuture.？某一段代码到处都在重复，是否可以单独提一个方法出来？我们都知道新建一个线程池有不小的开销，那是不是可以用工厂模式做一个线程池的工厂？在接收到一个更新消息时，要去很多系统去更改缓存/别的存储是否可以从 Manager.method改成观察者模式？是否可以对当前贫血实体类进行下领域划分，把一些操作并到RichModel中？
总结
我们的工作大都在编写代码那部分，但并不意味着业务代码是工作的全部，如上段的浪花，研究起来还是挺有意思的，代码这条路很好玩，更多的应用场景欢迎大家一起来讨论！
小编还整理了很多经典的java、python学习资料及路线，需要的小伙伴们可以加微信15513541542免费领取！希望对你们有所帮助。
