大数据架构师避而不写的3个代码陷阱

　　去年9月份，我接手个新项目，对方架构师甩过来的代码文档里，连个异常处理的影子都没见着。我原以为是他漏写了，结果翻遍仓库，好家伙，所有模块的异常处理全靠「try-catch」硬扛，连日志都不打。后来跟他们团队的人闲聊，才知道这老哥觉得「写异常处理太麻烦，反正系统会重启」——我当场就懵了，这思路，怕不是从二十年前的单机程序里继承来的？

　　第一个坑，就是「异常处理等于没处理」。我见过最离谱的，是某个数据清洗模块，直接把所有异常都吞了，连个「System.out.println」都没留。结果上线第三天，数据源格式变了，模块一声不吭地继续跑，直到下游系统报错，才发现数据早烂了。更绝的是，这老哥在文档里写：「本模块具备自愈能力」——自愈个鬼啊，连问题都发现不了，还自愈？我后来偷偷改了代码，加了详细的日志和告警，结果被这老哥骂「过度设计」，说「简单问题复杂化」。我直接怼回去：「你所谓的简单，是拿整个系统的稳定性当赌注。」

　　凌晨三点刷后台，看着曲线突然掉到零，心跳都停了。查了半天，发现是某个ETL任务卡死了，日志里只有一句「NullPointerException」，连堆栈都没打。我原以为只是个别情况，结果翻历史记录，这任务每周都要卡两三次，每次都是手动重启。更搞笑的是，这老哥在文档里写：「本任务设计为7x24小时运行，无需人工干预」——我信你个鬼，你这分明是「7x24小时需要人工擦屁股」！

　　第二个坑，是「资源管理靠天收」。我见过最神的，是某个Spark任务，连「spark.executor.memory」都没配，直接用默认值。结果任务跑着跑着，OOM了，整个集群都卡死。我查代码，发现这老哥连「try-with-resources」都没用，文件流、数据库连接全靠手动关闭。我问他：「你不怕资源泄漏？」他一脸无所谓：「跑完任务，JVM自己会回收的。」我差点没喷出来——JVM回收是能回收，但在这之前，你的任务早被OOM杀掉了！后来我偷偷改了配置，加了资源监控，结果这老哥又骂：「你加这些监控干什么？影响性能！」我直接回：「不加监控，你怎么知道任务什么时候会炸？」

　　站长平台里存了半年的截图，全是各种任务的失败记录。我翻着翻着，突然发现个规律：凡是这老哥写的模块，失败率都比别人高至少30%。更绝的是，他写的代码里，连最基本的单元测试都没有。我问他：「你不写测试？」他一脸惊讶：「测试？那不是测试团队的事吗？」我差点没晕过去——测试团队能测出你的逻辑错误？能测出你的资源泄漏？能测出你的异常处理？后来我强行要求所有模块必须写单元测试，结果这老哥又闹：「写测试太浪费时间了，我有经验，不会出问题的。」我直接怼：「你的经验，就是让系统每周炸三次？」

文章配图，仅供参考

　　同事打来电话，说某个任务又卡死了。我查了半天，发现是这老哥写的代码里，有个死循环。我问他：「你没发现这代码会无限循环？」他一脸无辜：「我以为条件会变的。」我差点没气笑——条件变不变，是你「以为」就能决定的？后来我偷偷加了循环次数限制，结果这老哥又骂：「你加这个限制干什么？影响功能！」我直接回：「不加限制，你的任务能跑一年！」

　　我原以为，这些坑只是个别现象，结果跟几个同行聊天，发现大家或多或少都遇到过。有的架构师觉得「异常处理太麻烦」，有的觉得「资源管理不重要」，有的觉得「配置管理无所谓」——可这些「觉得」，最后全变成了系统的定时炸弹。优胜劣汰，市场会教他们做人，但在这之前，遭殃的，是我们这些接盘侠。

　　凉掉的茶，喝着有点苦。我翻着代码，突然想起个问题：这些架构师，是真的不懂，还是装不懂？如果是前者，那还能救；如果是后者……我叹了口气，把代码合上——算了，还是先把自己手头的活干好吧。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!