为什么有些大公司技术弱爆了？ 第1页

楼主你好，我试着给你解释一下，希望你能满意。

新手经常会有这样的想法——「这代码怎么这么烂？写的人干什么吃的？怎么能这样？为什么不按照书上说的做？」，这很正常，大家都年轻过，经历过这种阶段，我懂你心里的想法，所以也愿意详细地向你解释，这一切发生的原因是什么。

你说「

不过技术和管理方面，却弱爆了。

那里的程序员，每天都在看邮件，查问题工单。

这些问题，多半是他们设计不当，造成的。

」

你真的觉得『国内行业老大的互联网公司』会是技术和管理弱爆了的样子吗？

你以为团队应该像永动机，但现实永远有各种摩擦、辐射、损耗。

内燃机的能量转化率，通常只有 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 我怎么能不支持呢？我今天在知乎这个公众平台我明确说了我支持。

但是你也应该多学习一个，这个现实毕竟是现实，我们要兼顾各种考量。

你今天在这里渲染「大公司技术和管理这么差劲」，是不对的、是失实的、是欠妥的、是缺乏认真思考的、是未加深入考量的。

将来舆论出了偏差，你虽然不用负责任，但是你认识到自己的错误的时候，会后悔、会内疚、会难过的吧？

何处乌托邦？或许……等下一代？

总结就是，生产效率才是最重要的，世间万物最重要的是平衡。

怎样取舍、如何妥协，这不仅是大自然的规律，也是我们前进、发展的准绳和仰仗的原则。

————

@bhuztez 满意吗

题主有年轻气盛的一面，但是你说的问题确实是常常存在的。

大公司常常会遭遇两种病症，我管它叫“滑坡与蒸发”现象。

具体病症如下：

1.滑坡：招聘标准持续降低。人资的硬标准或许在提高，但是实际技术标准在降低。s 级的老一辈面试官，能容忍 a 级的应聘者，过了几年这个 a 级的应聘者自己成了面试官，能力却没提高到 s 级（提高不仅靠个人努力，也要看历史行程），于是他能容忍 b 级的应聘者……所以叫滑坡现象。

尤其是当这家公司历史上经历过极速壮大时期的话，滑坡现象就更加明显。你甚至会发现一线员工技术水平远低于早已脱离一线的经理层。

2.蒸发：如果团队建设跟不上业务发展，大部分人都会处在疲于奔命实现需求的状态，技术水平和交付质量长期得不到提高。个别人由于努力和运气，技术提升较快。如果他没有一个清晰的通道将能力体现出来，就会出现两种可能——要么他会拒绝继续提升，反正现在也够用了，同事还不如我呢，大公司一般又不裁人；要么他觉得同事不行，跑了，蒸发了。最终留下来的人反而是相对平庸的人，那些利用公司资源达到较高水平的人反而让其他公司得利。

最终当你来到这家公司的时候，你就会奇怪为什么他们的技术不如你想像的好。其实不是没有能人，只是要么在经理室里，要么已经蒸发了。

PS：我补充一点，已经有相关领导澄清了，题主的观察可能有偏颇。但是我假设题主的观察没有偏颇，那么是不是你理想中的项目状态就一定好于你看到的“乱糟糟”的状况？

答案是不一定。

不说大道理，我举个例子，题主在互联网圈子里，可能没见过一个版本控制工具，叫 ClearCase，IBM 开发的。特点是极其严谨，极其强大，极其复杂。如果你只看流程图的话，那绝对是严谨到完美的版本控制系统。但是实际用起来的体验如何呢？只能说，让人挠头啊……所以，你想象的那种“清晰而优美”的项目，维护起来，可能是极其难受的。

甲：这个A开源库旧版本有崩溃问题啊

乙：换新版本的A

甲：换了新版本A，用旧的 GCC 编译不过啊

乙：换新版本GCC

甲：换了新版本GCC，B开源库不兼容啊

乙：换新版本的B

甲：换了新版本的B，导致性能下降啊

乙：开多线程

甲：开了多线程导致延迟抖动不同步了

乙：换新的延迟修正算法

