⼀篇精彩的洗地⽂
写在前⾯
前段时间读了⼀篇知乎帖⼦，相当精彩。后来研究了帖⼦的始末，发现更加精彩。在这⾥分享给⼤家。
长⽂预警！这篇⽂章相当长。但是也相当精彩。剧情反转超乎想象。有兴趣的请耐⼼观看。
知乎提问
先说问题的来源。问题的来源是⼀条知乎的提问，。为了⽅便⼤家阅读，我转载到这⾥。
提问原⽂
今年年初，到⼀家互联⽹公司实习，该公司是国内⾏业龙头。
不过技术和管理⽅⾯，却弱爆了。
那⾥的程序员，每天都在看邮件，查问题⼯单。
这些问题，多半是他们设计不当，造成的。
代码写的⼀团糟，全是复制粘贴，连作者都没改，⼤家普遍不写注释，也不格式化，代码歪歪扭扭。
⼀个项⽬⾥，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编程⽅⾯，功能更丰富，更适合做统计，它本⾝就⽀持数组。
程序员们都是得过且过的态度，怎么把代码灌进去，跑的通测试，就算交差了。
为什么⼤型互联⽹公司，技术和管理这么差劲，是怎么形成的？
（这家公司是卖机票的，没有明确说出公司名字，是怕给⾃⼰惹⿇烦）
萧井陌的回答
对这个问题，最精彩的是萧井陌的回答。⽬前已经有5000+的赞。这也是本⽂推荐的主要内容。
这个回答很长。⼀定要耐⼼读。⼀定会受益匪浅。
回答原⽂
作者：萧井陌
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，⾮商业转载请注明出处。
楼主你好，我试着给你解释⼀下，希望你能满意。
新⼿经常会有这样的想法——「这代码怎么这么烂？写的⼈⼲什么吃的？怎么能这样？为什么不按照书
上说的做？」，这很正常，⼤家都年轻过，经历过这种阶段，我懂你⼼⾥的想法，所以也愿意详细地向你解释，这⼀切发⽣的原因是什么。
你说「
不过技术和管理⽅⾯，却弱爆了。
那⾥的程序员，每天都在看邮件，查问题⼯单。
这些问题，多半是他们设计不当，造成的。
」
你真的觉得『国内⾏业⽼⼤的互联⽹公司』会是技术和管理弱爆了的样⼦吗？
你以为团队应该像永动机，但现实永远有各种摩擦、辐射、损耗。
内燃机的能量转化率，通常只有 30% - 50%，但是它却是驱动全世界运转的核⼼引擎，顺丰京东的快递⼩车、联通全国的⾼铁动车绿⽪、瞬时直达的飞机……
机器尚不能 100% 效率运转，何况是⼈呢？
你说我们的程序员每天都在查看邮件、问题⼯单，你说这些问题多半是我们设计不当造成的，请问你有试过统计数据吗？你⼤概只是『感觉』如此吧？
事实上，经过⼗⼏年的发展，我们内部的『效率改进团队』已经⾮常⾼效成熟，每⽉、每周、甚⾄每天都会有新的改进，现在的业务处理⽅式，不说全世界，我可以⾃豪地说在全国我们是领先的，甚⾄是遥遥领先，不然凭啥坐到了全国龙头⽼⼤的位置呢？
所以啊，你只看到了程序员花在业务上的时间，没看到我们内部的『效率改进团队』为程序员们省掉的时间，我觉得我有必要站出来为默默付出的『效率改进团队』说⼏句。
当然，楼主作为实习⽣，不知道这些事情进⽽产⽣了这些疑问，也暴露了我们的不⾜。我已经在『团队建设委员会』⾥提出了这个问题，⼤家⼀致通过了决议，以后我们会对新员⼯——包括实习⽣加强企业⽂化、历史培训，确保我们的新伙伴们不仅知道要去哪⼉，也要清楚我们从哪⾥来，长路漫漫，我们⼀同前⾏。
你觉得「
代码写的⼀团糟，全是复制粘贴，连作者都没改，⼤家普遍不写注释，也不格式化，代码歪歪扭扭。
」
当初公司起步的时候，整个项⽬都是⼏个初创程序员加班加点熬出来的，我知道你看过《代码⼤全》、《程序员修炼之道》、《Unix 编程艺术》，你对上⾯的准则信⼿拈来，你可否翻开床头柜上的这⼏本书，看看它们的出版时间呢？
是的，公司起步的时候，这⼏本书根本还没有出版，彼时中国互联⽹⽅兴未艾，⼤家都是摸着⽯头过河。现在你遇到问题，你可以问朋友、问导师、⽤⾕歌、⽤栈溢出、⽤知乎，我们写程序那个年代，看的是谭浩强、严蔚敏，⽤的是 52k 拨号上⽹，语⾔只有 C，编辑器是没有语法⾼亮和实时编译的，编译器是没有智能准确的报错的，没有现在这么多知识、也没有这么多规范和好资源、好⼯具。不过我们还是把项⽬做出来了，把公司⼀步步推到了现在的位置。
不过这个问题是客观存在的问题，谁也不否认，但是你知道为什么你被分配到了⼀个『代码看上去⼀团糟也不够规范』的项⽬吗？我们需要新鲜⾎液来重构⼀些⽼代码，所以你会被分配到艰苦的岗位上。我们希望你是勇于战⽃的战⼠，我们更希望你能成长为经验丰富的⽼兵，⽽
把你放到这种岗位，是对你来说成长最快的⽅式。
你认为「
⼀个项⽬⾥，httpclient竟然出现了四种。
⼀种是该公司研发部写的，
⼀种是⽼版本的开源项⽬，
⼀种是新版本的开源项⽬，
还有⼀种是开发⼈员造的轮⼦。
」
你不知道的是，我们最初⽤了开源软件（也就是你所说的『⽼版本』），它构成了我们早期项⽬的基⽯，随着业务复杂性增加，我们改进并最终切换到新版本。
这个软件跑⽼业务⾮常成熟，但是在⼀些新业务上有不可调和的⽭盾，所以在痛苦的适配后，研发部的同事们⾃告奋勇⽤ 20% 的时间写了新业务的组件——是的你没看错我们也有 20% 时间，我们⿎励⼯程师的创新。
⾄于你说的开发⼈员造的轮⼦——这说起来可真有趣，它其实是前年来的⼀个清华⼤学实习⽣写的。
当时他来了之后，针对他接⼿业务的需求，向我抱怨说现有的 3 种都不好，要写⼀个新的来『统⼀天下
』，这话是他的原话，我记得⾮常清楚，因为以我多年经验来看这样的做法是不可取的，但是本着锻炼年轻⼈的⼼态（加上他的确是不可多得的天才），我同意了他的请求，于是我⽤⾃⼰的业余时间接管了他的⼤部分⼯作，全⼒⽀持他写⼀个新的组件，帮他挡住了所有上⾯的压⼒，后来的故事就是你看到的这样。
是的，他后来越深⼊、就越来越感到业务的复杂，不断推翻重构、拆东墙补西墙，但始终发现和⾃⼰想的根本完全不⼀样，受不了了就⾛了，留下来这个。
我们明年的规划中，就包括剔除这个组件的 codebase，因为它实在是太糟糕了。
你⼜说「
打接⼝请求响应⽇志，竟然不知道⽤。
打错误⽇志竟然不打上下⽂信息，每个⼈⼀种⽇志风格，千奇百怪。
许多重要的中间流程，居然不打⽇志。
idea、eclipse、myeclipse的配置⽂件竟然全部传到项⽬⾥去了。
该公司混了两年的程序员，跟快递公司做查询接⼝，竟然不知道加密运单号。
所有服务间通讯，都没有设requestId，导致跟踪会话很困难。
」
并不如你所想的那班美好，也许你在⾃⼰的电脑上写过⼀些玩具代码，觉得这样很⽅便、酷炫，但是真正到了战场，你会发现没什么才是必须的、好的，只有适合的才是对的。
⾄于配置⽂件，这么说吧，IDE 的配置⽂件传到代码仓库是我定下的规矩，『怎么会有⼈定这样的规矩？』，是的你可能从软件⼯程的教科书上或者某些『知名博客』上读到了不能这样做，但实际上这样做在很多情况下是必须的。
原因何在？
这样可以确保代码克隆即可⽤，⽽不是让每个⼈都去设置⼀⼤堆⽆聊的东西，这样不仅节省时间，也确保了每个⼈的环境⼀致性，你想想这⼏年⽕热的 docker，应该明⽩了这样做的正确性和必要性了吧？
你可能会说即便如此、插件也不⽤上传到服务器保存，我告诉你这样是不⾏的，你要考虑到我们这个项⽬前后⼗余年，你觉得⼏个插件能坚挺⼗余年？很可能我们早期⽤的软件，现在你已经完全不可能到了，所以保存⼀份备份是⾮常有必要的，决不能错误地认为是冗余。
教科书只会教你基本通⽤的原则，树⽴你基本正确的观念，但是如果只是死守教条，如何能拥抱⽇益复杂的变化呢？
你看的教科书，且不说时间上已经是⼆⼗多年前的了，在适⽤性上，也不说就是真理，IT ⾏业发展⽇新⽉异，⼏个⽉就是沧海桑⽥，为了适应这样的变化，认真地思考、总结、判断才是最重要的。
你觉得「
⼀个没什么qps的边缘接⼝，居然做消费者⽣产者+阻塞队列的异步模式。
显得你技术少是不是。
不知道异步会增加维护成本，提⾼测试难度吗？
⽽且，任务队⾥没有考虑持久化，赶上发布，丢了好多任务。
读取⼀个⼩⼩的xml和exc配置⽂件，居然⽤流式解析，没见过这么⼆逼的，真是醉了。
」
你⼤概不知道，当初跑在你⼝中的「⼀个没什么qps的边缘接⼝」上⾯的业务带来了公司曾经 90% 的收
⼊，所以我们⽤了复杂的设计以应对当时的需求，当然现在业务转变，⽼系统不再需要处理那么多业务了，但是更没有理由为⼀个『works perfectly well』并且不再重要的业务重构代码吧？
所以，不是我们秀技术，⽽是业务需求 + 业务变更使然，年轻⼈还需要多学习⼀个。
你抱怨「
做优化全靠拍脑门拍⼤腿，难道不会⽤excel分析⽇志，⽤jprofile扫项⽬？
⼀个100以内的常数集合遍历，他也要写个优化算法进去，算法跟业务还搅在⼀起，⼀团乱⿇。
每个⼈都在嚷嚷性能、算法、分布式计算……
⼏乎没有⽂档，全靠从代码反推逻辑。
有枚举他不⽤，⾮要在每个页⾯上，把枚举值挨个⼉写死，知道后⾯改代码多么费劲吗？
欺骗性的变量名，⾥⾯存储的是AES加密的，变量名后缀却写成了DES；⾥⾯存的是⼩写字母，却写成upperStr。
⼀个⽅法⼗⼏个参数，有三分之⼀是极其简略的缩写，注释肯定也没有的。
⼀个类写到三四千⾏是常事。
」
我再强调⼀次——我们是全中国同类公司中技术能⼒第⼀的，你所说的问题，当然是不存在的。
我们有专门的 Hadoop 集来分析⽇志，当然也就⽤不着 Excel 了。
对于我们这种体量的公司来说，不存在什么『常数集合』，代码必须⽤合适的数据结构——这是常识吧？
特殊的算法和业务掺杂以增加内聚性，这是我们多年的经验，的确，它和教科书上说的不⼀样，但是我前⾯说了，死守教条是不⾏的——想必你⼀定知道 OSI 7 层⽹络模型吧？
公司的技术氛围浓厚，是和公司的基因分不开的，我们公司最重要的原则就是——『拥抱变化』，从⼗⼏年前的机房托管单机到现在的庞⼤⾃建集，技术跃迁了何⽌千万⾥，所以每个⼈都在学习新知识、每个⼈都沉浸在新知识的喜悦中。
你的问题，⼤多都是因为没有考虑到公司的庞⼤体量和⼗⼏年的技术跃迁才有的疑问，这点不再赘述，⾃⾏体会吧。
你想的是
「
开发⾃测，居然要把代码全丢到公共机器上，⽽且都是⾛svn，他们把svn当ftp⽤。
svn⾥⾯⼤量的⽆意义提交，⼀多半的提交连都编译不过去。
我看到有个应届⽣，改了两句话，马上提交，说是怕代码丢失。
⼀个运⾏了两年的项⽬，spring的包扫描明显配错了，有些bean根本扫不进来，居然没有⼈发现。
⼀半的bean在spring管理下，另⼀半的bean他们⾃⼰写单例模式来实例化。
」
其实那不是 SVN，那是我们公司⾃主研发的适应我们内部需求的源代码管理系统和⽂件管理系统，你可以往⾥⾯放任何东西。
你所说的「⽆意义提交、⼀多半的提交连都编译不过去」其实只是表象，这套系统代号 TITAN，它⾃带 CIDD（持续继承、交付、部署），所以这些⽆法编译的提交都是不会有机会⾛到下⼀步流程的的。
如果你⼯作了⼀年，你就会发现这个需求是很重要的，改动、尤其是⼤型改动，中间会有很多⾮可⽤但有需要存档的步骤，现有的源代码管理系统都不能很好地⽀持这些需求，因此你也被教育了⼀套适应落后⼯具的思想。⼈啊，最重要的能⼒是改进⼯具，所以⽤ TITAN 的时候要拥抱全新思维，不要被落后思维捆绑。
如果你⼯作了⼏年，你可能还会问为什么我们没⽤ Jenkins、Travis 等⼯具，其实呀，就在 TITAN 之中呀，它凝结了公司最优秀的⼈才的⼗⼏年宝贵经验和⼼⾎。
By the way，我们最近正计划开源它，为中国开源社区做贡献，也希望提⾼业界的综合素质。欢迎你提交 PR 哦
你最后说「
他们⽤mysql来做审计系统，出报表，有个报表要跑8分钟。
原来是有⼈⽤字符串来存多值（逗号分隔），sql⾥写了like，导致没有利⽤到索引。
为什么不⽤pg，pg在sql编程⽅⾯，功能更丰富，更适合做统计，它本⾝就⽀持数组。
程序员们都是得过且过的态度，怎么把代码灌进去，跑的通测试，就算交差了。
为什么⼤型互联⽹公司，技术和管理这么差劲，是怎么形成的？
」
为什么不⽤ pg？如果你抱着这种想法，那⽤了 pg 也要被喷的，到时候就就会说 —— 「为什么不⽤ sqlite，轻量简单，搞这么复杂真的有必要吗？」，真的有必要。。。
这只是⼀个很简单的系统，做的事情也很简单，当初做这个系统的同事更熟悉 MySQL，当然 MySQL 是不⼆之选了，对于简单的东西，追求的是开发速度、使⽤便利性。
你觉得⼀个⽉跑⼀次的审计代码，8 分钟有什么问题吗？就算是⼀周跑⼀次，当然也是没问题的。
程序员的单位时间是如此宝贵，为了优化⼀段⼀个⽉跑⼀次的 8 分钟代码，值得花费数天的时间来做这件事吗？
重复⼀遍，你的问题，⼤多都是因为『没有考虑到公司的庞⼤体量和⼗⼏年的技术跃迁才有的疑问』，这点不再赘述，还请⾃⾏体会。
当然，年轻⼈乐于思考，这是好事，是希望，新鲜⾎液替换⽼旧部件系统才能健康发展成长，⼈如此、公司如此、国家也是如此。
希望你勤于思考，努⼒学习，有问题的话，我们公司是⿎励同事们向 CEO、CTO 写信的，不然也不会有 CEO、CTO 信箱了你说对吗？
当然，这样的技术性问题、你写给我就好，CEO 是船长，不需要关⼼底层锅炉房的细节。
另外我想补充⼀下我的想法，希望对你有所帮助。
你看你都没说加班问题，我们公司没加班啊，这多好，怎么做到激烈竞争下还能不加班的？都亏了公司⽼领导和元⽼们的⼀⼿决策
所以我想补充的不是技术问题，技术问题都不是问题，年轻⼈可以学习、交流，技术都会很快成长，毕竟年轻⼈的冲劲⼤、头脑灵活。
我想说的是整体观、⼤局观、⼤棋战略。
黄⾦的导电性最好，为什么电脑主板还要⽤铜？
清华⼤学最好，为什么有⼈要去普通学校？
飞机最快，为什么还有⼈坐⽕车？
因为资源都是有限的，我们在现实⽣活中——⽽不是教科书上——必须兼顾成本和产出的平衡。
你问我每⾏代码都多⼈多层⼈⼯ review 好不好？问我⽀不⽀持？我说好，review 我怎么能不⽀持呢？我今天在知乎这个公众平台我明确说了我⽀持。
但是你也应该多学习⼀个，这个现实毕竟是现实，我们要兼顾各种考量。
你今天在这⾥渲染「⼤公司技术和管理这么差劲」，是不对的、是失实的、是⽋妥的、是缺乏认真思考的、是未加深⼊考量的。
将来舆论出了偏差，你虽然不⽤负责任，但是你认识到⾃⼰的错误的时候，会后悔、会内疚、会难过的吧？
何处乌托邦？或许……等下⼀代？
总结就是，⽣产效率才是最重要的，世间万物最重要的是平衡。
怎样取舍、如何妥协，这不仅是⼤⾃然的规律，也是我们前进、发展的准绳和仰仗的原则。
————
满意吗
知乎评论
这篇⽂章真的是精彩。特别是⼀些句式，模仿长者的⼝⽓，简直惟妙惟肖。这样精彩⽽认真的⽂章，也就引来了相当多的共鸣。可以看到很多评论已经深深陷⼊了对回答的认同。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论