汽车突然刹停，“嘭”，一个响亮的声音传入车厢里的几人耳中。
“哇！”接着传来小孩的哭声。“遭了，这下遭了！”后排的人嘴里说着话，赶紧抱起摔倒的小孩。
大家开始检查小孩的伤势，鼻子旁边有擦伤，在流血，另一只鼻子也隐隐流出血来。
事发之前，小孩站在后排中间座椅上，刹车时，被惯性带着往前倾倒。由于正对着空调出风口，直直的撞了上去。
这是多幸运？只是一点擦伤！如果没有这么幸运，那可能就是生命不能承受之重！
最近进行的是一个数据开发重构项目，最重要任务之一是改善先前代码的质量。
经过几周时间的分析和实践，我们发现核心问题是代码重复。
团队随处能看到一大段一大段的重复代码，一个800行的sql代码消除重复之后可能只有不到200行。
消除重复带来的益处非常明显：
原来的数据计算逻辑清晰地呈现了出来，代码更容易理解，调查问题更快了
不少隐藏的bug被发现并修复
取数逻辑的一致性得到更好的保证
代码行数一直是程序员工作量的一个参考指标，不少企业甚至为每个员工设定一个代码行数的目标。因此，很多开发人员为了达成这个所谓的目标胡乱复制粘贴代码，最终导致了低下的项目质量。
这其实是关于代码行数的错觉。
事实上，在代码量指标上，不仅不应该求多，反而应该求少。能完成同样功能的代码，当然是越少越容易维护。
在很多数据项目中，数据流水线的配置都是靠团队手工完成。这带来了很大的工作量（特别是在开发阶段），而且容易出错。
事实上，数据流水线完全可根据etl血缘关系自动生成出来。
我们在团队中这样做：
采用airflow这样的可通过代码定义流水线的调度工具
自动解析etl文件中的依赖表，并找到对应的etl文件
根据以上依赖关系自动生成etl依赖图
将此依赖图转化为流水线代码
自动化数据流水线的生成和管理给我们带来了极大的便利，节省了团队大量的时间。团队变得更高效和敏捷了。
日本核污染水排海事件正在成为国际关注的焦点。关于这件事有很多说法，比如日本自私论，美国阴谋论，中国过分反应论等等。
日本举出了很多数据说明核污染水无害。然而中国的逻辑很简单，如果无害就没必要排海，如果有害就更不应该排海。
在这件事上，我们的态度应该是保守的，因为它关乎全人类的健康。同时，在这件事上，过分相信数据那是极危险的，因为数据极容易作假，特别是这样复杂的专业领域，漏报一项数据就可能让性质完全不一样。
这件事上更应该相信的是简单的逻辑，中国的逻辑就是简单而显然的。
在关乎健康的重大问题上，中国是偏保守的，这让我们很放心，感觉更安全。为什么要拿安全去冒险？钱是可以赚的，安全问题发生了，就无法回头了。
业务应用开发中大家常常遇到bug，有些bug隐藏很深，甚至连专业的qa都没法发现。比如某些并发场景下出现的bug，某些极少出现的边界场景、需求未定义的场景下的bug等等。
但是在数据开发中，这些bug往往无处遁形。究其原因，有：
数据开发通常要并行处理大量数据，并发问题极易在开发阶段就暴露出来
数据开发通常要处理生产系统积累的全部数据，其背后覆盖了几乎所有业务场景
数据开发以专用的sql语言为主要开发语言，如果代码本身有问题，从结果上很容易发现（比如结果集数据量不对，统计上不符合业务直觉等等）
因此，数据开发人员在编写代码时应当极为谨慎，因为bug很容易暴露出来，而出现bug后也得由自己处理，总也跑不掉。
如何让团队变得更敏捷，也许应该从自动化一切开始。
自动化大部分工作之后，团队的各类开发规范就不至于只停留在纸面上，而是通过工具自动化得到保证。团队也不会因为一些低级错误而耗费大量的时间。有了自动化加持，团队可以集中精力解决重要问题，从而实现效率更高、质量更好。
就像先进机器是工业化时代的生产力一样，自动化工具就是敏捷团队的生产力。
如何推进团队工作自动化？要点在于在团队内部建立这样的意识，当每个团队成员在完成开发任务的时候都想着是不是可以把一些工作自动化的时候，团队的自动化水平就会越来越高。
自动化一切要求团队成员具备很强的技术基础，不过，这正好是技术人员努力前进的方向。
小孩到了一岁半的年纪，吃饭慢慢变成一件令人头疼的事情。
勺子自己拿不太稳，同时专注力也不够，吃两口之后就动来动去，上蹿下跳。
家里人没办法只能喂饭，喂一口，又跑了，得跟着追。有时候喂快了没吃完，或者他只是单纯抗拒食物，到嘴里面了，也直接吐出来，吐一地。
最近发现一个特别有效 …
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。