2019年（58）
分类： IT业界
2019-04-15 20:39:15
阅读本文大概需要 4 分钟。
悟空之友的故事
今年年初，到一家互联网公司实习，该公司是国内行业龙头。
不过技术和管理方面，却弱爆了。
那里的程序员，每天都在看邮件，查问题工单。
这些问题，多半是他们设计不当，造成的。
代码写的一团糟，全是复制粘贴，连作者都没改，大家普遍不写注释，也不格式化，代码歪歪扭扭。
一个项目里，httpclient竟然出现了四种。
一种是该公司研发部写的，
一种是老版本的开源项目，
一种是新版本的开源项目，
还有一种是开发人员造的轮子。
打接口请求响应日志，竟然不知道用拦截器。打错误日志竟然不打上下文信息，每个人一种日志风格，千奇百怪。许多重要的中间流程，居然不打日志。
idea、eclipse、myeclipse的配置文件竟然全部传到项目里去了。
该公司混了两年的程序员，跟快递公司做查询接口，竟然不知道加密运单号。
所有服务间通讯，都没有设requestId，导致跟踪会话很困难。
一个没什么qps的边缘接口，居然做消费者生产者+阻塞队列的异步模式。显得你技术少是不是。不知道异步会增加维护成本，提高测试难度吗？而且，任务队里没有考虑持久化，赶上发布，丢了好多任务。
读取一个小小的xml和exc配置文件，居然用流式解析，没见过这么二逼的，真是醉了。
做优化全靠拍脑门拍大腿，难道不会用excel分析日志，用jprofile扫项目？
一个100以内的常数集合遍历，他也要写个优化算法进去，算法跟业务还搅在一起，一团乱麻。
每个人都在嚷嚷性能、算法、分布式计算……
几乎没有文档，全靠从代码反推逻辑。
有枚举他不用，非要在每个页面上，把枚举值挨个儿写死，知道后面改代码多么费劲吗？
欺骗性的变量名，里面存储的是AES加密的，变量名后缀却写成了DES；里面存的是小写字母，却写成upperStr。
一个方法十几个参数，有三分之一是极其简略的缩写，注释肯定也没有的。
一个类写到三四千行是常事。
开发自测，居然要把代码全丢到公共机器上，而且都是走svn，他们把svn当ftp用。
svn里面大量的无意义提交，一多半的提交连都编译不过去。
我看到有个应届生，改了两句话，马上提交，说是怕代码丢失。
一个运行了两年的项目，spring的包扫描明显配错了，有些bean根本扫不进来，居然没有人发现。
一半的bean在spring管理下，另一半的bean他们自己写单例模式来实例化。
他们用mysql来做审计系统，出报表，有个报表要跑8分钟。
原来是有人用字符串来存多值（逗号分隔），sql里写了like，导致没有利用到索引。
为什么不用pg，pg在sql编程方面，功能更丰富，更适合做统计，它本身就支持数组。
程序员们都是得过且过的态度，怎么把代码灌进去，跑的通测试，就算交差了。
为什么大型互联网公司，技术和管理这么差劲，是怎么形成的？（这家公司是卖机票的，没有明确说出公司名字，是怕给自己惹麻烦）
甲：这个A开源库旧版本有崩溃问题啊。
乙：换新版本的A。
甲：换了新版本A，用旧的 GCC 编译不过啊。
乙：换新版本GCC。
甲：换了新版本GCC，B开源库不兼容啊。
乙：换新版本的B。
甲：换了新版本的B，导致性能下降啊。
乙：开多线程。
甲：开了多线程导致延迟抖动不同步了。
乙：换新的延迟修正算法。
甲：换了新延迟修正算法偶尔会崩溃啊。
乙：要不。。。我们还是去看看那个A开源库的旧版本崩溃能不能修好吧。
如今上点规模的IT公司，其软件项目的规模和复杂度都远远超过工程师的能力上限了，都只能小心翼翼地修补。
有时局部的大改动会引发连锁反应，大改动的风险和成本很难控制，没有巨大的收益谁也不敢随便改，你能看到的问题老员工看得更清楚，甚至也清楚怎么解决，但是不动手的原因就是不知道出了事谁来背黑锅，技术上的事情谁敢说100%不出事的。
那是不是大公司的技术项目就没救了呢？
也不一定，有些事要等个机会的，常见的机会：
1. 技术基础平台大革命，比如移动互联网的兴起，从PC迁移到了手机端，很多旧的技术代码就可以抛弃了，手机上从零开始。
2. 竞争对手小宇宙爆发，对手搞出一项技术取得了竞争优势，被迫追赶，这时候死马当活马治，改出任何问题也都能忍了。
3. 人事大动荡，管理层和基层都大换血，旧代码已经没人有能力维护下去了，不得不重来。
码农西游特别申明：本文文字内容转自 ，图文效果为原创，如有侵权，请联系删除。
·END·
程序员的成长之路
路虽远，行则必至
本文原发于 同名微信公众号「程序员的成长之路」，回复「1024」你懂得，给个赞呗。
往期精彩回顾
