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

文章配图，仅供参考

　　第一个陷阱是“隐式类型转换”。那架构师写ETL脚本的时候，为了图省事儿，在SQL里混用了字符串和数字类型。比如有个字段本来是VARCHAR，结果他直接拿它跟INT做比较，数据库为了不报错，就偷偷做了隐式转换。我原以为这种问题在编译阶段就能暴露，结果他们用的是动态类型语言，运行时才炸。最要命的是，这种转换在数据量小的时候根本看不出来，一旦数据量上百万，CPU直接飙到100%，监控大屏上的告警短信响得跟放鞭炮似的。后来我们查代码，发现这种隐式转换藏了二十多处，光改这些就花了三天——那架构师离职前居然还把注释全删了，说是“保持代码简洁”，我呸！

　　第二个陷阱更绝——“空指针防御性编程”。那架构师可能被空指针异常吓怕了，写代码的时候疯狂加null检查。按说这也不算错，但他把检查写在了最不该写的地方。比如有个方法，参数明明已经做了非空校验，他还在方法内部又加了一层，结果导致每次调用都要多走一遍判断逻辑。更离谱的是，他为了“防御”，还在判断里嵌套了三层try-catch，有个catch块里居然只写了“log.error(‘null pointer’)”，连异常都不抛。我原以为这种代码在测试阶段就能被发现，结果他们测试用例写得稀烂，根本没覆盖到这些分支。后来我们压测的时候，发现系统90%的时间都耗在这些无用的判断上，响应时间直接从两百毫秒飙到两秒——桌上的外卖都凉了，测试报告还没跑完。

　　第三个陷阱是我最不能忍的——“过度同步”。那架构师可能对并发有误解，写代码的时候见不得任何共享变量，只要是个可能被多线程访问的字段，他都要加synchronized。有个计数器，本来用AtomicInteger就能解决，他非要套个同步块，结果导致所有线程都要排队等锁。我查日志的时候发现，系统在高并发时，线程阻塞率高达70%，而真正在干活的线程不到30%。更搞笑的是，他还在同步块里调了IO操作——比如写日志、查数据库，这下好了，锁直接从毫秒级变成秒级，整个系统卡得跟蜗牛似的。我后来跟他们运维聊，他说有次系统崩溃，查了半天发现是某个同步块里的日志写入把磁盘IO打满了，而那个日志级别本来是DEBUG，根本不该在生产环境输出——那架构师离职前居然还把日志级别调成了INFO，说是“方便排查问题”，我直接气笑了。

　　这些陷阱之所以能藏这么久，说白了就是“优胜劣汰”在起作用——那架构师可能靠这套代码混过了几家小公司，毕竟小公司数据量小、并发低，这些隐藏问题根本暴露不出来。但一到大公司，数据量一上来，问题就跟雪崩似的全冒出来了。我后来跟几个同行聊，发现大家都遇到过类似的情况：有些架构师为了赶进度，或者为了显示自己“技术高深”，专门写这种“看似聪明实则坑人”的代码，反正出了问题他们早就离职了，锅都是接手的人背。所以我现在看代码，第一件事就是查有没有这种“过度防御”“过度同步”“隐式转换”的痕迹——但凡发现一处，直接让架构师重写，绝不妥协。

　　对了，那天我们改代码的时候，窗外天都黑了，运维小哥的告警短信还在响个不停。我抬头看了眼监控大屏，发现CPU使用率终于降到了20%，这才松了口气。后来朋友公司为了感谢我，送了我一个域名——说是他们之前注册的，一直没用，我觉得挺有意思，就收下了。现在想想，那架构师要是知道他写的代码能让我白捡个域名，估计得气得从坟里爬出来吧？

　　不过话说回来，这些陷阱虽然坑人，但也不是完全无解——关键是要敢较真，敢让架构师把代码细节讲清楚。别听他们吹“我这套架构能扛多少并发”，直接让他们把代码打开，看看有没有隐式转换、有没有过度同步、有没有无用的防御性编程。要是他们支支吾吾不肯展示，或者找借口说“这是商业机密”，那基本可以断定：这代码有问题，赶紧跑！

（编辑：PHP编程网 - 金华站长网）

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