2017.9.1 0:26 昨晚在办公桌上码这篇博文不到50字
2017.9.1 0:52 坐上公司楼下约得拼车
2017.9.1 2:12 到家
2017.9.1 9:52 到公司
缺点
1.使用固定值
在测试环境的DB上开发，插入一些需要的固定数据，这些数据自增长的ID与实际DB中自增长的ID不同。但在开发的后台代码中使用了测试环境DB中自增长的ID……
2.没有准备脚本
新的模块，对DB的修改，没有准备用于生产DB的SQL脚本。幸运的是自己有记录工作过程的习惯，快速准备好了
3.命名冗长及随意
冗长：假设你定义变量表达【在XX活动期间注册且首次YY金额超过ZZ的好友数量】
我的命名是：
userFriendWhoRegisteredInXXActivityAndFirstYYMoneyMoreThanZZCount
我咨询了2个同事，都是以核心词汇“好友数量”命名，用注释来阐释形容限定词汇
随意：上面的命名我用“Money”不是“Amount”来表达金额
4.谨慎不足-修改即提交
以为很简单，将int修改成string，完成新的逻辑，却忘了还有地方用它和int类型来比较，不能用时间仓促来当借口
5.谨慎不足-数据的唯一性
从集合中取First()这个属性是1的数据，虽然做到了，但在真正生产环境下，是否First取到的就是这个属性是1的数据，在First前Where明确一下是否更好，起码更严谨
6.简化前后台接口结构
前台开发的方式多种多样，并不仅仅是Razor中嵌套C#，这次前台使用VueJs打包，在View中引用，没法集成后调试前端，过程变成了前端开发自己造简单的假数据，集成用的后台数据结构复杂（多级，类型多样），导致获取数据、想获取数组的length都费事
如果有些状态需要计算接口数据的个数和需要遍历获得，不如后端加一些冗余属性来记录，前端拿来直接使用
一般两级就好，尽可能是基元类型
7.日报坚持当晚完成进度总结
临走前也应该打开日报，校验一下今天的进度和是否一些备注
优点
1.深刻理解需求
不论是业务逻辑、DB、前端接口，在开动代码前，先理解需求，先沟通相关人员，不明白的地方都搞明白，在开发的时候能够清晰，在集成时调试能在产品上把关一下
2.积极配合前端
早晨来了索性抱着本做到前端身边待命
3.想要做更好的技术规范（sql脚本整理）
没有整理脚本，但整理后没有条件判断是否存在在CURD，找到前辈的脚本，规规范范的模仿，数据库和字段都加了[]，校验if not exists, sql语句换行变得好看
4.愿意待在公司一起到凌晨
与上家公司朝9晚6但需要的时候晚9、10点相比，我更喜欢现在早晨9：30弹性到10点，晚上年轻人在一起有交流做事
我也明白了一件事，我的存在，即使再怎么激情，也无法和一个老人大多数时在加班做事相比，如果真的想成为骨干，想学那些我不懂的，我需要加班
5.不以太晚为理由
今早有偷懒的想法，起床想再睡会，晚点去，但还是起了床，不能以太晚下班为理由，明明身体心理都都可以做得到，而且凌晨走的我们4个人才仅有一个人迟到了
见识
抓包的测试，测试在抓包
前端后台开发，如果接口命名不好，也不能一个人去Rename, 如果模块又赶上紧急上线，或者是开发人员焦头烂额状态不好也不愿意去再看……