某个程序员的工作记录

一直工作都没有过记录，经历了什么，时间长了就都记忆模糊了，经验指的就是记忆，忘了就相当于白做了。决定把工作都记录下来，作为以后的参考。

11月18日
新入职了一家公司，公司的平台是做小游戏平台的，我是做后台开发的。主要是统计会员数据（用户的活跃数量、用户任务、用户排名、评论、用户金币、提现金额），暂时只知道这些。分配给我的任务是将验证码换成阿里云的短信验证码，
提现的时候增加将账号绑定手机号如果已经绑定就校验是否是原来的手机号，如果不是，就不通过；给2天，3天，7天，15天的不登录的会员发送消息，并统计召回率，退订数量。问题的难点是：代码不熟悉，数据的处理，要兼容原有的数据；阿里云的依赖包下载不下来；统计的数据放在哪里及表的设计。

11月19日
今天把定时发短信及查询召回率写完了，虽然没有多少，但也花了一个上午，效率要提高啊。下午碰到创建分支，使用jenkins及springboot启动时使用配置文件的问题，都不太熟悉。

11月20日
今天测试了下短信发送的接口，把定时功能移动到新项目中。有一个双色球的游戏需求，随机生成5个红球（不统计顺序），随机生成一个篮球，后台生成一个中奖号码并统计奖金，保证奖金不会超出范围，表还没设计完呢。

11月21日
今天测试下定时发短信的功能，发现java的Localdate 对应mysql的date类型，offsetdatetime 对应 datetime , timestamp，以前还真没有注意，今天特意试验过，确实是这样的。写了保存中奖号码，查询上次选择的号码及返回选号及中奖号码或者距离开奖的时间。还有号码开奖的一些细节没处理好。

11月22日
今天把双色球写完了，主要包括生成号码，这个要考虑并发生成，重复生成的问题，请求参数的校验，定时生成开奖号码，这个是用了forkjoin框架，通过分治算法完成的，不过，统计买的号码在生成开奖号码，数据量大，需要多次查询表，如果遇到号码冲突，就要重新生成，数据又要重新查询，目前还没有想好怎么处理这个问题，减少查询次数或减少冲突情况。

11月23日
今天没做什么，代码测试了，改了改。下午使用了Feign做接口调用。

11月24日
调试了接口，

11月27日
调用进程的接口时做好异常处理，即时接口本身不抛异常，也要try catch下异常，因为本身网络连接方面的问题就很多。

11月28日
今天写微信app支付的接口，是调用微信的接口。流程：app端用户下订单，请求后台生成订单，后台调用微信统一下单api接口，获取到微信的返回值后，生成签名并返回给app端做支付信息。用户确认支付，app端调起微信客户端发起支付请求，微信客户端向微信支付系统发起请求，微信支付系统验证权限后，返回需要的支付权限，用户确认密码后，微信客户端提交支付权限，微信支付系统验证权限，完成交易。
微信支付系统异步通知后台系统，后台系统保存支付结果，并返回已经接到通知的信息给微信支付系统。微信支付系统返回支付结果给微信客户端。
微信客户端将支付结果通过app客户端的回调接口执行回调，如果app没有拿到支付结果，可以通过后台查询支付结果，后台先查询订单是否支付，如果没有支付，调用微信支付系统查询支付结果。后台获取支付结果后，返回给app端，app端将支付结果展示给用户，并发货。
微信接口传的是xml的数据，因为有demo，调接口并不难。

12月1日
项目上线会影响一些定时任务，增加一个表记录定时任务的执行情况，只限定每天执行一次的定时任务，项目启动时查询表，如果表的记录时间不是当天，程序就调用相应的定时任务执行。

12月5日
今天线上有个bug，一时没有定位出来，原因是没有合代码，本地看代码发现不了，昨天代码评审没有仔细看代码，没有发现代码中的错误。
还有一个突然出现的bug，主要是受之前别的代码的影响，觉得静态变量就要直接引用，没有用spring框架的IOC功能，导致出现null值，而且改bug时一直没有忘IOC这方面想，直到同事提醒我才想起来。
还有一个问题是重构了一个测试项目，结果部署时报错了，之前没有好好测试，因为没有改动，是直接迁移的。今后要认真对待每一件事情。
中午学习了一个产品的发展，做一个产品，要考虑行业的定位问题（如果是行业领头人，对拉投资或卖公司或发展都是有优势的），产品流量的问题（引流，这块找个好渠道，便宜的，把流量引过来，转化这些流量），产品设计的问题（有针对性的定位用户，让花钱的用户得到更好的服务，引导用户花钱）、技术问题减少资金投入。

12月6日
今天调试一个bug，参数要传文件，开始是部署了再测试，很浪费时间，后来找了极客工具，可以模拟请求发送各种数据，很快就调通了。

12月7日
今天写了调用阿里云的验证身份证和姓名的接口，做了防重复调用接口，就是在表里计数，超过3次就返回失败，表中已经存在身份证也不验证。

12月10日
今天测试了写的接口，出现很多比较初级的错误，表结构中主键id 设计的是自增的，但确忘记写auto_increment ，好几个表都写错了，还有表的字段和代码字段不一致。代码返回值格式不一致，导致还要修改，接口文档写的不全，浪费了时间。

12月11日
今天一个计算秒的方法出现问题，一段时间内数据不变，当时是debug代码，没有发现问题，应该是分析思路的问题，首先方法返回数据是有问题的，有时候返回不正确，应该分析这个方法是做什么的，然后具体分析每一步是不是完全符合方法的目的，部分正确说明某些情况下是不符合预期目的的。这个分析问题的方法要谨记。