甲：换了新延迟修正算法偶尔会崩溃啊

乙：要不。。。我们还是去看看那个A开源库的旧版本崩溃能不能修好吧

如今上点规模的IT公司，其软件项目的规模和复杂度都远远超过工程师的能力上限了，都只能小心翼翼地修补，有时局部的大改动会引发连锁反应，大改动的风险和成本很难控制，没有巨大的收益谁也不敢随便改，你能看到的问题老员工看得更清楚，甚至也清楚怎么解决，但是不动手的原因就是不知道出了事谁来背黑锅，技术上的事情谁敢说100%不出事的。

那是不是大公司的技术项目就没救了呢？

也不一定，有些事要等个机会的，常见的机会：

1. 技术基础平台大革命，比如移动互联网的兴起，从PC迁移到了手机端，很多旧的技术代码就可以抛弃了，手机上从零开始。

2. 竞争对手小宇宙爆发，对手搞出一项技术取得了竞争优势，被迫追赶，这时候死马当活马治，改出任何问题也都能忍了。

3. 人事大动荡，管理层和基层都大换血，旧代码已经没人有能力维护下去了，不得不重来。

题主你看到了很多槽点，但我认为你不能只看到槽点和大概怎么解决。有没有想过怎么改进，如果是你的话你怎么做，这些项目里面临的主要挑战是什么，次要的挑战又是什么？

不要只告诉我技术A弱爆了，用B就可以完爆这个项目了。你知道用B的优劣，B的适用场景以及适用B的成本吗？对于一间公司来说，成本是很重要的。我这里说的成本不是金钱。而是，假如你看不爽一份代码，你打算重构它，你觉得你需要投入多少时间，多少人力？重构之后，又要花费多少时间和人力去升级依赖这份代码的其他项目？不要以为开会无用，老板就只是在天天发邮件。如果你重构了一份代码，不能通过沟通说服其他组去升级他们的组件，又或者你只是重构了一份虽然很丑陋，但其实并没有多少程序依赖它的代码，又又或者你重构了代码只是让代码技术含量更高了，更好看了，却没给公司带来多少收入甚至KPI，那你的工作和成果就很尴尬了。

其实上述也解释了为什么你身边的同事都眼睁睁地看着这些丑陋的shit存在而无动于衷。因为他们也是需要投入成本的。先不论他们个人技术水平高低，试问谁愿意挑一个又艰难，又不能产生多少效益的任务去做？当然，你会说，写好代码是程序员的节操。抱歉，节操多少钱一斤，北京三环商品房多少钱一平？

编程高手都有真爱，但现实就是编程高手凤毛麟角。我们身边的大部分同事可能只是希望养家糊口，他们头上还挂着十几个bug等着修。我们数落他们没追求，但追求从来都不是嘴上说说，吐吐槽就能实现的。

人心如此，公司也如是。

矛盾分主次，公司的目标都是一样的：用最少的成本投入到最能产生效益的项目中去，或者投入大成本去解决公司最需要解决的问题，这间公司才能继续运作。

所以题主你想想，在你吐槽的个案中，有多少是公司真正关心的？有哪些是你的老板认为可以创造最大效益的？有哪些才是主要矛盾或者挑战需要最牛逼的人挺身而出第一时间解决？去辨别，解决这些关键的问题吧，骚年。必要时带上（忽悠）一队人马（同事）跟你一起干，苟富贵，勿相忘。不要像祥林嫂一样，天天抱怨着生活，日日思考着辞职。得罪点说一句：“沦落”到要跟这样的人共事工作，难道自己身上就没有原因？

这个世界有更好的公司，有更牛逼的人。如果你认为解决这间公司的这堆问题不值得，又或者同事实在太不给力，就远走高飞吧。

