从校园到职场测验

我们每个人都在从校园走向职场，那么从校园走向职场需要注意哪些问题，有哪些经验值得我们学习呢？ 以下是Study La小编为您整理的相关内容。 我希望你们都喜欢它！

我们先来说说职场中所谓的技术问题产生的原因。

1.是很久以前的产品了，是新秀产品。

这些巨头也是从初创企业起步的。 一开始他们的技术实力可能不是很好，而我们知道信息技术发展得非常快。 我们现在所熟悉的很多东西，都是十年前无人知晓的黑科技。从校园到职场，在这种情况下，继续运营的公司会有一些历史上粗糙和菜鸟的代码，有的可能还在运营，这很正常。

那么为什么它仍然在运行呢？ 说明这个东西虽然不够好或者不够正确，但是从来没有造成过大的问题，也没有给系统造成太大的麻烦。 所以，这个东西虽然不好，但是是以业务为中心的诉求。 企业技术部门解决问题的意愿和积极性并不是特别高。

2、需求迭代的产物

与教科书不同，职场中的需求是千变万化的。 有些初入职场的人会觉得公司的需求和要求经常发生变化，这是无法接受的，被认为是不正规、不健康的。 说实话，15年前甚至20年前，我们就说印度的软件产业最发达，开发流程最规范。 当时很多中国企业去印度学习开发标准； 他们认为印​​度在IT领域远远领先于中国。 然而，在互联网蓬勃发展的今天，哪家互联网公司会去印度学习开发流程和规范呢？ 谁说印度在互联网研发领域领先于中国？ 问题是什么？ 中国互联网产业之所以发展得这么快，就在于它没有包袱。 敢想、敢做、响应需求。 作为定制开发，强调需求的确认和定稿。 然而，这种模式在互联网时代却自寻死路。 你必须能够随时跟随需求，顺应时代潮流。 如果你按照所谓的瀑布流去做项目，如果你做互联网，那你肯定就没有机会了。 我刚毕业的时候，也遇到了这个问题。 领导说，好好学习软件工程。 今天我可以明确地告诉大家，在互联网时代，软件工程中除了敏捷开发之外的所有开发思想都值得学习。 你不需要考虑别人！ 如果你仍然认为自己的发展需要明确的边界条件、明确的需求确认、明确的发展路线，请离开这个行业。

因此，问题就出现了。 对于一个产品来说，最初的设计目标是A，但在开发过程中突然发现B才是真正的目标。 最终将目标A开发的系统的一半转换为目标B后，上线后才被发现。 需要兼容C、D的目标。所以，如果一个新人来看一看，不了解这次迭代的背景和历史，他就会想，这个系统到底是谁设计的，为什么是这样的？逻辑就这么混乱？ 不可能。 不断试错，不断调整，就这样了。

3.所谓正确的架构都有你不知道的陷阱。

就像上面提到的第三范式。 新人一看，你的数据结构有各种冗余。 为什么你不知道第三范式？ 大学课程，因为他不知道，当涉及到分布和负载均衡时，这第三范式无法满足快速扩展的需求。

因此，很多时候，教材中的一些例子和方法并不适应新的业务需求和应用场景。 这时候，只看过课本的孩子就会认为代码太烂，技术太低劣。

4. 技术演进的印记

一个运行多年的系统，在演化过程中会有大量不同的参与者。 每个参与者都会有自己的逻辑、想法和处理方法。 因此，在代码迭代中，往往会优先考虑技术迭代。 当务之急是优化最消耗资源的模块。 在不断的迭代中，可能无法保持代码的一致性和结构的一致性。 结果，一些原本很漂亮的建筑可能只剩下两三个模块了。 新的迭代代码替换了其他模块，但新人一看从校园到职场，就感觉这个模块非常复杂、冗长，里面塞了很多无意义的东西。 请相信我，这个美丽的技术结构经过几次迭代后，就会变得面目全非、杂乱无章。 然后等待下一位大神做整体重建。

5、侧重点不同的考量问题

比如，一个新人发现一个报表系统效率很低，耗时很长，他就嘲笑它，说它连索引都不知道。 怎么会设计出这么糟糕的结构呢？ 但他不知道的是，这个数据结构首先要满足每天非常大量的数据添加，然后需要每周生成一次。 那么如果按照他认为很漂亮的生成报表的结构来设计的话，那么增加的索引和数据字段的设计在日常生产中就会是一个大问题了。 在大量I/O开销的情况下，新数据的逻辑会导致数倍甚至十几倍的额外开销（不夸张），这意味着需要很多额外的服务器来支持，但效果是每周生成报告的时间从几十分钟缩短到几秒钟。 那么，如果你是老板，你会同意这样的计划吗？

如果没有大局观，只从局部角度看设计，就会自以为是，认为别人做的都是不好的、垃圾。

