实话实说:只会.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在你核心技术体系中的地位 。


一万年太久,只争朝夕。我建议大家一开始就使用主流成熟技术 + 主流技能树。


3. 掌握通用的技术架构


微服务的服务独立性客观上为.NET参与高精尖项目提供了可能性, 微服务中各种技术语言可充分参与,取决与你的技术选型、习惯、喜好、


语言在整个体系中是最异变的,不变的是支撑整个业务的通用架构。


比如说 nginx/负载均衡,又比如说后端三大中间件


  • 缓存  redis  memorycache
  • 消息   rabbitmq  kafka
  • 搜索  Elasticsearch


不管技术怎么升级, 这些核心的架构点始终存在, 现在有redis memorycache,以后有xxCache也不是没可能,但是这个技术点落地的场景基本不会变动。


提醒:.NET 程序员不要认为使用 sdk Client 对接了Elasticsearch rabbitmq, 就掌握了这些中间件。


🧛‍ 我个人的技术体系是 弱前端+后端(.NET) +sql+ DevOps,我希望具备一个完整的、能落地的web技术栈,当然整个技术栈里面有侧重,这个你从我公众号内容也能感受到


4. 不要频繁造轮子,也不要图新鲜去使用什么不知名的小技能点


举个栗子:目前主流的Devops框架 Jenkins、Gitlab-CI等, 你倒腾什么中小轮子codeing等,不管是职业生涯、还是大厂面试,谁会用,谁会问。


当然如果你已经倒腾并已经点亮这颗并不一定闪耀的技能点了,那沉淀下来的东西还是你的, 也无妨。


时间很宝贵!


5. 多深究 多提问


多深究,多倒腾,每一个你叫的出名的技术栈/技能点,都是经过开发者撸掉上万根头发丝弄出来的,后面也经过市场上的千锤百炼。


他们的技术深度 不是我们写一两个Demo就能参透


  • 为什么会产生这个技能点?
  • 整个数据流是怎样的?
  • 为什么这样设计?
  • 这个技能点如果用到其他场景(云、集群)我需要注意什么
  • 这一段写法看似是骚操作, 开发者为什么推荐这么做?


很多时候,我们一时也难以参透, 没关系,记下来, 随着时间的流逝,认知和视野会解锁这些问题。


最怕的是遇到问题选择性忽略:


😇  “这是骚操作写法,为什么?官方这么写,哎呀我也这么写吧,不知道!”


-------------- 下面是技术之外的唠嗑--------------


6. 多关注产品和市场


工作时以主人翁的心态Cover所有与你有关的事情,什么意思?参见美帝"长臂管辖权"


把成果推到市场验证,你的产品体验做得好、市场反馈爆棚,资本家受益,自然会给你多分一点口粮。


回过头来,如果在可预期的未来,这个产品不会好过,我建议你适时执行“沉末成本”“时间成本”的方案, 改变不了公司,那就改变自己。


产品有没有潜力,能不能增长?


  • 可对比公司年报增长率;该产品的贡献率;业内对公司产品的关注度;竞品的能级。(上市公司)


  • 从公司产品的活跃度、留存来感受;从你们团队的实力或者态度来感受;公司年会老板在画饼的时候提到你们团队的次数;把你们的产品手把手推给认识的素人,看看他们的评价。  (非上市公司)


    --- 两者可结合---


🧛‍ 我承认产品和团队是有生命周期的,不可能一直优秀,这就有点像NBA鱼腩球队重建,有的甚至是摆烂重建。


落实到个人,每个人背后的环境不一样、每个人所处的阶级不一样、每个人所处的人生阶段也不一样,最后每个人的诉求也会不一样。


7.  做好向上汇报、平级管理、向下共情


技术人养成了教条式输入输出的思维,  Stateless  Serverless ,技术人是标准的工具人。


  • 向上汇报 不是说要你耍语言艺术,搞花花肠子;
    向上汇报是一种职业素养:在上级提出需求的时候,给出几个可行方案和方案的预期、风险点、人工成本;在项目进行中,主动以百分比形式汇报进度和遇到的新的风险点。


  • 平级管理 也不是说 茶水间家长里短,闲言碎语;
    而是说 与同事技术沟通,形成合理的技术预期;给产品经理一个让他难以反驳的拒绝理由;给跨部门同事一个承诺必答的Deadline节点。


