大家好，我是风控老骑士陈Sir。
一转眼，今天是十月一号国庆节了，首先祝各位各位童鞋国庆节快乐~
感谢大家一直以来的关注。
我是一位模型工程人员出生，最开始做的数据分析工作并不像现在的很多同学一样，我最开始接触到的并不是python或者sas这类数据分析工具类。第一门启发我的数据类的工作，仍然是最古老的excel报表。当时部门的数据分析任务繁重，凭着对数据的无限热爱(wu nai)，我使劲倒腾各种报表函数，那时以为数据原来如此简单。来来去去不外乎是各种count，sum，if，以及匹配神奇vlookup。当时看到培训课程上，某位老师出神入化地做各种报表统计，当时以为那个就是我的顶，真的是too young too simple。
再后来随着工作的需要，又接触到代码类的内容，其实就是专职写代码取数，sql报表那种。应该也是很多数据分析类同学的第一份工作，简单如此，每天基本都是接触各类的取数需求。取数不难，sql大家都会写，做得取数时间久了，日益感到价值不大，每天救火员的工作也让自己看不到职业的前景。当时写了两年的sql，我对身边的人说以后别让我敲sql代码，见了它，我都会🤮但sql真的是了解业务的好帮手，因为在你连接各种表的时候，其实就是熟悉业务最好的时候。只有熟悉业务的情况下，表的各种连接才能用对应的主键关联好。
实际业务的中的表连接，不似那本《sql必知必会》那样如此友善。记得那个数据分析的段子内容吗？实际的业务分析的确如此。
出现这个情况的主要原因，公司是在业务的前期，企业都不愿意花精力，也不善于做数据管理，导致待业务量爆炸后，总会留下来各种数据治理问题，让后人苦不堪言。
至于sql，当时我也以为已经很6，表间连接，循环以及开窗函数基本都烂熟于心。直到我遇到一些不一样的代码写法，那一次我真正了解到原来代码还有非常不一样的写法。比如
“selet * from t1
wher 1=1
and …”
为什么要使用1=1？这看起来不是画蛇添足么？当时问了习惯写这行代码的同学，他的答复是习惯。
但后面我自己也找到了自认为的答案：1=1，看起来代码变得不简洁了但它会为了避免引起下一行注释的时候引发代码错误，为了避免where 关键字后面的第一个词直接就是 “and”而导致语法错误。
类似的代码习惯内容，还有
“with t1 as select …“起了一个别名，方便后面的操作，当时有某位同学特别喜欢用这个代码格式。
以上的内容如果称为个人代码书写习惯，而随着学习的深入越来越知道这些后面都可以为归为代码规范。
说到代码的书写规范，保持代码整洁一致，逻辑清晰是一位代码人的功力体现。阅读代码为我们开启理解前人的思维的路径。一段优秀规范的代码，会让人非常舒服；一份糟糕的代码，经常有读不下去的感觉，每每看之都想胖揍代码书写者。
好的代码除了格式整洁，没有多余语句外，引入一些看似有似无的内容，并且分门别类进行代码管理也非常重要。而这一部分在后来我参与开发一份评分卡的开发内容后更深入体会。
对代码分门别类管理，不是一张大表里敲写全部的语句，但很多刚从事代码工作的同学肯定也是这样做的。不管三七二十一，一张表里写满了all内容，还没有清晰的注释，等待自己修改的时候，只能望码兴叹。
分门别类，每个模块只实现某部分功能。这些借鉴了开发的同学成熟的代码管理方法得来的经验，这个内容也应该是刚做数据分析与模型开放岗位的同学应该积累的代码思维。
以某实操类型的评分卡的代码的内容中，具体的代码分类内容如下：
在整个评分卡的开发文档中，我们引入py文件来启动整个评分卡模型，评分卡的整体逻辑是用sas书写。
auto.py文件是最开始引导文件，它最重要的作用是引出00going的SAS文件，这个00going的SAS文件是整个评分模型的引导文件。
整体的逻辑可以是这样理解：py文件是对接外部引导文件，sas文件是内部引导文件。为什么这样设计？因为对外衔接上py文件比较友好，当然这个是建立在你的评分卡整套逻辑是用sas书写的，如果是全用py问题忽略。
打开内部的00going的sas文件是这个内容：
在这里我们引入了sas中的关键字%inc，其中的%INC调用了关键路径中的命令文件。这里我们就越来越能看到评分模型的核心部件是各司其职的，比如其中的demography是用来统计人口信息的，creditecad是用来统计负责中的卡信息数据的，其他的类似…用具体的语句来实现某个功能。
一份好的代码，应该是逻辑分明，层次清晰，读之让人清爽，掩卷让人回味三日有余。
关于代码的管理与分类规范，参考别人的代码，学习代码精华更是提升代码能力的重要路径。
希望本篇内容对您有所启发。
~原创文章
…
end