聊聊大厂潜规则,有点子意外的
2024/12/12 23:03:05
本文主要是介绍聊聊大厂潜规则,有点子意外的,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
作者:五阳
为什么面试造火箭?
面试的时候,我有个习惯,我会先描述一个具体的问题场景,让候选人设计方案,同时让候选人聊聊如何解决这一类问题。因为这样和候选人探讨具体场景的具体方案,可以很深入的讨论细节,考察实际的系统设计能力,防止他夸夸其谈,询问如何解决这一类问题,能考察是否具备深度思考和抽象能力。
例如服务的full gc 非常频繁,半小时一次,如何解决这个问题,你有哪些思路?谈谈GC问题有哪几类,优化GC参数有哪些方向?
例如优惠券领券活动有库存限制,有总库存和日库存,系统并发度最高 1W TPS,要求设计一个扩展性强的库存系统?
为什么要这样提问呢?因为解决问题的能力和突显你的能力同样重要。解决问题要看结果,你拿到了好的结果,只能证明你解决了这个问题。如何突显自己的能力?要充分说明这件事的挑战、难点,要能说清楚解决方案的逻辑性。
在职场里光干活显然不够,活是永远干不完的。在大公司里,快速解决一个具体的问题和完美解决一个具体的问题,似乎是存在矛盾的。
快速解决一件事,一般使用改动少、风险低的成本低的解决方案,这种方案最终会被定为短期方案。而长期方案则有如下特点:
能解决根本问题,不仅针对一个具体特殊场景
不仅能解决当前场景的风险,更全面地解决潜在风险。
具备更好的扩展性,未来的需求来临时,更好评估和修改,需求交付更快。
系统边界更加清晰,职责划分更加合理。(至少上下左右相关方都认可的标准)
……
完成胜于完美
完成胜于完美,我上家公司的CEO说过这句话。那家公司研发团队少于500人,当时公司创建时间不足5年。
在中小型公司,业务压力非常大,业务的稳定性不足,往往需要团队快速试错,快速拿到结果。快速淌出来一条路,证明这条路是光明的。试错的次数足够多,成功的几率越大。
这种情况下,研发团队的目标是更快的交付需求,系统稳定性、系统设计合理性在初期是次要目标。
所以我们的CEO对公司产研团队的要求是完成胜于完美。 项目组采用敏捷开发模式,每天的晨会负责过项目进度,每一天会单独过个人的项目进度。 每个人每天干了什么活,当前有什么在跟进的项目在领导层到时明确的。每个人的压力也是非常大的。
当时领导对我们的要求就是快速完成需求,有困难提出来,领导帮协调解决。 大部分情况下甚至不写设计方案,对齐接口以后,直接写代码。
每天都有写不完的代码,什么都做过,什么都不精通。我感觉自己的成长很慢~ 这可能是小公司的通病。我做过很多项目,经验看似很丰富,但是如果问我精通什么?在这个领域,我足够专业吗?我的心里底气不足。
停下来思考的时间很珍贵~ 因为不停的有倒排期的需求,甚至需求提出越晚,上线要求越急,简直倒反天罡。
完美胜于完成
入职大公司一段时间以后,我开始意识到,原来大公司大部分时间不是在写代码,是在写技术方案,写梳理文档,写SOP处理方案,写重构方案。每天不是忙需求,而是在忙稳定性。
大公司里虽然没人说:完美胜于完成,但那是大家心照不宣的潜规则。
大公司里核心项目的产品形态已经很成功稳定了,产品经理的需求方案评审更加严格,项目规划也更长远。在落地前,会分析大量的数据得出业务结论,会花大量的时间思考产品设计,总之 产品经理更加专业,作为研发感受是:需求频率低了,沟通氛围更和谐了,上线要求没那么急了。
但这不代表你更加轻松了。因为要求你花在技术方案上的时间更多了,你需要考虑更多的事情,它会要求你的技术方案写的更全面。
你要做的足够完美,并且能告诉别人,它在哪些方面有挑战,我采用了哪些动作,化解风险,解决问题。至于完成这件事,这是最低的要求。
<顺便吆喝一声,技术大厂,前后端测试捞人,欢迎
>解决问题能力与推销能力都很重要
老黄牛不会说话,只知道干活,主人会认为他很辛苦吗?主人会想:“你干活的时候,我牵着你,我也在风吹日晒,我还要负责你的草料,所以你辛苦时,我更辛苦。”
主人会认为自家的老黄牛,能力很强吗?恐怕很难,老黄牛只能通过日复一日、老实巴交的干活,向主人证明:他是一头合格的黄牛,无法证明它是一头能力强的老黄牛。
只有你凸显了项目的挑战性,才能凸显你的能力。只有这样,你的领导才能向更高层领导,说清楚这件事难在哪里?
这不就是卷吗?
如何突显项目的挑战性,怎么做有亮点?
有这么几个方向,供大家思考。
需求复杂,我是如何和产品经理沟通的?
记录沟通过程。越是难以理解,沟通成本越高,可以记录和产品经理沟通问题的数量,并且逐个记录下,作为产品结论。例如 产品需求逻辑复杂,和产品经理沟通需求,总计35个沟通结论。
描述需求如何复杂,系统需要处理多少个场景,处理多少个极端问题,需要有多少个交互方。系统对外提供了多少个接口,新增调用下游多少个接口等等。
一定要可以量化~
系统并发度非常高,要求低延迟,我是如何解决的?
支持如此高的并发,系统瓶颈在哪里?自己是如何分析的
高并发接口应该如何设计?自己产出了哪些经验和方案,应该从哪些方面去思考。
如何进行存储系统选型?使用了本地缓存,分布式缓存,和数据库三级缓存。
使用缓存如何保证数据一致性?
全链路上多少个接口需要支持高并发,自己是如何梳理的,涉及多少相关方,如何沟通确认的。
如何规划系统容量?设计了全链路压测方案,压测出多少问题
如何识别高延迟的风险,有哪几类,例如GC参数不合理,协调优化了X个服务的GC参数,效果如何?
上下游相关方多,如何保证数据一致性
如何描述挑战:
相关方有多少个,相关接口有多少个,返回值多少个,极端场景多少个,是否有资损风险?
如何解决挑战 2. 如何识别出系统的相关方?如何保证是全面的 3. 相关方非常多,如何把问题拆解下去,问题和责任明确到个人。 4. 写场景,如何保证众多的参与方数据一致性?这本身是一个难题 5. 制定上下游接口规范,即上下游对齐数据一致性方案。例如最终一致性如何保证、谁是事务管理者谁是事务参与者、谁负责发起重试、系统是否要回滚、返回值上游如何处理、接口幂等性要求、超时了重试还是失败等等。如果没有一个组织者跟大家对齐标准,各系统各行其是,在异常和边角场景各参与方的数据不一致风险非常高。
拆解问题和制定标准规范 是很困难很有挑战的事情。
如何更好提供扩展性?
和产品沟通未来业务如何扩展,扩充的粒度是什么?
模型上如何设计的,预留了哪些字段,提供扩展性。
不同场景的流程存在差异化时,如何更好扩展呢? 使用流程引擎,提供流程编排能力。
流程上提供了哪些扩展点,业务可以自定义扩展。
上下游交互协议如何设计的?可以支持新的业务场景接入。
项目梳理成本高,我是如何梳理的?
如何体现梳理成本高? 接口数量、服务数量、页面数量、数据库表数量、相关团队数量等等。
如何拆解问题到个人,明确责任和分工。当工作量庞大时,分解工作量很重要。
领域:确保相关的领域都评估全了。拆解问题到对应的领域负责人,展现层:确保所有的页面都评估到了,接口层:确保所有页面相关的接口都评估到位,数据库:确保所有的表评估到,写入和查询逻辑,如何存储等。
项目时间短,我是如何快速完成的?
和产品沟通成本最低的解决方案,优先保证重要需求上线,一些不重要的问题能否二期再做。
协调更多的人力参与进来,拆解问题。
协调更多的开发时间,向上申请周末加班等(有加班补偿的情况下)
注重预期管理。越是紧急的项目,问题越多,风险越大,越需要不停对齐风险。当识别出风险以后,就能向上申请更多的资源:时间或人力。不要等项目铁定延期了,再向上报风险要资源,要注意过程透明。
明确项目里程碑,互相依赖的问题要明确交付时间和交付物。 例如X 日提供接口文档,X日提供接口Client,X日可以联调,X日可以提测。
前置完成下一阶段的事。当提测以后,接力棒交到测试同学手中,研发同学可以设计上线方案,设计监控告警方案,代码Review等等,提前完成下一阶段的事情。
项目人手不够,我是如何快速完成的?
人手不够,可以申请时间。人手不够,时间充足也能如期完成,或者砍掉不重要的需求。
可以申请将一些次重要的事情交给其他人去干。像组织例会、稳定性工作等协调类工作交给其他人,让参与人完全投入到代码开发。
拆分后的任务要独立完成,减少互相依赖的情况。如果有依赖,一定要明确交付时间和交付物,参考上一条。
多说一句:越忙的时候越要加班,至少做做样子,当领导发现你划水时,你申请资源的难度会增加(人和时间),这将导致你更加的忙~ 如果实在想划水,可以趴桌子休息会,营造自己很困的假象。这不就是卷吗?
不熟悉项目的情况下,如何保证需求交付速度和质量
不熟悉怎么办,那就慢慢熟悉呗。只要功夫深,铁杵磨成针。
要向上协调资源,在没有专业人下场参与的情况下,要尽可能的让熟悉项目的人,给自己讲解,给自己写梳理文档。对方不配合就找老板协调。
不熟悉项目的情况下,最容易遗漏事情。如果有一个熟悉项目的人,能告诉你哪几个接口需要改动,我相信你的工作量能下降很多。因为你不需要花时间在无关的事情上。如果没有这样的人,那么自己一定要提前做好规划,自己应该梳理什么什么东西,把计划列出来,尝试去执行,如果时间不允许,继续向上反馈,申请资源,增加更多的人手参与梳理。
在这个过程中,你要量化需要梳理的东西有哪些?这些都是挑战和困难。一定要量化。
项目相关方多,我是如何保证关键信息不丢失的?
项目相关方多,保证关键信息不丢失本身就是一个极大地挑战。
量化相关方的数量,数量越多,挑战越大。
相关方越多,越需要重视技术方案和评审。
每日例会,各参与方出责任人,对齐关键信息,由责任人向下同步。每日例会过进度,过关键风险。过遗留TODO问题
记录关键信息,确保项目参与者都能找到。
项目参与方多,需要项目经理负责以上问题。专业的人负责专业的事。
如何保证快速发现问题?如何快速定位问题?
快速发现问题本身就是一个挑战,项目的参与方越多,系统链路越长,接口越多,越难以快速发现问题。
全面有效的监控和告警能快速发现问题。又回到了那个问题,如何保证全面?这个问题可太难了~ 就好比 数学老师考试之前问你:"小帅,这次考试你怎么做才能保证考100分呢?”。
你可以回答:“我圆锥曲线、立体几何解析几何、极值求导等各种题型都非常精通,我有信心考100分”
数学老师:“这些我知道,你怎么证明你一定能考100分呢?”
这不就是卷吗?
全面性很难保证,但是你至少可以保证,你梳理的全面性。例如本次需求涉及哪些业务场景需要监控,你分别予以说明。拆分到页面、拆分到接口、拆分到数据库等等,保证这些异常场景有监控打点,保证上下游调用返回值都有监控打点,保证自身接口返回值有监控打点,制定监控标准,要求各接口负责人都按照标准做。做到这些基本上就够了。
如果想做的更好,则需要思考业务上有哪些异常情况,例如哪些流量突增突降等,分别配置告警策略。
做到这些就是很有挑战的事情。
如何保证快速恢复故障?
发现问题后,如何快速降级,恢复故障 灰度发布,要求所有的新功能都具备灰度能力。出现问题后,降级灰度,系统切回原处理逻辑,故障得到恢复。
又回到了这个问题,如何保证全面性?这不就是卷吗?
写在最后
当你看到这里,想必已经意识到在大公司里大部分时间不是在写代码,而是在写文档和PPT。
当你做这件事的逻辑如果无法自圆其说,甚至无法证明全面性、正确性时,那么这件事八成白干了。
完美胜于完成,大公司的潜规则~
这篇关于聊聊大厂潜规则,有点子意外的的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-12-22项目:远程温湿度检测系统
- 2024-12-21《鸿蒙HarmonyOS应用开发从入门到精通(第2版)》简介
- 2024-12-21后台管理系统开发教程:新手入门全指南
- 2024-12-21后台开发教程:新手入门及实战指南
- 2024-12-21后台综合解决方案教程:新手入门指南
- 2024-12-21接口模块封装教程:新手必备指南
- 2024-12-21请求动作封装教程:新手必看指南
- 2024-12-21RBAC的权限教程:从入门到实践
- 2024-12-21登录鉴权实战:新手入门教程
- 2024-12-21动态权限实战入门指南