Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

从工具使用的痛苦说开去

Posted on 10/25/201606/23/2019 by 四火

painful

是因为最近团队里的数据分析师(data analyst)向我抱怨,为了分析数据,要跑 job,要执行 pipeline,要用 Spark 来算结果,但是期间遇到各种问题,虽然我们一起研究问题的解决方法,但是依然非常耗时而且令人沮丧。这些问题大多并非数据本身的问题,而是工程问题。换言之,我认为数据分析师的价值在于数据思维,他们有我们软件工程师不具备的数据敏感性,他们能从海量的数据中获得有价值的信息——但是如今他们却陷入了因为工具问题而导致才华无法施展的境地,确实令人叹息。而工具的问题,正是应该由软件工程师来解决的。

上班同车的同事 Kai 和我说,现在和几年前不同的是,“全民 dev 化” 了。除了上面说的数据分析师要解决工具的工程问题以外,还有 data scientist,business intelligence engineer,甚至 program manager,以及 TPM,都在不得已地处理并努力解决各种各样原本应该由 SDE(软件开发工程师)去思考和处理的问题。个中原因很简单,技术发展太快,快到维护的工作已经跟不上了。虽然有各种各样的工具,拥有巨大的能量,解决以往根本不敢想象的数据规模下的问题,可以不可思议地提高效率,创建纷繁多样的数据分析结果,但是似乎很多人都忽略了一件事。没有问题的时候,如同平静的湖面波光粼粼,光彩动人。但是一旦出现了许多问题,湖水马上翻脸,波涛汹涌,这些新技术和新工具往往带来了巨大的维护成本。

在许多团队以大数据为荣的时候,用大数据招人的时候,很少有团队去思考这样一个事情:真的需要那么大的数据规模吗?

我看到有很多问题的论证和尝试,是并不需要用海量的数据和巨大的计算资源的。但是似乎我们的思考已经带着迂腐而沉重的惯性,迈开了步子,跑起来,就再也停不下来了。举个例子,用 sample data 来验证数据的正确性。既然是 sample data,完全可以用合适的 ETL 去攫取少量但是符合要求的数据,然后来完成验证。有时候为了控制 sample 的数据规模,这个 ETL 需要更多的思考和斟酌才能完成。但是人是有惰性的,有时候拿到一个数据集合,不做 filtering,不管三七二十一一股脑儿扔进去,拿巨量的 EMR 计算资源去算结果,也能得到结果。但是这就是强大的工具带来的人在思维上的懒惰。我们看到计算和存储成本不断上涨,却很少有人从这个角度思考问题。

只有等这个问题问完了之后,我们才值得继续去问下一个问题:到底谁来为这样的工具问题买单?

我的观点是,虽然现在有那么多人都在承受它带来的后果,但是只有软件工程师才应该以之为耻。你们引入了这个工具,你们就应该把它负责到底。我们不要看到 data analyst 的才华消耗在无比沮丧的异常堆栈上面,data scientist 因为各种运行时故障跑一个简单 data report 生成折腾了一个星期。他们的才华不应该被浪费在这上面。无论是公司层面还是团队层面,SDE 应该站出来解决这些问题,提供一些足够好用的工具。如果没有资源和统筹来做这件事情,大家都只能痛苦,跟着效率低下。

于是说到痛苦,于我以及我们团队来说,最大的痛苦在于不得不去打交道的 Oracle。Data warehouse,既是系统的上游数据来源,也是中间数据存放的其中一个媒介,还是下有数据的出口,因此耦合紧密。而其中的数据库 Oracle 又频出问题。整个公司都在努力去 Oracle,但是这却并不是那么容易做到的。

以上只是一些冷静下来的思考而已。

更多的,留在记忆中的,是那些思考之前的痛苦的回忆。

但是这些年的工作,已经让我渐渐麻木或者说不会再少见多怪情绪激动了。

我记得刚工作的时候,发现一大痛苦在于要读懂项目里的六十万行代码。那个时候对于设计、骨架、模式等等缺乏认知,这六十万行代码映射到眼睛里面并没有明显的主次轻重之分,于是读代码变得痛不欲生。

接着则是出差,开局,要熬夜,要解决各种各样的线上问题、网络问题、部署问题。这不光是心理上的,还有身体上的疲惫。我记得在当时联通 “沃” 项目联调运营,对外展示前,突然网络出现重大问题,当时目睹某现场总工程师急的眼泪都要下来了,最后说出一句心凉的 “我们只能烧高香了”。

做过一个前端播放器的整合,一大堆兼容性问题,好多个日夜的折腾。好好坏坏,也缺少专家指导,很多问题都是靠枯燥而无奈的 “试错” 来 “解决” 的。于是问题规避开了,但是原因却不很清楚。

第一次性能优化期间,则是为了达到要求的指标。如果是一个新项目,有好多种性能要求下的设计方法。但是困难的地方在于,当我们开始着手并深入性能问题的时候,系统已经基本完成了,架构上的大动作基本不可能实施。

后来进入外企,开始面对如山的英文文档,难受得胃疼。

开会面对一帮印度人,口音听起来仿佛和外星人交流,只觉得云里雾里,不知所云。当时我肯定没有想到,如今几乎天天跟各种乱七八糟口音的人打交道。

后来则是一些恼火的线上问题,甚至一些严重的问题,棘手且出现在半夜,往往背上一凉,睡意全无。

……

现在已经淡定许多了。

我曾经和同事开玩笑,软件工程师成长的过程,就是一个被各种问题痛苦折磨并且自我解脱升华的过程。技术上的解脱是次要的,心理上的升华才是收获。在觉得山重水复疑无路的时候,往往悲观消极,自我怀疑。在解决问题的时候,又有一种巨大的解脱感而畅快无比。

有人说程序员是一个最波澜不惊的职业。对着电脑工作,然后拿钱回家。那么那个人一定不懂这个职业。

热爱,才有激烈的喜怒哀乐。

其实有时候也想心如止水,但是人的个性本就如此,不易改变。

于是在各种各样问题不断的折磨中蜕变,也不断成长。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 再谈谈工程师
  2. Notes: Spark metrics
  3. 研发团队的角色和构成
  4. JVM 问题定位工具
  5. 常用的 JDK 自带命令行工具

3 thoughts on “从工具使用的痛苦说开去”

  1. jkryan says:
    11/12/2016 at 12:14 AM

    写的很赞~

    Reply
  2. joey says:
    11/01/2016 at 5:21 PM

    哈哈~ 印度人的英语!

    Reply
  3. exc says:
    10/27/2016 at 6:01 PM

    赞
    面对这些问题(工具的快速迭代导致的问题)身为开发人员 应该以什么态度去面对呢 行业中有什么比较好的解决方案吗

    Reply

Leave a Reply to jkryan Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 聊一聊分布式系统中的时间
  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • Ticket: TRANSACTION 1.922915 BTC. Go to withdrawal >> https://yandex.com/poll/enter/BXidu5Ewa8hnAFoFznqSi9?hs=20bd550f65c6e03103876b28cabc4da6& on 倔强的程序员
  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme