不过技术和管理方面，却弱爆了。
那里的程序员，每天都在看邮件，查问题工单。
这些问题，多半是他们设计不当，造成的。
代码写的一团糟，全是复制粘贴，连作者都没改，大家普遍不写注释，也不格式化，代码歪歪扭扭。
一个项目里，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，用旧的 GCC 编译不过啊
乙：换新版本GCC
甲：换了新版本GCC，B开源库不兼容啊
乙：换新版本的B
甲：换了新版本的B，导致性能下降啊
乙：开多线程
甲：开了多线程导致延迟抖动不同步了
乙：换新的延迟修正算法
甲：换了新延迟修正算法偶尔会崩溃啊
乙：要不。。。我们还是去看看那个A开源库的旧版本崩溃能不能修好吧
如今上点规模的IT公司，其软件项目的规模和复杂度都远远超过工程师的能力上限了，都只能小心翼翼地修补，有时局部的大改动会引发连锁反应，大改动的风险和成本很难控制，没有巨大的收益谁也不敢随便改，你能看到的问题老员工看得更清楚，甚至也清楚怎么解决，但是不动手的原因就是不知道出了事谁来背黑锅，技术上的事情谁敢说100%不出事的。
那是不是大公司的技术项目就没救了呢？
也不一定，有些事要等个机会的，常见的机会：
1. 技术基础平台大革命，比如移动互联网的兴起，从PC迁移到了手机端，很多旧的技术代码就可以抛弃了，手机上从零开始。
2. 竞争对手小宇宙爆发，对手搞出一项技术取得了竞争优势，被迫追赶，这时候死马当活马治，改出任何问题也都能忍了。
3. 人事大动荡，管理层和基层都大换血，旧代码已经没人有能力维护下去了，不得不重来。
大公司常常会遭遇两种病症，我管它叫“滑坡与蒸发”现象。
具体病症如下：
1.滑坡：招聘标准持续降低。人资的硬标准或许在提高，但是实际技术标准在降低。s 级的老一辈面试官，能容忍 a 级的应聘者，过了几年这个 a 级的应聘者自己成了面试官，能力却没提高到 s 级（提高不仅靠个人努力，也要看历史行程），于是他能容忍 b 级的应聘者……所以叫滑坡现象。
尤其是当这家公司历史上经历过极速壮大时期的话，滑坡现象就更加明显。你甚至会发现一线员工技术水平远低于早已脱离一线的经理层。
2.蒸发：如果团队建设跟不上业务发展，大部分人都会处在疲于奔命实现需求的状态，技术水平和交付质量长期得不到提高。个别人由于努力和运气，技术提升较快。如果他没有一个清晰的通道将能力体现出来，就会出现两种可能——要么他会拒绝继续提升，反正现在也够用了，同事还不如我呢，大公司一般又不裁人；要么他觉得同事不行，跑了，蒸发了。最终留下来的人反而是相对平庸的人，那些利用公司资源达到较高水平的人反而让其他公司得利。
最终当你来到这家公司的时候，你就会奇怪为什么他们的技术不如你想像的好。其实不是没有能人，只是要么在经理室里，要么已经蒸发了。
PS：我补充一点，已经有相关领导澄清了，题主的观察可能有偏颇。但是我假设题主的观察没有偏颇，那么是不是你理想中的项目状态就一定好于你看到的“乱糟糟”的状况？
答案是不一定。
不说大道理，我举个例子，题主在互联网圈子里，可能没见过一个版本控制工具，叫 ClearCase，IBM 开发的。特点是极其严谨，极其强大，极其复杂。如果你只看流程图的话，那绝对是严谨到完美的版本控制系统。但是实际用起来的体验如何呢？只能说，让人挠头啊……所以，你想象的那种“清晰而优美”的项目，维护起来，可能是极其难受的。
新手经常会有这样的想法——「这代码怎么这么烂？写的人干什么吃的？怎么能这样？为什么不按照书上说的做？」，这很正常，大家都年轻过，经历过这种阶段，我懂你心里的想法，所以也愿意详细地向你解释，这一切发生的原因是什么。
你说「
不过技术和管理方面，却弱爆了。
那里的程序员，每天都在看邮件，查问题工单。
这些问题，多半是他们设计不当，造成的。
」
你真的觉得『国内行业老大的互联网公司』会是技术和管理弱爆了的样子吗？
你以为团队应该像永动机，但现实永远有各种摩擦、辐射、损耗。
内燃机的能量转化率，通常只有 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 我怎么能不支持呢？我今天在知乎这个公众平台我明确说了我支持。
但是你也应该多学习一个，这个现实毕竟是现实，我们要兼顾各种考量。
你今天在这里渲染「大公司技术和管理这么差劲」，是不对的、是失实的、是欠妥的、是缺乏认真思考的、是未加深入考量的。
将来舆论出了偏差，你虽然不用负责任，但是你认识到自己的错误的时候，会后悔、会内疚、会难过的吧？
何处乌托邦？或许……等下一代？
总结就是，生产效率才是最重要的，世间万物最重要的是平衡。
怎样取舍、如何妥协，这不仅是大自然的规律，也是我们前进、发展的准绳和仰仗的原则。
不要只告诉我技术A弱爆了，用B就可以完爆这个项目了。 你知道用B的优劣，B的适用场景以及适用B的成本吗？对于一间公司来说，成本是很重要的。我这里说的成本不是金钱。而是，假如你看不爽一份代码，你打算重构它，你觉得你需要投入多少时间，多少人力？重构之后，又要花费多少时间和人力去升级依赖这份代码的其他项目？不要以为开会无用，老板就只是在天天发邮件。如果你重构了一份代码，不能通过沟通说服其他组去升级他们的组件，又或者你只是重构了一份虽然很丑陋，但其实并没有多少程序依赖它的代码，又又或者你重构了代码只是让代码技术含量更高了，更好看了，却没给公司带来多少收入甚至KPI，那你的工作和成果就很尴尬了。
其实上述也解释了为什么你身边的同事都眼睁睁地看着这些丑陋的shit存在而无动于衷。因为他们也是需要投入成本的。先不论他们个人技术水平高低， 试问谁愿意挑一个又艰难，又不能产生多少效益的任务去做？当然，你会说，写好代码是程序员的节操。抱歉，节操多少钱一斤，北京三环商品房多少钱一平？
编程高手都有真爱，但现实就是编程高手凤毛麟角。我们身边的大部分同事可能只是希望养家糊口，他们头上还挂着十几个bug等着修。我们数落他们没追求，但追求从来都不是嘴上说说，吐吐槽就能实现的。
人心如此，公司也如是。
矛盾分主次，公司的目标都是一样的：用最少的成本投入到最能产生效益的项目中去，或者投入大成本去解决公司最需要解决的问题，这间公司才能继续运作。
所以题主你想想，在你吐槽的个案中，有多少是公司真正关心的？有哪些是你的老板认为可以创造最大效益的？有哪些才是主要矛盾或者挑战需要最牛逼的人挺身而出第一时间解决？去辨别，解决这些关键的问题吧，骚年。必要时带上（忽悠）一队人马（同事）跟你一起干，苟富贵，勿相忘。不要像祥林嫂一样，天天抱怨着生活，日日思考着辞职。得罪点说一句：“沦落”到要跟这样的人共事工作，难道自己身上就没有原因？
这个世界有更好的公司，有更牛逼的人。如果你认为解决这间公司的这堆问题不值得，又或者同事实在太不给力，就远走高飞吧。
我以前也跟题主一样，看我第一份正式工作的很多技术环节都相当不爽。这份代码写得丑，那个设计像大学生作品，重要的项目居然连单元测试都没有…… 但是我后来反观我自己，并没有发现比起那些丑陋代码和糟糕实现强悍多少。我跟我的同事没有质的区别。我笑话他们代码混乱bug不尽，我何尝不是少处理了一个field，倒腾错了一个片段的数据搞到要翻工重跑？在我心底里艹了隔壁组那个“我的程序好像不能跑，你帮我debug下”的同事一千次之后，带我做ML让我倒腾数据并且被我的程序搞坏了几份数据（当然后来搞好了）的T9君在会议上说：“她已经很努力了，我承认我有时候也逼得她太紧，她应该有多些时间的。”
我不是长者，不能share多少人生经验，就留下最后一句话跟诸君共勉（好像有点怪）吧：
我观别人大傻逼，料别人观我亦如是！
发现楼里很少有人是从软件工程的角度来分析的，有的明显扯得太远、太长、偏题了，真是遗憾。题主提到这些问题和现象其实没什么可奇怪的，无非是糟糕的软件工程管理所导致的一些 Bad Smells（涉及团队的开发流程、开发规范，系统架构设计，个人的开发技能等方面），以及中式软件工程江湖上几十年来的 “糙快猛”开发文化在互联网大公司的延续而已，多数过来人 70 后、85 前码农对这些传统陋习早已是习以为常、司空见惯的吧。
为什么大型互联网公司，技术和管理这么差劲，是怎么形成的？
大公司的一些项目团队技术差、管理差的现象在江湖上并不少见，尤其在软件工程基础和意识多年来都很薄弱的中式江湖就更不奇怪了。即便是一流企业，通常也会有一些表现差的二（三）流团队和部门。按照通常的逻辑，我不相信这些现象会出现在一流龙头企业的核心产品研发部门，所以最大可能这些是题主在一个二三流、非核心、管理较差的研发部门实习过程中看到的情况。
造成一个团队或部门技术差的原因其实也很明确：
主要是因为管理水平（如工程管理、技术管理、研发管理、项目管理、质量管理等等）差造成的。所以，板子应该打在相应的领导、管理者（如架构师、项目经理、研发经理、技术主管等）身上，而基层的码农可以说基本无责。码农的表现差，那也是因为领导把他们招进来，培养、培训、管理、带出来的。所以，团队技术差的主因通常是因为 技术领导、技术带头人（架构师）的水平差。
还有一些其他相对次要的原因，例如，公司发展太快，招人太多（大部分是低技能的编程新手），一时技术管理更不上，领导顾不过来，等等。
那么，为什么“糙快猛”开发对于中式软件江湖一直是有效的？
。。。
架构师水平差
一个项目里，httpclient竟然出现了四种。
一种是该公司研发部写的，
一种是老版本的开源项目，
一种是新版本的开源项目，
还有一种是开发人员造的轮子。
一个项目里采用的同一个功能构件竟然同时出现 4 个来源不同的版本应该说是反常的，也许在一个大公司的几个不同部门、产品线之间出现这种现象还能容忍。这个项目组的架构师去哪里了？难道就不能做点深入的技术调研，尽量作出一个统一的选择？当然，也许这个项目组正在同时对这 4 个 httpclient 进行比较实验。排除这种情况，感觉这个项目的技术管理是失控的，或者是因为这个项目的架构师岁水平不行，无法服众。
打接口请求响应日志，竟然不知道用拦截器。
打错误日志竟然不打上下文信息，每个人一种日志风格，千奇百怪。
许多重要的中间流程，居然不打日志。
同上，我还是觉得这个项目的架构师水平不行，没人懂 Logger 的价值，自然不会有人来作出规范。
所有服务间通讯，都没有设requestId，导致跟踪会话很困难。
同样是架构设计的问题，requestId 这应该很容易想到吧。
几乎没有文档，全靠从代码反推逻辑。
这个项目组的架构师会写文档，有时间写文档吗？
程序员们都是得过且过的态度，怎么把代码灌进去，跑的通测试，就算交差了。
一个项目组、团队没有一个靠谱的技术带头人，结局必然是这样的。
码农技能差
为啥一个项目组的码农技能差，代码惨不忍睹？因为大公司图便宜和高性价比，招了大量的嫩手，却又不给有效的在岗培训。
开发自测，居然要把代码全丢到公共机器上，而且都是走svn，他们把svn当ftp用。
svn里面大量的无意义提交，一多半的提交连都编译不过去。
我看到有个应届生，改了两句话，马上提交，说是怕代码丢失。
难道是半拉子的 CI？
可怕的是这个团队没有一个严格的开发流程规范，怎么提交代码，怎么集成，怎么测试。。。基本采取放羊式管理，责任还在架构师。也有可能是新员工培训的问题。
有枚举他不用，非要在每个页面上，把枚举值挨个儿写死，知道后面改代码多么费劲吗？
江湖俗称 Hard Coded。可见大公司招了许多嫩手。
欺骗性的变量名，里面存储的是AES加密的，变量名后缀却写成了DES；里面存的是小写字母，却写成upperStr。
一个方法十几个参数，有三分之一是极其简略的缩写，注释肯定也没有的。
一个类写到三四千行是常事。
估计这个项目组是不可能有代码规范的，也没有 Code Review，当然也可能规范神马都有，就是无法执行。
1. 理想主义： 现在的代码太烂了，应该去改改改
2. 现实主义： 支撑现有业务就是最好的代码，你说烂那是你不懂
一个团队，在任何时候，都应该 分辨得出：
分辨什么样的烂是真烂，什么样的烂是业务复杂；
分辨不出，就不要去修改。
也应该 积极寻求：
如果是业务复杂，能不能更简化更抽象一些；如果是烂，能不能在有限的成本中改好一些。
对于一个长期维护的软件和系统而言，
烂是合理的，懒是不合理的。不合理的事情多了，只会让未来更合理。
---------------------下面才是正文-----------------
为什么新人总是会觉得有落差，通常并不是新人的问题，也不算是现有产品的问题。
考虑到系统是经历了业务A - B - C这样的转换过程（这个 @萧井陌 也提到了例子），然后代码也是从无到有慢慢起来的，当时的Precondition，以及Dev Path，所以实际上现有代码是
然后新人来了后，只能看到现在的Condition，和现在的业务C，所以得到成本最低的系统是
有区别当然是正常的。
即便是持续重构所解决的，也只是降低A - B - C的业务变迁中成本，并不是现时的最佳方案 g。
而且，产品本身是要演进的，我们所要做的，是让产品到下一个版本，也就是
自己的成本最小化。而这个
最小化的时候，往往
。
我举个例子，系统在B的基础上实现C，引入了State设计模式。从C到D，仍然适合State设计模式。但是如果只看C，这个State很可能就被退化掉了。
这样，
反而要大于
第一，我认为毫无疑问是上一代的管理者的技术在跟进时代潮流这方面不如年轻人，没什么可说的
第二，不知道楼主有没有听说过Worse is Better的观点：
Worse is better
The idea is that quality does not necessarily increase with functionality. There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.实际上随着技术越深入，一定是对口的程序员越难招，维护成本越高以及边际效应递减的过程。
我给你举个例子。我在学校做过一段时间推荐系统的研究，看了很多paper，觉得这些paper很吊，觉得我可以去公司把各种paper里heuristic的算法改进（灌水）技术放到实践中，一点一点提升系统的性能。
去实习之后我傻眼了，实际上是十个工程师实现了一个最简单的推荐算法，系统就上线了。我去跟人聊各种paper里的算法，大家听着一愣一愣的。
实际上就是存在这个问题。我有技术，但是如果让我实践这些技术，所带来的一定是系统实现的复杂度和工作量成倍上涨。那怎么办？多招一些我这样的看过一堆paper的人？市面上这样的程序员比起安卓php程序员数量肯定要少，这是个不争的事实。而且这帮人坐地起价做出来的复杂度高开发时间长的东西所带来的流量提升也未必高了几个点，这帮人根本创造不了高工资对应的高价值，就是炫技。
前段时间Linkedin终于放弃scala了，为什么，招不到程序员啊。原来在里面的人可以随着这种转型在业务里学，但外面的人没机会就是学不会啊
再举个例子。已经有无数工程师吐槽过Facebook的快糙猛了， @grapeot 吐槽过里面随便拿一个分类器就上了， @王淮的书里面也讲过剑桥PhD去了水土不服的例子。为啥，不需要高深技术，需要随着业务快速解决问题。用的软件大部分都是现成开源的，把学术界过去50年无数聪明人的智慧扔在一旁玩简单粗暴，招一帮会写几个小玩具（可以很复杂，但一定经不起考验）的高中生去开发上线产品，你跟我说美国公司就多么重技术？
当然现在开始重视了，Facebook招research scientist成立AI Lab，Google有Google X。恩，不挣钱嘛，微软要裁自己的研究院嘛。Google X一个项目两年没啥就要砍了嘛。
我观察了一下身边导致此类现象的原因：
1）3个臭皮匠
有这样的产品人员，想到一个点子就觉得自己是天才，功能一上就能改变世界，晚3天上线就失去了成为下一个马云或者马化腾的机会。无论什么需求，研发说要十五上线，产品认为一定要初一上线，初一不上线世界就毁灭了，还动不动拿业务来压研发，遇到这样的产品人员，如果再配上一个听话的项目经理和一个任务分配器的研发leader，计划就这样定了！
怎么完成？ 不管，我只要初一上线；
质量如何？ 不管，我只要初一上线；
设计要扩展么？ 不管，我只要初一上线，设计优秀能带来用户？ 能增加收入？ 能提高KPI ？ 都不能你要设计做得好有屌用啊？
代码要优美么？不管，我只要初一上线，代码优美管我鸟事，我是产品我也看不懂！
。。。。。。。。。。。。。。。。。。。。。。。
2）做事不如无事，求变不如求稳
系统很烂，代码很差，但不关我事，都是历史原因，我改也改不动，改好了业务上也看不到，改出问题了还要被批，何苦呢？ 不改，有问题还可以找个背锅的，反正别人也不会去看代码。
新需求来了怎么办？ 很简单，if - else上吧，老的一行不动，新的我来重写，多简单，后面的人看不看得懂？ 不关我事，我到时候在不在还不一定呢
3）编程就是敲键盘
你们技术部门又不创收，又不节流，工资还要那么高，随便招几个人做完就行了，不就是敲代码么？ 我做产品的还写过两年代码呢，不就是if -else / 类 / 函数这些么！找个月薪15K的干嘛，10K也能做啊，10K的能做，8K的也能完成啊，或者一个15K的，我招两个8K的，多好，你们不是总是嚷嚷没人吧，我给你人还不行嘛？ 你看你们要3个，我都给你6个了，你还说啥啊
归根结底： 就是一个公司对技术的价值没有认识，只能看到业务的价值。
技术的价值体现：一个是质量、一个是效率，但偏偏这两个东东都不像业务那么有明显的指标衡量，也偏偏不像业务那样立竿见影，技术的价值需要投入、需要时间积累，投入是很容易看出来，而价值不容易看出来，也不容易很快看出来，所以，就悲剧了。。。。。。
========================2015.12.11补充=====================
通俗的讲， 技术就像一个人的身体，你不锻炼当然不会立刻就死，你把锻炼的时间用来做个兼职，还能赚点外快；但身体素质不行的话，就今天来个感冒，明天来个头疼，后天咳嗽，综合下来，你去医院的时间和花费的金钱，除了抵掉你赚的外快，还会让你倒贴更多；反过来说，你开始锻炼了，老板也不会给你加工资，客户也不会立刻就给你订单，但我相信没有几个人会因此认为锻炼没用，锻炼是浪费时间吧？
然并卵，就像大家都知道锻炼的好处，还是没有几个人会坚持锻炼一样，人类总是会在长远利益和短期利益之间选择后者！
题主这问题，非要言简意赅的话，大致就是这么两句：
A、这架构和设计稀烂！
B、这代码稀烂！
这两句话简直放之四海而皆准，但雄心勃勃的家伙，往往被现实糊上一脸。
原因很简单：成熟而理想的架构设计和代码，一般都过时了，不值钱。
业务在发展，公司在竞争，领先的新东西才能赚钱。但做这些东西都是在摸索中前进的，环境在变化，需求也不稳定，架构设计和实现也就随之改变，好听点叫架构演进，不好听叫推倒重做。
等到市场环境和需求都全稳定了，你的理想架构出炉了，市场上的坑也就早就被别人占完了。对，就是那些稀烂的东西。
对于客户来说，我才不关注你内部架构设计多优美，代码多精妙，语言逼格多高。只要这个系统它能工作，不犯错，不太慢，就可以了。
新架构出来了？关我啥事，它能多几个有用的功能么？能提高性能和效率让我更爽么？能少收我一点钱或者是免费么？
都没有？那关我鸟事！
————————————
实际上不仅仅是客户，当你接手一个产品或者项目时，同样会有困境：
~重新设计实现它的工作量有多大？
~资金和时间成本能承受么？
~质量和客户习惯的风险成本能承受么？
当你手头的资源有限，也承受不起那些成本和风险时，你也不会妄动。
当然，为了秀逼格改架构make title说的花言巧语，我很熟悉：
~新架构功能扩展性更好，当前一次性投入，未来增加新功能特性时的工作量很少，无需到处改动。
~新架构的弹性部署能力更强，未来系统容量扩充500倍时（业务量增长），我们能轻松使用配置实现，无需重新开发！
~新架构的代码更为精炼，可维护性更好，出了问题更好找更好修理，维护和运营团队的压力更少，可以节约维护成本。
~新架构的可制造性更好，生产环节少效率高成本低，连供应链的库存资金占款都减少了！（好像混进来了神马奇怪的东西）
~新架构的可安装性更好，客户自己就可以装好它，我们不用派遣工程队四处奔波了！（大雾，工程队是啥？农民工？）
~报！！！！！新架构的安全性更好，带有全自动的威胁分析和消除机制，能更早地发现潜在安全威胁并及时将其消灭在萌芽状态，我们不用担心美帝苏修和反革命分子的网络攻击了！
然并卵(ಠ .̫.̫ ಠ)
——————————
第三段，正能量
前面那些貌似make title的话，其实并不是讽刺。
在野蛮争夺的新市场，一个成熟的以产品说话的公司，就会在初步完成市场争夺之后，很快开始做架构设计演进或者重构，以进一步构筑足够的技术壁垒避免被人追上；有些基本全部依赖商业模式而不是技术的公司，有追求的话也会在有机会时尝试重构，以获得一些上述的内部收益。
而更为成熟的公司，不仅仅是在“修改现有架设”时会这么做，他们会持续维护一个架构设计或技术开发团队，在市场初步有苗头时就开始做新技术和架构演进/重构的研究了。
我们也总是希望自己能成为这样团队的一员，或者至少是在这个路上吧？
这就扯到什么叫做架构设计了，简单展开一下，尽量大白话。
首先要声明的是：架构设计往往跟看到的细节设计和代码质量并无直接关系。
就好像坚固的城堡与石块上粗糙刻痕之间的关系。
在架构设计时，其考虑的常见要素如下，根据不同的系统或项目会有所侧重。
~ 功能可扩展性：目标系统的当前功能，以及其可以预见的远期功能是怎样的。这是大家最容易理解的架构设计要素了，不展开了。在很多项目中，强大的功能扩展并不是首要考虑的对象，因为有句老话：“实现功能总是简单的”。
~ 环境依赖性：这是最常见设计局限，特别是大型工程，能使用的关键周边资源往往是已经运行多年的系统，并不能轻易改变。如果想以后不依赖或者更替，一般都要设计中间件，并顺带着付出运行性能、存储空间的代价。在使用开源组件时，往往也伴随着大量的适配，要么修改它从而带来维护压力，要么同样要做中间件。
~ 性能与容量可扩展性：系统需要达到的效率性能和容量是怎样的，可预见的远期目标是啥。需要注意的是，目标并不是越高越好，因为远期目标过于宏大时，往往实际达不到，会造成从来用不到的过设计和资源浪费。一般的扩展性设计会控制在1-2个数量级，而苛刻的性能设计往往导致优美结构的毁灭，但这是必须的。如今分布式系统被时常使用，不过总是会有人忘记做度量的。
~ 可靠性：在纯软件项目中，可靠性与可维护这两者往往被合并考虑；但在很多软硬件结合的项目中，这两者是分开考虑的。可靠性设计的主要问题是：各个部件的失效模式都有哪些，对外表现为怎样，它们之间是怎样相互影响的，失效可以被怎样检测并采取对应的消除措施；在高可靠性系统设计中，FMEA量化计算和裁决机制的引入是必然的。最常见的失误是：没有对失效模式做出正确的假设或核定，以及假设数据和检测总是可靠的。
~ 可维护性设计中，关键在于维护的操作流程是怎样的定义的，以及为了正常维护系统需要获取哪些关键度量数据。当然还有更难的：故障维护设计。当设计团队争吵什么是正确的维护流程时，我会建议他们去维护部门实习1-2周；但就算是这样，混乱而冗长的日志记录也继续很是常见，特别是软件系统的故障分析和修复，真心难搞。当然，现在也有简单粗暴的做法：重建。
~ 可用性：可用性是个很有趣的概念，在很多系统中它和可维护性混在一起，在另一些系统中它跟工程部署有强相关性。在大家常见的互联网IT系统中则化身为用户操作流程和体验。很多人将用户操作和可用性理解为界面的美化，但其本质取决于商业业务流程和操作逻辑；当与工程部署相关时，更会出现money talk的情况。
~ 人员技能依赖性：团队成员都会用啥技能，能快速学习和掌握哪些新技能，有哪些关键人员拥有能帮忙看护架构设计的关键技能。没有大团队管理经验的人，很容易在这个假设上载跟头，选择错系统实现语言、编译器、关键组件。我就不说C++曾经挖下的大坑了，呵呵。
~ 就知道有人会问奇葩的可测试性、可生产性、安全性、架构隔离自保设计，但是我就不说。
--------------
说一千，道一万，有志气的兄弟们应该会直面这些“稀烂”的玩意，敲下自己的一行行新代码，并经过严格验证+灰度测试后力排众议将其上线发布。当然，在这个过程中也需要付出自己额外的时间、汗水，承受可能的失败风险。
而当还没有累计起足够的工程经验和成功履历，也没有贡献代码，就开始动则谈哲学论架构和设计时，往往会与题干对应，得到别人奉送的两句金句：
A、talk is cheap, show me the code.
B、U can u up, no can no BB.
这么说好像太恶毒了？
正确的做法是自己提高效率也好，加班也好，在业务工作排期内提前完成，剩余时间去改进代码，很有可能改翔的时候粘一身，踩一堆坑，不要放弃，努力持续不断的填坑……直到最后也不会有人表扬你，给你加薪，甚至不会有领导发现
你说我为啥这么sb非要干这种没意义的事呢，没错，你的同事们也是这么想的
ps:给点正能量，看和改别人的代码是一件难度非常高的事情，一不小心就搞出一堆bug，但也是对自身水平提高非常有帮助的，至少我自己是经常这么做并确实获得了收获的。
在企业认可的预算范围内，只要能支撑好主营业务，IT部门内部搞得好一些还是坏一些，上层不会有人在意。
尤其在我国目前的市场环境，增加营收还是比控制成本重要。
本公司现在的系统，有一大坨（几十个）C++核心组件，并且依赖另一大坨（几十个）别组的C++组件/DLL。依赖组要升级代码到64位，我认为这是一个同步升级本组代码的好时机，顺便把VS 2008升到2013。挑战如下：
- 所有项目编译从x86改为x64；这个相当耗精力。
- 重点是，所有2003服务器要改为2008 R2 。。。
876
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
