今天看了一篇文章为什么有些大公司技术弱爆了？。大概讲的就是知乎上一位题主在一家大公司中对于大公司的所用技术的吐槽，下面还有这个大公司一位有年份的技术人员对于题主吐槽的一些看法。

开始看这片文章时，我感觉题主以自己的视角看到了许多公司中的问题，让人感觉也许大公司的技术过度的偏向于保守，并且在流程规范上不够正规，对于新事物的接受能力很差。接下来回答问题的这位答主却将我之前对于该公司的偏见一扫而空，我们且来看看答主对于题主个个问题的答案：

1. 代码写的一团糟，全是复制粘贴，连作者都没改，大家普遍不写注释，也不格式化，代码歪歪扭扭。

当初公司起步的时候，整个项目都是几个初创程序员加班加点熬出来的，我知道你看过《代码大全》、《程序员修炼之道》、《Unix 编程艺术》，你对上面的准则信手拈来，你可否翻开床头柜上的这几本书，看看它们的出版时间呢？

是的，公司起步的时候，这几本书根本还没有出版，彼时中国互联网方兴未艾，大家都是摸着石头过河。现在你遇到问题，你可以问朋友、问导师、用谷歌、用栈溢出、用知乎，我们写程序那个年代，看的是谭浩强、严蔚敏，用的是 52k 拨号上网，语言只有 C，编辑器是没有语法高亮和实时编译的，编译器是没有智能准确的报错的，没有现在这么多知识、也没有这么多规范和好资源、好工具。不过我们还是把项目做出来了，把公司一步步推到了现在的位置。

不过这个问题是客观存在的问题，谁也不否认，但是你知道为什么你被分配到了一个『代码看上去一团糟也不够规范』的项目吗？我们需要新鲜血液来重构一些老代码，所以你会被分配到艰苦的岗位上。我们希望你是勇于战斗的战士，我们更希望你能成长为经验丰富的老兵，而把你放到这种岗位，是对你来说成长最快的方式

题主看到的这些代码与自己所了解到的规范不符合，吐槽一番，却忽略了写这些代码的年代，在那个时代的工具没有现在的好用，当时的资料也没有像现在这么全面。

2.一个项目里，httpclient竟然出现了四种。一种是该公司研发部写的，一种是老版本的开源项目，一种是新版本的开源项目，还有一种是开发人员造的轮子

你不知道的是，我们最初用了开源软件（也就是你所说的『老版本』），它构成了我们早期项目的基石，随着业务复杂性增加，我们改进并最终切换到新版本。

这个软件跑老业务非常成熟，但是在一些新业务上有不可调和的矛盾，所以在痛苦的适配后，研发部的同事们自告奋勇用 20% 的时间写了新业务的组件——是的你没看错我们也有 20% 时间，我们鼓励工程师的创新。

至于你说的开发人员造的轮子——这说起来可真有趣，它其实是前年来的一个清华大学实习生写的。

当时他来了之后，针对他接手业务的需求，向我抱怨说现有的 3 种都不好，要写一个新的来『统一天下』，这话是他的原话，我记得非常清楚，因为以我多年经验来看这样的做法是不可取的，但是本着锻炼年轻人的心态（加上他的确是不可多得的天才），我同意了他的请求，于是我用自己的业余时间接管了他的大部分工作，全力支持他写一个新的组件，帮他挡住了所有上面的压力，后来的故事就是你看到的这样。

是的，他后来越深入、就越来越感到业务的复杂，不断推翻重构、拆东墙补西墙，但始终发现和自己想的根本完全不一样，受不了了就走了，留下来这个。

我们明年的规划中，就包括剔除这个组件的 codebase，因为它实在是太糟糕了。

其实这个问题我们公司的项目也遇到过，在使用一些库的过程中，随着时间的推移，一些问题渐渐暴露出来，而有些第三方库由于某些原因不再更新了，此时你想要替换掉这个库，用个更新版的，却发现想要替换掉它时牵一发而动全身，所花费的时间成本和未来可能遇到的问题都是未可知的，索性在新的地方用新的库老的地方保持原样，逐渐迁移代码才能慢慢解决问题。

还有一些问题就不再赘述，其实我们这些问题都用一个共性，在什么样的背景下产生的，有的时候我们看一件事在两种情况下会有两种不同的评判，题主已自身视角去看公司中的这些问题自然回觉得很多东西都很low，其实结合了一定是时代背景后在看这些问题时就会感觉其实并没有自己所感觉的这么差。

技术时刻都在更新，我们也需要不断的努力去跟上时代的步伐，以后在看自己现在学的这些技术也会觉得很low吧，哈哈。不知道到时的自己会如何看待今天的自己！