6. 在资源有限的情况下工作

大公司也缺资源吗？ 至少人力资源始终是紧缺的。 比如，有紧急活动或者紧急任务，时间特别紧急，程序员就得赶紧从第三方开源软件上抓一段代码，修改一下。 我就换了，塞了进去，反正生意还算满意。 至于不好的，实在是没时间了。 结果这个临时活动效果很好，于是就慢慢变成了常规活动，工程师就去做其他事情了，这段代码反正没有什么问题，就继续跑吧。 快来看看吧。 这到底是什么？ 代码到处都是锤子。 难道这个程序员不知道如何设计系统吗？ 得了吧，站着说话也没什么坏处。 我真的没有时间。 设计。

那么，我接下来讲一下：新人就不能对现有的系统提出问题吗？ 难道他们就不能提出改进计划和建议吗？

当然，这是你进入公司后要做的事情。 公司花钱支持你，让你完善系统，增强业务支持能力。 但这需要事先有正确的认识和思考。

首先，尽可能完整地了解系统。 当看一组代码的时候，明白所谓的不好、不好的原因，历史演进过程是怎样的，明白它在业务系统中的地位和价值。 当你有了一些认识和了解之后，我们再思考一下所谓的好与坏的问题。

其次，从你最有信心、结构最简单的地方开始，用你认为正确的方式修改一个最小的结构，然后经过测试和发布的过程，然后得到运维等的反馈。主管人员了解改进是否比旧版本具有比较优势，以及比较优势有多大和重要。 不重要也没关系，但是你要明白这个改进是否正确； 完成第一个之后，努力完成第二个。 当你能够成功发布，完成十个甚至更多这样的改进和优化，并且确认你的代码的比较优势确实很明显的时候，我们再来谈谈别人的代码到底好不好。 如果你做了这些事情，你不需要谈论它，你的主管会看到的。

三是不要轻易谈重建。 不要轻易谈论重建。 不要轻易谈论重建。

必须说三遍

我讲过一些巨头的技术架构中出现的一个架构悖论。 为了满足所谓的高扩展性原因，开发人员构建了一个逻辑关系极其复杂的系统。 他们说这个系统需要更多时间。 值得，因为以后如果有新的需求还可以灵活扩展！ 所以产品人员和运营人员要耐心等待。

新系统上线后，市场发生了一些变化，出现了新的热点。 运营商问，我们可以增加一些功能吗？ 技术人员表示：“抱歉，我们设计初期根本没有考虑这个需求，因为目前的架构太复杂，所以这个版本肯定不会支持。放心，我们会考虑的。”下次我们重构时。”

我的架构原则是适度的灵活性和简单性第一。 你会发现架构越简单，遇到新的业务需求时就越容易做出改变和升级。 这是一个非常简单的道理。 新工程师进来查看代码并理解逻辑。 成本低。 所谓照顾更多需求的可能性，这么说吧，人们设计了一种开发语言来照顾更多需求的可能性。 你也想设计一种开发语言吗？

再说说我一直想吐槽的另一件事。 PHP之所以能被发明并迅速传播并成为流传最广的语言，是因为脚本语言是最快、最容易满足需求的方式。 门槛极低，开发和测试极其简单便捷。 ，但是现在很多人都在研究各种PHP框架。 看来不做框架就不是PHP开发了。 我不明白。 如果你想开发一个框架，为什么要使用PHP？ 人们终于把事情变得简单了，你我又回来了。 现在当我看到那些所谓的灵活扩展的框架时，我感到不知所措。 这简直令人费解。 最后，学习成本大大增加，调试成本大大增加，优化成本大大增加，大大大大。 ，面对高并发场景，优化难度比原生态开发高出一个数量级以上。 当然，这是题外话，与今天的主题无关。

回到重构的话题

深入理解业务逻辑，力求360度无死角地理解各种业务逻辑之间的关系。 （如果你在大公司，能做到这一点，几乎可以让你成为神了！）

彻底了解当前架构的演进过程（踩了多少坑，解决了多少开发问题，如果不懂，请相信我，你一定会再做一遍！）

彻底理解各个模块的调用关系和相互依赖关系。

深入了解当前架构的瓶颈和问题。 （前提是你必须知道这个架构为什么能行，否则这个理解就相当于不理解！）

然后我们再谈谈重建。

最后但并非最不重要的一点是，问题也是机遇

如果你发现一个巨头还有很多连你自己都认为错误的技术问题，你应该感到高兴。 这不是你的机会吗？ 但你必须明白哪些是真正的问题，哪些是你的经验不足造成的误解。 ，你一步步解决这些问题，并在解决的过程中一步步理解系统。 到了一定程度，你就会了解更多，理解更深； 站起来喊这些垃圾那些垃圾，只能暴露你的浅薄和无知。 我不得不重复那句话，可能会失去友善，别做教科书SB。