五月工作小结

前言

公司4月以来大量裁员，我所在的统计与编程部门优化了一半人。入行统计编程后，我一直以来的工作是对于个别因各种原因无人负责的项目进行部位支持、新工具开发和大数据项目数据治理的执行，实际上承担完整项目的主程序员或QC程序员的机会都比较少。这次优化后，我也终于被分配到了4、5个担任主程序员或QC程序员的临床研究项目，压力骤增的同时也对终于可以使用自己创造的工具，投入实际项目执行而欣喜和期待。

执行项目的感受

同时需要密集执行3、4个项目，对于统计分析项目经验尚不充足的我很有压力，同时我自己开发的工具也给我有顺利交付的底气。对于这个工具在这个时候支持实际项目，仍有很大的不确定性。因为其尚没有经过一个复杂项目所有数据集代码、TFL代码完成生成的过程。好在裁员前的1个月期间，领导安排了即将离职的小伙伴加入这个工具的测试，发现了一些bug和提出一些改进问题。

从5月初到5月结束，经过一个月的密集使用，可以说工具能够胜任目前所能遇到的全部Table和数据集的开发逻辑、方法。基本能够做到又快又好的完成一个又一个的表格，给了我很大的成就感，也很欣慰。期间还加入了又一个重要功能--亚组管理。这样可以更好管理亚组分析，并且因为批量编辑功能的加入大幅度提高亚组的生产效率。在一个项目中，我运用工具建立了8个亚组，并且在后续几个亚组中，运用了复制前置亚组和批量修改的方式，几乎只用了一瞬间就完成了亚组的全部编程。最后，加入所有SAS代码导出，并且在SAS项目文件夹里，研究了如何批量运行代码，并且生成QC对比结果的方式，整个来说，基本达到了目前我能做到的最大程度的自动化。

在这期间，我仍然坚持对数据问题采用RBM的方法，使用我用python开发的RBM报告框架，设定核查条目，批量且规范输出数据问题。这样数据问题得到更规范高效的发现和处理。

Spec_workbench工具5月高强度使用后的优点和不足

对比直接在SAS项目环境里写代码，使用我开发的Spec_workbench工具来编写SAS代码，目前我总结有以下优点。

• 效率更高。效率更高的原因有几个。1内置大量宏，并且可以可视化选择插入，并按照参数提示填入参数；2内置大量快捷方式，对于很多常用代码，直接通过简单配置产生相关代码。比如数据集之间的横向连接、导入系列原始数据；3快速生成表头和行标签，这是Table生产的一个重要加速方式；4快速产生QC相关的代码；5变量维度编辑的快捷方式，比如快速加入format，快速格式转化，快速形成按条件赋值代码。并且大量可选项选择操作，加快速度；6生产一个数据集或者表格，采用了模块化的划分，有助于模块化思考、配置，并且查找修改更快；7代码编辑和spec配置在一个工具中，在代码编写时如果要修改spec，可以很快完成
• 准确率更高。1对于数据集的产生，可以和本工具配置的spec信息关联，确保数据集代码没有遗漏变量；2对于一个数据集代码或者一个表格的代码，工具按照模块进行了划分，在编辑和查找问题的时候可以很好的按照一个子数据集、一个变量的维度进行工作；3对于快捷方式，宏的运用，工具展示了待填写的参数以及一些参数的选项，可以避免参数遗忘 项目管理。项目所有的spec信息和代码信息都在一个工具里管理，可以很方便的查看不同项目信息，以及来回在不同项目中切换工作。未来多人编辑同一个项目，应该会比较方便。

不足之处。

易用性。工具使用有一定上手门槛，要经历1到2个项目后应该可以熟练掌握。

专业性。工具完全是我一个经验不那么丰富的SAS统计程序员，以及开发软件经验也不太丰富程序员的胆大妄为之作。开发出来这个东西在专业人士眼中可能有很多不合理不规范不完善之处。另外软件也是在实践中边用边加功能和边改bug，应该还有许许多多没时间改或者懒得改的bug。

接受度。这个东西应该说初级程序员SAS水平和项目经验不丰富的人还比较愿意尝试。但是高级SAS程序员已经形成自己的习惯，可能视之为异端，并不愿意尝试。

多人使用的性能问题。本软件背后的数据库是本地的简单sqlite数据库，当多人同时使用时，对于数据库的存储可能是个问题，会产生存储冲突。

目前我每周都会加很多班，使用我的工具完成项目，积累项目经验也希望没有白开发出这样的工具，每天也基本乐在其中。我会继续努力，用实际完成的项目，来证明自己构思并开发实践的这款产品能产生较大的价值。