本文有点长。主要整理自知乎上的同名讨论帖：《为什么有些大公司技术弱爆了？》https://www.zhihu.com/question/32039226/ ，有网友提问：
下面是萧井陌的回答，伯乐在线已征得转载许可。 楼主你好，我试着给你解释一下，希望你能满意。 新手经常会有这样的想法「这代码怎么这么烂？写的人干什么吃的？怎么能这样？为什么不按照书上说的做？」，这很正常，大家都年轻过，经历过这种阶段，我懂你心里的想法，所以也愿意详细地向你解释，这一切发生的原因是什么。 你说
你真的觉得『国内行业老大的互联网公司』会是技术和管理弱爆了的样子吗？ 你以为团队应该像永动机，但现实永远有各种摩擦、辐射、损耗。 内燃机的能量转化率，通常只有 30% 50%，但是它却是驱动全世界运转的核心引擎，顺丰京东的快递小车、联通全国的高铁动车绿皮、瞬时直达的飞机…… 机器尚不能 100% 效率运转，何况是人呢？ 你说我们的程序员每天都在查看邮件、问题工单，你说这些问题多半是我们设计不当造成的，请问你有试过统计数据吗？你大概只是『感觉』如此吧？ 事实上，经过十几年的发展，我们内部的『效率改进团队』已经非常高效成熟，每月、每周、甚至每天都会有新的改进，现在的业务处理方式，不说全世界，我可以自豪地说在全国我们是领先的，甚至是遥遥领先，不然凭啥坐到了全国龙头老大的位置呢？ 所以啊，你只看到了程序员花在业务上的时间，没看到我们内部的『效率改进团队』为程序员们省掉的时间，我觉得我有必要站出来为默默付出的『效率改进团队』说几句。 当然，楼主作为实习生，不知道这些事情进而产生了这些疑问，也暴露了我们的不足。我已经在『团队建设委员会』里提出了这个问题，大家一致通过了决议，以后我们会对新员工包括实习生加强企业文化、历史培训，确保我们的新伙伴们不仅知道要去哪儿，也要清楚我们从哪里来，长路漫漫，我们一同前行。 你觉得
当初公司起步的时候，整个项目都是几个初创程序员加班加点熬出来的，我知道你看过《代码大全》、《程序员修炼之道》、《Unix 编程艺术》，你对上面的准则信手拈来，你可否翻开床头柜上的这几本书，看看它们的出版时间呢？ 是的，公司起步的时候，这几本书根本还没有出版，彼时中国互联网方兴未艾，大家都是摸着石头过河。现在你遇到问题，你可以问朋友、问导师、用谷歌、用栈溢出、用知乎，我们写程序那个年代，看的是谭浩强、严蔚敏，用的是 52k 拨号上网，语言只有 C，编辑器是没有语法高亮和实时编译的，编译器是没有智能准确的报错的，没有现在这么多知识、也没有这么多规范和好资源、好工具。不过我们还是把项目做出来了，把公司一步步推到了现在的位置。 不过这个问题是客观存在的问题，谁也不否认，但是你知道为什么你被分配到了一个『代码看上去一团糟也不够规范』的项目吗？我们需要新鲜血液来重构一些老代码，所以你会被分配到艰苦的岗位上。我们希望你是勇于战斗的战士，我们更希望你能成长为经验丰富的老兵，而把你放到这种岗位，是对你来说成长最快的方式。 你认为
你不知道的是，我们最初用了开源软件（也就是你所说的『老版本』），它构成了我们早期项目的基石，随着业务复杂性增加，我们改进并最终切换到新版本。 这个软件跑老业务非常成熟，但是在一些新业务上有不可调和的矛盾，所以在痛苦的适配后，研发部的同事们自告奋勇用 20% 的时间写了新业务的组件是的你没看错我们也有 20% 时间，我们鼓励工程师的创新。 至于你说的开发人员造的轮子这说起来可真有趣，它其实是前年来的一个清华大学实习生写的。 当时他来了之后，针对他接手业务的需求，向我抱怨说现有的 3 种都不好，要写一个新的来『统一天下』，这话是他的原话，我记得非常清楚，因为以我多年经验来看这样的做法是不可取的，但是本着锻炼年轻人的心态（加上他的确是不可多得的天才），我同意了他的请求，于是我用自己的业余时间接管了他的大部分工作，全力支持他写一个新的组件，帮他挡住了所有上面的压力，后来的故事就是你看到的这样。 是的，他后来越深入、就越来越感到业务的复杂，不断推翻重构、拆东墙补西墙，但始终发现和自己想的根本完全不一样，受不了了就走了，留下来这个。 我们明年的规划中，就包括剔除这个组件的 codebase，因为它实在是太糟糕了。 你又说
拦截器并不如你所想的那班美好，也许你在自己的电脑上写过一些玩具代码，觉得这样很方便、酷炫，但是真正到了战场，你会发现没什么才是必须的、好的，只有适合的才是对的。 至于配置文件，这么说吧，IDE 的配置文件传到代码仓库是我定下的规矩，『怎么会有人定这样的规矩？』，是的你可能从软件工程的教科书上或者某些『知名博客』上读到了不能这样做，但实际上这样做在很多情况下是必须的。 原因何在？ 这样可以确保代码克隆即可用，而不是让每个人都去设置一大堆无聊的东西，这样不仅节省时间，也确保了每个人的环境一致性，你想想这几年火热的 docker，应该明白了这样做的正确性和必要性了吧？ 你可能会说即便如此、插件也不用上传到服务器保存，我告诉你这样是不行的，你要考虑到我们这个项目前后十余年，你觉得几个插件能坚挺十余年？很可能我们早期用的软件，现在你已经完全不可能找到了，所以保存一份备份是非常有必要的，决不能错误地认为是冗余。 教科书只会教你基本通用的原则，树立你基本正确的观念，但是如果只是死守教条，如何能拥抱日益复杂的变化呢？ 你看的教科书，且不说时间上已经是二十多年前的了，在适用性上，也不说就是真理，IT 行业发展日新月异，几个月就是沧海桑田，为了适应这样的变化，认真地思考、总结、判断才是最重要的。 你觉得
你大概不知道，当初跑在你口中的「一个没什么qps的边缘接口」上面的业务带来了公司曾经 90% 的收入，所以我们用了复杂的设计以应对当时的需求，当然现在业务转变，老系统不再需要处理那么多业务了，但是更没有理由为一个『works perfectly well』并且不再重要的业务重构代码吧？ 所以，不是我们秀技术，而是业务需求 业务变更使然，年轻人还需要多学习一个。 你抱怨
我再强调一次我们是全中国同类公司中技术能力第一的，你所说的问题，当然是不存在的。 我们有专门的 Hadoop 集群来分析日志，当然也就用不着 Excel 了。 对于我们这种体量的公司来说，不存在什么『常数集合』，代码必须用合适的数据结构这是常识吧？ 特殊的算法和业务掺杂以增加内聚性，这是我们多年的经验，的确，它和教科书上说的不一样，但是我前面说了，死守教条是不行的想必你一定知道 OSI 7 层网络模型吧？ 公司的技术氛围浓厚，是和公司的基因分不开的，我们公司最重要的原则就是『拥抱变化』，从十几年前的机房托管单机到现在的庞大自建集群，技术跃迁了何止千万里，所以每个人都在学习新知识、每个人都沉浸在新知识的喜悦中。 你的问题，大多都是因为没有考虑到公司的庞大体量和十几年的技术跃迁才有的疑问，这点不再赘述，自行体会吧。 你想的是
其实那不是 SVN，那是我们公司自主研发的适应我们内部需求的 源代码管理系统 和 文件管理系统，你可以往里面放任何东西。 你所说的「无意义提交、一多半的提交连都编译不过去」其实只是表象，这套系统代号 TITAN，它自带 CIDD（持续继承、交付、部署），所以这些无法编译的提交都是不会有机会走到下一步流程的的。 如果你工作了一年，你就会发现这个需求是很重要的，改动、尤其是大型改动，中间会有很多非可用但有需要存档的步骤，现有的源代码管理系统都不能很好地支持这些需求，因此你也被教育了一套适应落后工具的思想。人啊，最重要的能力是改进工具，所以用 TITAN 的时候要拥抱全新思维，不要被落后思维捆绑。 如果你工作了几年，你可能还会问为什么我们没用 Jenkins、Travis 等工具，其实呀，就在 TITAN 之中呀，它凝结了公司最优秀的人才的十几年宝贵经验和心血。 By the way，我们最近正计划开源它，为中国开源社区做贡献，也希望提高业界的综合素质。欢迎你提交 PR 哦。 你最后说
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