我以前也跟题主一样，看我第一份正式工作的很多技术环节都相当不爽。这份代码写得丑，那个设计像大学生作品，重要的项目居然连单元测试都没有……但是我后来反观我自己，并没有发现比起那些丑陋代码和糟糕实现强悍多少。我跟我的同事没有质的区别。我笑话他们代码混乱bug不尽，我何尝不是少处理了一个field，倒腾错了一个片段的数据搞到要翻工重跑？在我心底里艹了隔壁组那个“我的程序好像不能跑，你帮我debug下”的同事一千次之后，带我做ML让我倒腾数据并且被我的程序搞坏了几份数据（当然后来搞好了）的T9君在会议上说：“她已经很努力了，我承认我有时候也逼得她太紧，她应该有多些时间的。”

我不是长者，不能share多少人生经验，就留下最后一句话跟诸君共勉（好像有点怪）吧：

我观别人大傻逼，料别人观我亦如是！

1.大公司业务极其复杂

毕业第一年在腾讯工作，做QQ游戏大厅，当时用的IDE是VC2006，用的版本控制工具，叫 ClearCase(估计用过的人不多)，IBM 开发的。特点是极其严谨、非常强大，但流程极为繁琐，用起来简直让人抓狂，这还是腾讯花了3000万找IBM买的。而业务的代码量几十万行，dll就有几十个，工程编译一次需要20分钟以上。

离开腾讯多年后，问了问，他们还在使用VS2006，还在使用CleaerCase，原因很简单，更换新版IDE需要解决大量技术问题，而业务又在高速迭代，只好不了了之，更换版本控制工具？历史的各种Log就会丢掉，要是出现什么稀奇古怪的突发问题，还得去看CLeaerCase。

业务的复杂性还会导致耦合严重，一但代码工程产生耦合，改动一个地方就会牵一发而动全身，这种情况下引入任何新技术都会带来极大工作量。

大公司的业务代码，有时候明明感觉有bug，却能运行良好。

这是一个前人留下的屎堆起来的一个克苏鲁缝合怪，看起来摇摇欲坠，有无数的虫子爬来爬去。但勉强堆起了山一样的形体，蠕动着为老板赚钱。

顺便在这里送大家一份珍贵的算法笔记，是一位阿里P8大佬撰写的，刚刚开放下载！程序员多刷算法好处多多，算法好的朋友进大厂非常容易，刷完进大厂很轻松：

这本书的目录，非常经典：

2.大公司技术历史包袱重

大公司之所以能成为大公司，一定是找到了稳定持续盈利的业务模式，这些业务对应的产品，动辄横跨几年甚至10年，这些年业界的技术高速发展，但大公司要保证业务的稳定性，即便再落后的技术，只要能给老板赚钱，就是极好的。

你想尝试引入新技术？能带来多少用户价值、商业价值？导致系统崩溃了怎么办？小公司系统出点问题无非是影响几万用户，大公司的产品要来点小问题，就算1/100的几率，拿QQGAME上亿用户来说，那就是100万用户出问题，一下就给公司带来几千万的损失，这么大的锅，谁敢背？

所以大公司的技术leader在引入新技术这方面，一定是趋向于保守的，人都是趋利避害的，用了新技术成功了，并没有肉眼可见的好处，失败了？直接卷铺盖滚蛋吧。

3.大公司新人入职离职频繁

铁打的营盘，流水的兵讲的就是大厂，大厂每年应届招聘动辄数千，社招再来数千，离职也不下几千甚至上万。很多开发的还是外包人员，外包人员的流动性可想而知。

在这种人员流动速度面前，能勉强把旧的技术系统吃透就烧高香了，哪有心情和心思研究新技术，除非真的是遇到了某个技术困难非要迭代进化，否则很难有动力去驱动。

以上三点，是我在大公司工作多年后的一些心得，但这么说大公司的技术难道就没救了？

当然不是！

大公司在以下几种情况，也会爆发出惊人的技术战斗力：

1.组成攻坚小团队，开疆辟土

这个最经典的就是腾讯的微信团队，2012年马化腾接受张小龙的建议，要杀入移动通讯领域。公司并没有只让QQ团队来研发这个新事物，而是同时启动3个敏捷小团队和QQ团队一起赛马。最后的结果大家也知道了。

微信团队今天取得的成绩不光是用户量，同时也有多端通讯实时同步的领先技术，这项技术在2012年属于绝对领先且碾压的技术。微信团队的前身是foxmail，张小龙创造性的把邮箱的实时同步引入到即时通讯领域。

