并不适应新的业务需求和应用场景
让你去开心的，福利好也是有代价的，你要用能力和工作价值去换的。最近这些年，我的体会是，这个世界的商业规则在发生巨大的变化，是的，不只是科技进步，不只是新产品和新市场，而是商业规则在发生变化，而这个变化对传统巨头的冲击是非常大的。很多百年企业，几十年的巨头企业，都在最近遭到严重的冲击，但只能说在这个情况下，我们必须意识到，一些传统的认为正确的、优秀的东西，可能已经不适合新的商业规则。十年前大家还把索尼当作多么了不起的商业案例，但最近这几年索尼都衰落成什么样了。大众汽车遭受如此严重的打击，谁又想得到这可是严谨认真的德国公司？在这样的变局中，书本可以告诉我们一些历史，一些经验，但更需要我们从实践中总结，而且新的东西总是不经意间出现，然后瞬息间，把旧的颠覆。尽信书不如无书，我支持各位多看书，多读书，有些技术原理、有些基本理论确实没有过时，但是关于商业、关于市场、关于行业的发展方向，我们必须更努力地往前看，而不能迷信于书本。至于鸡汤;、成功学、媒体报道、企业宣传，你可以看，可以作为参考，但是你要知道，这些很多都是包装出来的、拼凑出来的，真相需要你认真挖掘。最后，切忌玻璃心，特别提醒一点，特别能抗骂抗造的，一般发展都不错。挑错的逻辑总有这样的年轻人进入职场，进入巨头公司实习，没多久就发现，为什么巨头的技术也这么烂啊，指出了七八个问题来。然而，你只看到了烂，而背后的逻辑和原因思考过没？大学里学到的所有典型的策略、算法、逻辑，在职场里，只是最基本的一些东西，甚至可能是已经被颠覆的东西，比如数据结构里强调的第三范式在高并发场景中早就被摒弃了，也就是你即便在课程里得到了满分，你来到职场，依然是菜鸟一名。因为你所面临的场景、业务环境、需求变更的频次，和你在学校里学到的完全不同。那么是不是说你就不能发现职场的问题呢？我们先说职场上所谓技术问题是哪些原因造成的。年代久远，菜鸟的产品巨头也是从初创公司起步的，在起步之初，可能技术实力也不是很好，而且我们知道信息技术成长性很快，现在我们司空见惯的一些东西在十年前还属于无人知晓的黑科技，在这种情况下，一个持续运营的公司，多少会有一些历史上很粗糙和菜鸟的代码，并且可能部分仍在运营，这是正常的。那么为什么会仍在运营呢？说明这个东西虽然不够好，不够正确，但是一直没有出大的问题，没有给系统添太多麻烦。所以，虽然这个东西不好，但是基于以业务为核心的诉求，企业技术部门并不是特别有解决的意愿和动力。需求迭代的产物和教科书不同，职场上的需求是瞬息万变的，一些初入职场的人会觉得公司需求经常改，要求经常变，无法接受，觉得是不规范、不健康的表现。15年前，乃至20年前，我们说印度软件业最为发达，其开发流程最为规范，当时很多中国企业去学印度，学开发规范，觉得印度在IT方面远远领先中国。但是发展到今天，在互联网大潮中，请问哪个互联网公司还会去印度取经学习开发流程和规范？请问谁还会说印度比中国在互联网研发领域领先？问题在哪里呢，中国互联网产业之所以发展快就在于没有包袱，敢想敢干，随需应变。传统软件工程领域里，印度可以作为定制开发的楷模，强调需求确认，强调定稿，但是这种模式在互联网时代是自寻死路，你必须能随时跟着需求走，跟着时代的潮流前进。如果按照所谓的瀑布流去做项目，你做互联网，必然没有机会。我刚毕业的时候，也遇到过这个问题，领导说，好好学软件工程，今天我可以明确地告诉大家，在互联网时代，软件工程里的所有开发思想，除了敏捷开发值得学习外，其他的都可以不用再考虑！如果你还认为你的开发需要明确的边界条件，明确的需求确认，明确的发展路线，请离开这个行业。所以，问题就出来了，一个产品，最初设计的目标是A，但是开发过程中突然发现B才是真正的目标，而好不容易把开发一半的目标A的系统转为目标B，上线之后又发现需要兼容C和D的目标，所以，新人不了解这个背景，这个迭代的历史，就会觉得，这系统谁设计的，逻辑怎么都是拧着的？没办法，不断试错，不断调整，就是这样过来的。所谓的正确的架构，存在着你所不知道的坑就好比前面说的第三范式，新人一看，数据结构各种冗余，你怎么不会第三范式啊，大学课程啊，因为他不知道涉及分布、涉及负载均衡的时候，这个第三范式无法满足快速扩展的需求。所以很多时候，教科书上的一些范例、方法，并不适应新的业务需求和应用场景，而此时，就会被只读过教科书的孩子们认为是，代码太烂，技术太逊。技术演进中的印迹一个多年运营的系统，在演进的过程中，会存在大量不同的参与者，每个参与者都会有自己的逻辑、想法，以及处理的方式。那么在代码迭代中，技术的迭代往往是优先考虑最紧迫的任务，优化最耗费资源的模块，在不断迭代中，代码的一致性和结构的一致性可能就无法维持，导致一些本来架构优美的结构可能只剩下两三个模块，新的迭代代码替换了其他模块，但是新人就觉得，这模块做得好复杂，好啰唆，很多没意义的东西塞在里
