工作到现在的一些感想

最近工作方法上遇到一些问题。

一、换公司的感想

       面对这这些杂乱的sql代码，不知道他每一步要做什么，注释都写得那么吝啬（之前那个大佬你别惜字啊）。然后我突然想起了之前刚出来实习的时候，带我的那个人给我看的他们的sql代码。都是txt文件，开头有序号，有大概解释。给人的感觉非常的清楚，至少看注释是能看懂的。结束实习离开那家公司后，时间太久了我差点忘了这样的工作方法。今天碰到了问题才想起有这样的工作规范，可以用来借鉴减少自己的工作时间和成本。

       我在想，是不是大公司都有这样的清晰的文档习惯，你能看到的都是前面的人经过数次修改总结得到的工作结论，而不是一家小公司能给你的，还是实习的leader人好，愿意教给我这样的工作方法。

       一开始可以选的话，还是选大公司，像联调测试，SIT测试多部门合作这样的大规模测试，代码的编写梳理逻辑，文档的规范，这些能锻炼人的事情只有大公司才会发生，也可以给人开眼界。有些好公司流传下来的传统，不是网上查能查到的，只能在工作当中的文档，同事们的工作习惯能够体会到。如同当初实习leader给我看的那篇文档在这里看不到一样。

二、工作中的总结

       因为在工作中经常需要根据运营人员的需求取一些数据，有时候这些数据是有一个准确的参考值让你知道这个数有没有取对。

       比如说某某年的新客是多少，如果把新客按年龄段区分的话，加起来的人数一定是要等于该年的新客数。这种是如果加起来不对应的话，拉明细就可以找到原因。

       但是有一些不是这样，比如新客一个月后的复购率，这种按照实际情况能摸出大概取值范围的，比起第一种难一点，但是起码有个参考范围。真的错的话，就算查出某一拨人的明细，以此校验复购的脚本有没有算错。

       第三种是连一个参考范围都没有的情况。这种最麻烦。目前我碰到的问题中，有效的解决办法是靠人数。我做过的需求中大部分情况下会有人数的存在。

比如某一年求出新客中不同年龄的用户使用某产品的周期平均值：在计算的过程中难免要剔除一些不符合事实的用户，这个时候，可以根据每个条件剔除用户的数量，最终剩下多少数量，来初步的证明你的基础人数没有错。

至于最后的周期平均值如果不符合需求人员的期望，那么把不符合他们期望的值拿出来检查一下，检查明细先保证没有算错，然后看一下导致这个数值发生的原因，比如是1到3岁的用户数不应该那么多或者周期不应该比后面的用户长，那么这是时候你就要去找相关的明细，用户多的原因是不是大部分是尝试消费的人而不是我们概念中的用户；周期长的话就要判断是不是真的那么长。

碰到这种数据不对又不知道哪里不对的情况下，我会很烦躁很生气很抱怨，明细要重新写sql计算，又麻烦又讨厌。这个时候，通常就是你自己写的sql不合理：要么就是俄罗斯套娃临时表一个套一个，表名还是那种t1，t2这种没什么实际含义的表，要么就写的又杂又乱，排版还不好。所以以后临时表命名的时候最好取有含义的名字，你一眼就能看出是什么数据，另外套表不要套太多层，尽量3个表内解决你要的数。排放方面，很多工具都有排版功能，点一下又不会死。整洁的代码看起来才比较舒服，另外要写好注释，可以在开篇的时候用1 ，1.1，1.2来大致写清楚脚本的逻辑，先捋一捋思路，这样可以有效避免迷失在代码中。

        另外，熟练的应用sql技巧也是必不可少的，数量运用好case when，sum(case when ),left join和sum用在一起的时候 ，要看清楚是一对一还是一对多，能一对一尽量一对一，还有就是各种函数比如row_number，pivot等函数。对于日期20181101这样的数据，建临时表的时候这样的数据会被存储为int类型，在使用datediff这样的函数就要这样写

DATEDIFF(MONTH,b.date,cast(cast(a.Date as varchar) as datetime))--先转化为varchar再转化为datetime类型

       最后，作为一个目前工作为取数的人，要有忧患意识，平时要多注意一下，需求人员拿了这些数后怎么用，最后做出了什么东西，尝试往这个方向转，不能一直做一个写sql的

----20181224-----

最近老板在群上发了一条消息，大意是不要等活干，要自己主动去帮客户创造价值。看到的时候懵了一下，这怎么感觉像在说我。但我只是个小兵他应该关注不到我这里。我左思右想，我的工作就是需要等别人提需求我写sql，定位本来就是这样我要怎么主动找活干。实在想不出来，只能去整理之前之前的需求，希望从里面找到一些规律，判断需求人员他们要数据的趋势及范围，整理一下做个总结。我能想到的就这么多了。

做一份工不难，把一份工做好才难。