哪怕到了今天，微信团队从几十人成长到几千人，微信的技术依然保持着高速进化的状态。

2.业务老人走光，无法延续

这种情况比较极端，但也会发生，大公司老团队的业务leader跑路，然后带走骨干，又或者自然流失殆尽，导致旧的系统新人完全无解，或者迭代极为缓慢。

新Leader这种情况下，选择大刀阔斧，直接大规模重构，甚至重写。在腾讯互娱大部门，某一个游戏团队就发生过这样的事情，反而让各种新技术充分落地应用。

3.技术密集型的业务，必须不断在技术层面取得突破

哪些是技术密集型的业务？比如谷歌的搜索、微软的操作系统、亚马逊的云计算、华为的5G。这些大公司的业务，你丝毫不用担心技术上有任何落后。

他们事实上已经进入技术无人区，必须依靠企业的内发创造力，不断取得突破。所以他们会大量招募全球最顶尖最聪明的人才。

比如华为会在俄罗斯广泛招募数学天才，微软亚马逊吸引了大量能力智力双高的华人。

最后说下我对大厂的总体看法：并不是大厂员工能力问题导致某些技术落后，完全是业务和商业市场的选择导致。

另外，我认为程序员职场初期（前五年）进大厂是非常必要的，不管是不是最先进的技术，最起码完善的技术培训体系、薪资福利、更人性化的管理、人才密度等等，完全碾压小厂。

程序员多刷算法好处多多，算法好的朋友进大厂非常容易，送大家一本阿里P8撰写的算法笔记，刷完进大厂很轻松：

看看这本书的目录和排版！相当经典！

祝大家前程似锦，在编码的道路上一马平川。

码字不易，如果大家觉得我的分享有用的话，请帮我

@findyi

点个赞，一键三连呗，笔芯～

公司的成败取决于现金流，而技术只是辅助现金流的工具。

说公司可能很难理解，我们来说人。

为什么有人看上去很傻，但是还是活得好好的？

因为人类的存活靠的是消化代谢系统，血养循环系统。

这也解释了为什么世界上大多数人不聪明的，却还是能活得挺好的原因。

技术大神的时代过去了

在互联网刚开始刚开始的时候确实会出现技术大神秒杀众生，但是这种现象未来会越来越少。技术大神厉害之处并不在于其智力有多高，他们只是因为比别人更早的去学了大多数人都不认为重要的技术。等市场反应过来，发现市面上技术大佬就那么几个，于是他们就被吹成神了。

再有就是一些小众技术，这种技术很难对口市面上的工作，而大数人选择走技术路线也并不是对技术的热爱，只是想赚钱，这就注定了这些人从一开始就不会和技术大神那样去研究很难找到对口工作的技术，这同样也是一些技术壁垒产生的原因之一，比如搜索引擎，互联网安全，图形渲染之类的技术远远没有前后端开发，程序开发，移动端开发具有泛用性。

这样一来大部分的技术就不再是公司的主要瓶颈，只要慢慢砸钱总归是能做出来的。

公司首先要活着，然后才能去提升技术。

很多人以为公司是技术推动的，大错特错，公司是权力和财富推动的。

只要权力，财富足够，技术这东西请人慢慢弄就好了。

所以公司的管理层即使是技术出身，也不会对技术有非常执着的追求，到了一定级别他们就会去玩弄“权术”和“财富”，而把技术交由其他技术人员打理，毕竟打理技术是非常吃力不讨好的工作，技术迭代又很快，如果不持续投入就很难保持领先。而“权术”就更好维护一些，只要多见面吃饭，多聊聊天，交换一下资源和利益就好了。“财富”就更容易了，只要把钱投出去，等就完事了，在金融圈子里，这种方法被美其名曰“价值投资”。所以公司高层的行为永远是保持现金流的稳定，而不是一味追求技术。

能用就行，为什么要时刻保持最好状态？

