致职场新人：我初入职场曾多次吐槽公司技术烂
一入IT深似海
不知道你有没有过这样的经历：刚刚进入职场时，进入公司实习，没多久就发现，为什么公司的技术也这么烂啊，啪啪啪，随意就能指出十几个问题来。 我们当初四十几个同学大四集体去北京找实习单位，当时学校把我们集体安排住在一栋排屋里面，我们工作之后下班经常坐在一起闲聊，聊的最多就是吐槽自己的公司代码很烂，当然也包括进入BAT公司的同学。
一、为什么我公司的技术这么“烂”？
Too Young Too Simple Too Naive
五年过去了，当我最次回想当年的闲聊时，狂笑当年的我们Too Young Too Naive。 你只看到了烂的表面，而背后的逻辑和原因思考过没？大学里学到的所有典型的策略、算法、逻辑，在职场里，只是最基本的一些东西，甚至可能是已经被颠覆的东西，比如数据结构里强调的第三范式在高并发场景中早就被摒弃了，也就是你即便在课程里得到了满分，你来到职场，依然可能是菜鸟一名。因为你所面临的场景、业务环境、需求变更的频次，和你在学校里学到的完全不同。
那么是不是说你就不能发现职场的问题呢？当然不是！我们先来说说职场上所谓技术问题是哪些原因造成的。
1、年代久远，菜鸟的产品
巨头也是从初创公司起步的，在起步之初，可能技术实力也不是很好，而且我们知道信息技术成长性很快，现在我们司空见惯的一些东西在十年前还属于无人知晓的黑科技，在这种情况下，一个持续运营的公司，多少会有一些历史上很粗糙和菜鸟的代码，并且可能部分仍在运营，这是正常的。
那么为什么会仍在运营呢？说明这个东西虽然不够好，不够正确，但是一直没有出大的问题，没有给系统添太多麻烦。所以，虽然这个东西不好，但是基于以业务为核心的诉求，企业技术部门并不是特别有解决的意愿和动力。
2、需求迭代的产物
和教科书不同，职场上的需求是瞬息万变的，一些初入职场的人会觉得公司需求经常改，要求 经常变，无法接受，觉得是不规范、不健康的表现。 15年前，乃至20年前，我们说印度软件业 最为发达，其开发流程最为规范，当时很多中国企业去印度，学开发规范，觉得印度在 IT方面 远远领先中国。但是发展到今天，在互联网大潮中，请问哪个互联网公司还会去印度取经学习 开发流程和规范？请问谁还会说印度比中国在互联网研发领域领先？问题在哪里呢，中国互联网产业之所以发展快就在于没有包袱，敢想敢干，随需应变。传统软件工程领域里，印度可以 作为定制开发的楷模，强调需求确认，强调定稿，但是这种模式在互联网时代是自寻死路，你 必须能随时跟着需求走，跟着时代的潮流前进。在互联网行业，很多开发往往是没有明确的边界条件，也没有明确的需求确认。
所以， 对于一个产品，最初设计的目标是A，但是开发过程中突然发现B才是真正的目标，而好不容易把开发一半的目标A的系统转为目标B，上线之后又发现需要兼容C和D的目标。所以，新人不了解这个背景，这个迭代的历史，就会觉得，这系统谁设计的，逻辑怎么都是拧着的？没办法，小步快跑，不断试错，不断调整，快速迭代，就是这样过来的。
3、所谓的正确的架构，存在着你所不知道的坑
就好比前面说的第三范式，新人一看，数据结构各种冗余，你怎么不会第三范式啊，大学课程啊，因为他不知道涉及分布、涉及负载均衡的时候，这个第三范式无法满足快速扩展的需求。所以很多时候，教科书上的一些范例、方法，并不适应新的业务需求和应用场景，而此时，就会被只读过教科书的孩子们认为是，代码太烂，技术太逊。
4、技术演进中的印迹
一个多年运营的系统，在演进的过程中，会存在大量不同的参与者，每个参与者都会有自己的逻辑、想法，以及处理的方式。那么在代码迭代中，技术的迭代往往是优先考虑最紧迫的任务，优化最耗费资源的模块，在不断迭代中，代码的一致性和结构的一致性可能就无法维持，导致一些本来架构优美的结构可能只剩下两三个模块，但是新人就觉得，这模块做得好复杂，好啰嗦，很多没意义的东西塞在里面。请相信我，再优美的技术结构，经过几茬这样的迭代，都会变得面目全非，杂乱无章。然后等待下一个神做整体的重构。
5、侧重点不同的考量问题
比如说，新人发现一个报表系统效率很低，耗时很长，于是嘲笑，连索引都不会吗，这么烂的结构怎么设计的？但是他不知道的是，这个数据结构首先要满足一个非常巨量的每日数据新增，而后才要满足每周一次的报表生成。那么，如果按照他认为生成报表的优美结构来设计，所增加的索引和数据字段的设计，就会日常带来大量的i/o开销，数据新增的逻辑就会导致额外几倍十几倍的开销，也就是说需要很多台额外的服务器来支撑，而收效却是，可以每周生成报表的时候从几十分钟缩短到几秒钟，那么如果你是老板，你会同意这样的方案吗？
6、资源紧缺的作品
大公司也会资源紧缺吗？至少人力资源一直是紧缺的，比如有个紧急的活动，有个紧急的任务，时间特别紧，程序员只好急急忙忙从第三方开源软件抓了一段代码，改改塞进去了，反正业务满足了，至于不好那也实现没时间了，结果这个临时活动效果还不错，于是慢慢成为常态活动，而这个工程师又去干别的去了，这个代码反正也没出错，那就一直跑着。新人来一看，这啥玩意啊，代码东一榔头西一棒槌，这程序员不会设计系统吗？
二、我应该怎么样解决这些烂代码？
不要迷失了自己
你要明白，哪些是真的问题，哪些是你涉世不深的误会，不要只是站出来喊，这些垃圾那些垃圾，这只能暴露你的浅薄和无知。
那么，新人就不能提出现有系统的问题吗？就不能提出改进的方案和建议吗？当然可以！但是，这需要有一个正确的认识和思路在前面。
1、尽可能更完整地了解系统，查看一套代码的时候，了解所谓的不好的起因是什么，历史演进的过程是什么，了解其在业务系统中的地位和价值是什么，有了一些认识和理解后，再来思考所谓好和不好的问题。
2、从一个最有把握，结构最简单的地方入手，用你认为正确的方式修改一个最小的结构，先通过测试、分布的流程，然后再通过运维和其他主管人员获得反馈，了解改进是否具备对旧版本的比较优势，以及比较优势究竟有多大，多重要。不重要没关系，但是你要了解是否这个改进是正确的；完成第一个后，努力去完成第二个，当你能够顺利分布完成十个或更多的这样的改进和优化，并确认你的代码比较优势确实明显的时候，再来吐槽别人的代码的问题。
3、如果你这些都做到了，你可能就不屑于吐槽别人的烂代码啦，因为你会把它们当作一个个小怪兽。
三、一些说明
最近在读曹大的《你凭什么做好互联网》这本书，书中很多内容写出了我初入职场时的心态和做法，这些曾经经历过的事不吐不快，本文内容基于书上的做了一些修改。
谢谢你的阅读，愿初入职场的你少点吐槽，多了解点真相。愿曾经也吐槽过的你，和我一起一笑而过。