实话实说:只会.NET,会让我们一直处于鄙视链、食物链的下游
金三银四,是个躁动的季节。 结合最近的面试,谈一谈一个老牌开发人员的面试感悟。
大家都知道我的主力技术栈是 .NET + Devops + 弱前端 (当前技术认知,不排除以后变化)。
面试了大小厂,有收获也有沮丧, 结合工作和面试谈一谈看法:
1. .NET 技术栈的现状
目前.NET普遍用在数字化转型的中小企业,或者用于一些OA、CRM等中小流量的站点。
.NET 技术频繁升级,虽然我自己也升级到最新的.NET 5, 但是并不会刻意关注新版本的功能。
从我实际使用看,每次这种升级也没带上肉眼可见的改变;或者说每次升级,并不能从Java、Javascript群体中抢的一块肉食。
这与一些自媒体上吹嘘的能力、抛出的JD并不匹配, 当然我这样说,肯定会引来很多骂战。
-
每次这种挤药膏式的小升级,我内心只会觉得是不是早期.NETcore 1.0设计不达预期,并不如当初横空出世时标榜的这么牛逼;
乃至每次升级都鼓噪.NET 2.0最佳、3.0最佳、5.0最佳,以后出.NET6,7,8是不是又打脸.NET5是最佳设计。
-
.NET 客观上讲处在追赶Java的时代, 这里我用时代这个时间概念; 物竞天择,不进则退,其他语言JAVA,javascript 也在进化,
主流技术大厂的技术洞察力相比信息化转型的中小企业更加深厚,主流技术大厂的技术雷达里面目前选择性忽略.NET, 他们宁愿用Go,也不会用已经20岁的.NET
🧛 二面鹅厂的对话: ".NET只能windows服务器下”的,当我准备说.NET 5年前已经跨平台, 有runtime时, 他们适时打算了我的话,下一个话题。 另一大厂面试官一开始也有这样的疑惑。
(不管你愿不愿意承认,市场上确实存在语言鄙视链(҂⌣̀_⌣́))
2. .NET的价值
大前端、微服务、云原生蓬勃发展, 但是大多数时候主流.NET技术还是用来做api 。
从我近2份工作(6年),不管是技术经理还是开发人员自身 ,都将.NET 定位为api;
不是说我们要刻意迎合微服务、云原生这些高精尖概念,
但是客观上讲,微服务、云原生提高了应对复杂业务的天花板,提高了应对高并发、高可用、可伸缩场景的能力, 而这些能力也是主流大厂目前需要的。
🧛 你现在回想一下, .NET结合微服务、云原生用到了哪些知名项目上;就算你有心想用,这些技术理念里面的必要组件在纯.NET技术栈能信手拈来吗? 敢用吗?
网上有个调侃,. net从不加班,从不996,这侧面反映. net没能用于大场面。(手动狗头,轻喷)
所以, 如果.NET还是被定义为api能力,或者大多数时候CRUD用于中小站点,那我内心觉得.NET程序员确实只能值目前的市场价。
(本文标题所说的食物链,还可以解构为:使用这门语言,得到的报酬让我们能吃的食物链)
以上的1,2点都是基于普遍观感,不排除有少量大佬将.NET技术体系用到高精尖项目,并据此获得产品高价值、个人高回报。
😥 那怎么办? 我也是吃.NET这碗饭的。 还是那句话,弱化.NET在你核心技术体系中的地位,降低预期 。 (可能有骂战,我并不贬损.NET体系)
一万年太久,只争朝夕。 我建议大家一开始就使用主流成熟技术 + 主流技能树。
3. 掌握通用的技术架构
微服务的服务独立性客观上为.NET参与高精尖项目提供了可能性, 微服务中各种技术语言可充分参与,取决与你的技术选型、习惯、喜好、
语言在整个体系中是最异变的,不变的是支撑整个业务的架构。
比如说 nginx/负载均衡,又比如说后端三大中间件
- 缓存 redis memorycache
- 消息 rabbitmq kafla
- 搜索 Elasticsearch
不管技术怎么升级, 这些核心的架构点始终存在, 现在有redis memorycache,以后有xxCache也不是没可能,但是这个技术点落地的场景基本不会变动。
🧛 我个人的技术体系是 弱前端+后端(.NET) +sql+ DevOps,我希望具备一个完整的、能落地的web技术栈,当然整个技术栈里面有侧重,这个你从我公众号内容也能感受到。
4. 不要频繁造轮子,也不要图新鲜去使用什么不知名的小技能点
倒腾主流技能, 对新事务保持关注(不要刻意花时间)
举个栗子:
目前主流的Devops框架 Jenkins、Gitlab-CI等, 你倒腾什么中小轮子codeing.net等,(包括现在耳边狂轰乱炸的Blazor,我目前持保守态度!)
不管是职业生涯、还是大厂面试,谁会用,谁会问。
当然如果你已经倒腾并已经点亮这颗并不一定闪耀的技能点了,那沉淀下来的东西还是你的, 也无妨。
时间很宝贵!
5. 多深究 多提问
多深究,多倒腾,每一个你叫的出名的技术栈/技能点,都是经过开发者撸掉上万根头发丝弄出来的,后面也经过市场上的千锤百炼。
他们的技术深度 不是我们写一两个Demo就能参透
- 为什么会产生这个技能点?
- 整个数据流是怎样的?
- 为什么这样设计?
- 这个技能点如果用到其他场景(云、集群)我需要注意什么
- 这一段写法看似是骚操作, 开发者为什么推荐这么做?
很多时候,我们一时也难以参透, 没关系,记下来,
随着时间的流逝,认知和视野会解锁这些问题。
最怕的是遇到问题选择性忽略:
😇 “这是骚操作写法,为什么? 官方这么写,哎呀我也这么写吧,不知道!”
-------------- 下面是技术之外的唠嗑--------------
6. 多关注产品和市场
工作时以主人翁的心态Cover所有与你有所关联的事情,什么意思? 参见美帝长臂管辖权。
把成果推到市场验证,你的产品体验做得好、市场反馈爆棚,资本家受益,自然会给你多分一点口粮。
回过头来,如果在可预期的未来,这个产品不会好过,我好建议你适时执行“沉末成本”“时间成本”的方案, 改变不了公司,那就改变自己。
产品有没有潜力,能不能增长?
- 可对比公司年报增长率; 该产品的贡献率;业内对公司产品的关注度; 竞品的能级(上市公司)。
- 从公司产品的活跃度、留存来感受;从你们团队的实力或者态度来感受;公司年会老板在画饼的时候提到你们团队的次数; 把你们的产品手把手推给认识的素人,看看他们的评价。 (非上市公司)
--- 两者可结合---
🧛 我承认产品和团队是有生命周期的,不可能一直优秀,这就有点像NBA鱼腩球队重建,有的甚至是摆烂重建。
落实到个人,每个人背后的环境不一样、每个人所处的阶级不一样、每个人所处的人生阶段也不一样,最后每个人的诉求也会不一样。
7. 做好向上汇报、平级管理、向下共情
技术人养成了教条式输入输出的思维, Stateless Serverless ,技术人是标准的工具人。
-
向上汇报 不是说要你耍语言艺术,搞花花肠子;
向上汇报是一种职业素养:在上级提出需求的时候,给出几个可行方案和方案的预期、风险点、人工成本;在项目进行中,主动以百分比形式汇报进度和遇到的新的风险点。 -
平级管理也不是说 茶水间家长里短,闲言碎语;
而是说 与同事技术沟通,形成合理的技术预期;给产品经理一个让他难以反驳的拒绝理由;给跨部门同事一个承诺必答的Deadline节点。
你据此在上级、平级同事中形成技术影响力,也是极好的。 做到这些,剩下的你我无法决定。
- 向下共情
每个人的认知都会成长,时间会对齐你们当时的分歧。
不干预 多引导, 多站在对方角度思考。
8. 多记录,多分享
大多数人智力和能力的最高峰都是在高三阶段,相信那时大家每个科目都有一个错题本。
好记性不如烂笔头,鲁迅肯定没有说过。
记录是一个脑力活动,能刻意让我们有层次、有角度、有策略的思考问题。
🧛 经常看到 findi pointer 军哥手记 等意见领袖的公众号文章,你会惊叹于他们视野之广阔、思维之严密、角度之新奇,
大佬之所以是大佬,刻意练习,卖油翁说 唯手熟尔。
说到分享,分享是带有少量私心,目的是在圈内扩大影响力。但是大部分时候,分享是一个加深理解、广开言路的过程,近两年我写公众号加深延伸了自己的技术体系,结识了很多有深度的号主。
说点题外话, 遇到好的文章(阅读时对我有价值的),我通常不吝点赞分享 👍❤️。
大部分技术人性格上都是白嫖党,不要试图考验人性,白嫖就白嫖吧,落得下来是你本事。
我不是什么大佬,以上也算不上什么金玉良言,仅是我多年工作、最近面试的感想, 不接受恶意指责,你杠你对。
本文来自博客园,作者:{有态度的马甲},转载请注明原文链接:https://www.cnblogs.com/JulianHuang/p/14505857.html
欢迎关注我的原创技术、职场公众号, 加好友谈天说地,一起进化![](https://blog-static.cnblogs.com/files/JulianHuang/QR.gif)