你据此在上级、平级同事中形成技术影响力,也是极好的。做到这些,剩下的你我无法决定。


  • 向下共情
    每个人的认知都会成长,时间会对齐你们当时的分歧。不干预  多引导, 多站在对方角度思考。


8. 多记录,多分享


大多数人智力和能力的最高峰都是在高三阶段,相信那时大家每个科目都有一个错题本。

好记性不如烂笔头,鲁迅肯定没有说过。


记录是一个脑力活动,能刻意让我们有层次、有角度、有策略的思考问题。


🧛‍ 经常阅读 findyi洋哥  pointers袁吴范  军哥手记 等意见领袖的公众号文章,你会惊叹于他们视野之广阔、思维之严密、角度之新奇,


大佬之所以是大佬,刻意练习,卖油翁说 唯手熟尔


以上算不上什么金玉良言,仅是我多年工作、最近面试的感想, 不接受恶意指责,你杠你对。

相关文章
|
网络安全 KVM 网络虚拟化
变形金刚外传0x03:进一步讨论NSX-T的传输节点就绪
话接上篇,对于NSX-T来说,由于传输节点配置文件将传输区域与主机交换机进行了严格意义上的绑定,因此不会出现在NSX-V场景中传输区域与分布式交换机覆盖不一致的情况。
透过现象看创本质的能力-从忒休斯之船到系统论
透过现象看创本质的能力-从忒休斯之船到系统论
|
安全 IDE 区块链
BTC比特链/ETH以太链/BSC币安链/TRX波场链/Matic马蹄链智能合约系统开发稳定版丨指南步骤丨源码详情
Developing a smart contract system is actually the process of writing and executing code on a specific blockchain (such as Bitcoin, Ethereum, Binance Smart Chain, Tron, or Polygon (Matic)). These codes (conventions) have the ability to automatically execute and facilitate transactions without interm
|
7月前
|
监控
两阶段终止模式和Balking模式
两阶段终止模式和Balking模式
58 1
|
安全 区块链
TRX链/BSC链/ARB链/Matic马蹄链公链智能合约系统开发指南需求丨步骤逻辑丨规则方案丨案例开发丨项目程序丨源码说明
Chain selection and environment construction: Select suitable public chains as development environments, such as TRX chains, BSC chains, ARB chains, or Matic horseshoe chains. Establish a corresponding development environment, including node deployment, development tools, and testing network.
|
存储 Kubernetes 负载均衡
【k8s 系列】k8s 学习二十六,有状态的应用如何部署 1?
前面我们分享很多关于 K8S 的内容,有没有发现 pod 都是无状态,RS / RC 管理的 pod 也是无状态的,我们可以任意删除一个 pod,副本管理器又会马上给我们创建一个 pod 那么如果咱们的这个 pod 是有挂载持久卷的,那么我们用老方法可还行?
196 0
|
网络协议 程序员 数据处理
ZMQ之自杀的蜗牛模式和黑箱模式
ZMQ之自杀的蜗牛模式和黑箱模式
ZMQ之自杀的蜗牛模式和黑箱模式
|
设计模式 消息中间件 JavaScript
代码越写越乱?那是因为你没用责任链
代码越写越乱?那是因为你没用责任链
代码越写越乱?那是因为你没用责任链
|
负载均衡 算法 区块链
对百度超级链Xuper使用过程中的进一步理解
对百度超级链Xuper使用过程中的进一步理解
377 0
对百度超级链Xuper使用过程中的进一步理解
|
设计模式 算法 架构师
如何优化你的if-else?来试试“责任树模式”
写业务逻辑时,if-else 可能是最容易想到的逻辑方式了。然而大量堆砌的 if-else 毫无疑问将给代码维护带来巨大的困难。如何优化这些 if-else 呢?本文分享一种设计模式——责任树模式,通过将责任链与策略模式融合,成为一种广义的责任链模式,不仅可以完成任务的逐级委托,也可以在任一级选择不同的下游策略进行处理,并将责任树模式抽象出一个通用的框架。
如何优化你的if-else?来试试“责任树模式”