12月12日
今天合了代码，改了个bug，看了些需求文档，感觉没有做什么事情，需要提高工作效率，该想想哪方面不足，努力改变。

12月16日
创业，做一个产品，前期最好参照相同的产品，资金少，做的复杂一个是可能还是做不过对手，二是可能把自己搞死。用户的开发，留存（3日留存，7日留存，15日留存，30日留存…），研究一些成功企业的数据，找到一个数据比较的标准。新增用户的花费及用户带来的收益，用户的需求，怎么吸引用户。
toC产品面向的用户不是很理性，数量的微小差异都可能带来后期巨大的差距。

12月23日
最近用户量上来了，大概每天50万dua，晚上服务器很卡，运行不流畅，服务器大概9台，按道理是可以承受住的。问题不少，之前看到了分布式锁阻塞的问题，还有就是redis的配置问题。redis的线程配置的比较少，服务器及用户量上去了，就不够用了，出现阻塞的情况。用户量上去后，注意排查下代码及配置，可能之前的配置已经不适合现在使用了。

11月29日
之前的一个问题，记录下来。服务报404的问题，一般是接口不正确，还有可能是服务器挂了导致的，还有就是协议的问题，分布式服务用代理，有些是要求https协议的，找不到会返回404.

11月30日
最近做活动模板及自动审核的功能。活动模板，包含多个模块功能，可以组合各个功能，包括消耗金币兑换抽奖，每日领取抽奖，邀请好友兑换抽奖，抽奖这个功能包括抽奖权重、奖品数量、抽奖需要的贡献值，中奖减少的贡献值，除抽奖外其他功能都设置贡献值的获取，最后一个模块是奖品设置，还有一个排行榜的显示。难点是，需求之前不是太清晰，奖品是每日有设置数量的，其他的也都有限制，接口的访问权限也是要校验的.
自动审核：做一个设置每日自动审核用户余额提取的一个开关，可以在页面上手动操作开启或关闭审核，还可以调整额度上限。

2019年1月5日
这周主要测试了下自动审核的功能，修改判断条件，增加了通知钉钉的功能，其他的错误，一部分是异常场景的考虑遗漏了，还有就是返回值判断没有考虑全，查询可能出现返回null的情况。

2019年1月10日
修改了自动审核，额度的修改，对关闭时线程的处理，其他的一些bug的修改，支付修改了渠道号。代码写完了最好看一遍，对着需求来看，看看需求是否全面，或者代码是否能够在场景中很好的处理事情。

2019年1月12日
今天表添加了一个字段，在mybtis的xml查询语句中忘记加字段了，结果一直没有返回改字段，找很久都没有发现。总结一下，分析问题的思路是有漏洞的，如果结果又问题，就应该找问题发生的地方，然后再沿着轨迹查找，这才是正确的查找问题的思路。

2019年1月14日
今天碰到一个double转int的问题，试了好几种方法，发现自己对java的基本类型理解还是不够深入，要学习一下。

2019年1月27日
总结一下去年的工作吧。功能方面，按照需求来写，没有自己去研究，这个是不足，做功能要研究需求是不是合理及完善，要不很肯能要返工；对功能的使用，redis出错，这个是不是必须要用redis，用其他的行不行。

2019年1月31日
最近做了活动模板和审核支付的功能，测试中发现不少的bug是写代码中遗漏忘记写导致的。找错误的代价一定比写代码的代价要大。提高工作效率：完成一个功能后，要检查完成的功能，检查方法：根据需求查看功能有没有实现，功能中的参数的值是不是符合代码的需求的，从哪里来的，异常情况有没有考虑并处理。

2019年2月12日
今天修改了部分的bug。功能最好一个功能点一个功能点检查，列出需求的功能点，检查功能点及相关的变量是否 能完成预期的 功能。

2019年2月17日
这周工作主要是改了些bug，测试下并发性能。并发主要是用线程池来降低阻塞，因为mq要收钱，所以就没用mq。

2月24日
这一周在改抽奖这个功能，压测的并发量很多，才80多。将重新抽奖的次数减少为2次，并发量提升了2.5倍，后面有加了不限数量的判断和数量为0的判断，估计应该能达到300吧。有一个打卡分奖金的新需求，目前只写了部分表结构和接口名称。

3月23日
今天被公司开除了，理由是项目开发时间太长了，还一个是之前的支付功能微信返回系统错误会重复支付。总结一下：开发时间长是事实，一个是app端要等我开发好接口后才写， 这导致研发时间拉长了，开发的工作其实比其他地方要多，还要保证没有设计方面的bug，这个公司的测试只是性能测试，黑盒的，而且是不写测试案例，不看需求文档，直接测试的，无法保证全部测试到各个场景，开发需要自己测试或考虑到这些。产品是个新来的，不清楚这边的情况。看了微信文档，并没有说返回系统失败，会可能支付过了的情况。这个测试当时没有测试到这个场景，不过这个功能我接手之前就这么用的，然后我接手这个事情，因为没有测试到，背了这个锅了。
总结一下：支付或者充值这类和金钱相关的，仔细看文档，文档说明不清晰的要多查看，一定要每一个都测试到，这样会安全一点。
开发这块尽量保证设计好，减少修改次数，逻辑没有问题，写完后自己测试好，接口要写清楚；其实最好的还是对好接口，可惜前端都不喜欢这么干。