你作为一个人，难道每天出门都会把自己打扮成最好的状态么? 成绩优异学生，是否应该在打游戏上也要全方面碾压才能算优秀？有钱人是否要把生活起居的所有用品全都换成顶级奢侈品才算有钱？

优秀，是有代价的。

公司的技术也是这样，技术是要钱去开发的。在很多情况下这种“优秀状态”的维护是非常烧钱的。维护得那么好，不出几年，等到新的技术出来，代码又会变成屎山。

所以管理层的思路基本上就是用到代码严重拖慢公司效率之后再开始做新的，而不是时刻把技术保持在一个高位状态。

技术优势很像是物理学中的势能，而且技术优势更像是用人力去推起来的势能，这种势能无时无刻不再消耗资源。公司的员工总要有人去维护，如果你把技术人员解散，如果未来如果有新团队接手的话是很难接上手的。而且大部分技术人员也很讨厌在屎山里大扫除，因为到处都是屎，完全没法清理干净。

削弱技术影响，增强管理优势

如果技术很好，代码很优美，那么就会削弱资历老，但没啥本事的老技术人员的优势。因为代码很漂亮，那么新来的实习生很容易接上，老技术人员工资那么高，为何不直接开掉？

但是代码很垃圾，这就会把公司技术人员拉到一个纯粹比拼资历的状态中去。老员工肯定是知道自己和同事早年在“屎山”的哪块地方拉的屎，哪个地方是干的，哪个地方是稀的。这就不是一个牛逼哄哄的新人能接上趟的了，新来的没看过老员工拉屎，自然也不懂屎山哪个地方会窜稀。

这也是为什么领导最好懂技术的原因，因为如果领导不懂技术，那么手下的技术员很容易忽悠住领导，即使你把手下炒掉，换新的，技术人员还是选取那些写起来最方便，但对公司来说后期不好维护的框架和规范。这时候领导要非常明确的指出技术路径，这样才能避免手下的团队被某个技术高管，忽悠着走上邪路。

另外这种屎山写法也是导致程序加班的主要原因，只要程序员加班多，那么这些程序员就会花大量时间低效率的维护垃圾代码，而没有时间去提升自己，或在家里创业，然后跳槽。这样对公司来说也就是多点工资而已，而不会伤及根本。

公司主力在哪里

在技术主导的公司中，代码质量肯定会高一点。搜索引擎几分钟才返回一个答案，用户早跑光了。

而在很多非技术主导的公司中，代码质量都会垃圾得一批，一方面是领导不懂技术，所以忽略技术的投入和影响，再一方面愿意留在这种不看重技术的公司混吃等死的程序员大概率也不会去做什么创新，即使把屎山更新了，也很难对外界吹牛。‘更新屎山的清洁工也好意思说自己技术牛B’？你就说你主导开发了什么吧？什么订机票的软件？那不是大学代码课的随堂作业么？

这些领导不懂技术，所以很难去优化技术环节的成本。他们想到的永远是他们擅长的东西，比如找关系把票价弄便宜点，然后打广告把票价卖高一点，和友商搞好关系，然后让他们长期使用自己的订票服务等等，总之就是不会在技术上下功夫。

他们害怕自己做出错误的决定，被开发人员忽悠着花大钱更新，万一最后得不偿失反而被交了智商税，还不如把这些人工资定死，让他们自己折腾。只要东西能用，就睁一只眼闭一只眼，实在崩溃了，就开始找他们算账。

技术岗位也清楚得，只要不崩溃，凑合能用，领导就不会找自己麻烦，那么就把东西做到刚刚满足领导要求，多一分的优化都是浪费，反正领导也不会多给钱。

订机票的不是大厂，造飞机开飞机的才是大厂。

订票软件门槛还不如很多大学生创业项目，这些东西纯粹是凭关系的行业，技术在里面是可有可无的。这种“二道贩子”企业最重要的是营销，是策划，是广告，是运营，唯独不依赖技术，怎么把票低价拿进来，高价卖出去才是重点。

进公司前首先要了解公司的现金流构成，对公司做详细调研。如果公司的现金流基本和你岗位没啥关系，那么你的岗位在公司就是边缘人，不过这种岗位很适合混吃等死。