- 博客(221)
- 收藏
- 关注
原创 这家公司或损失 1398 亿!AI 赚翻,员工为何要罢工?
这场风波,影响全球。HBM、DRAM、NAND,都占大头。手机、PC、数据中心、AI 服务器,都会受牵连。间接损失,订单流失、信誉受损、供应链震荡。他们的诉求,很清晰。一,各事业部营业利润 15%,分给员工。二,基本工资,上调 7%。行业爆发,利润暴增。品牌、技术、产能,都是王牌。企业赢,员工赢,才是真的赢。别忘了,一线员工的付出。罢工时间表,已经公布。他们要的,不是闹事。是和企业成长,同频共振。三星罢工或损失 1398 亿元,来自界面新闻的报道,是一个真新闻,怎么看这个事。全球芯片老大,三星。
2026-05-08 18:46:02
41
原创 3 分钟,讲透豆包收费背后的真相!
Office、视频会员,多一个人用,成本几乎不变。AI 生意的核心,只看一个指标:用户付的钱 ÷ 烧掉的算力成本。芯片升级、模型优化、缓存技术,都在拼命压成本。68 元、200 元、500 元,三档包月,年费最高五千多。写长文、做 PPT、数据分析、图片视频生成、实时对话。只会聊天、没实用价值的 AI,会慢慢被淘汰。接下来,谁能把重资产,做成高毛利好生意,谁才是 AI 行业的赢家。聊天不值钱,但帮你搞定工作、搞定报告,很值钱。付费版,扛成本、服务重度用户。专业版:给职场人、创作者、学生,搞定工作流。
2026-05-07 17:34:41
316
原创 2025 年,有一家公司 583 名研发人员平均薪酬超 107 万元。
深耕芯片行业几十年,是真正的技术大牛。第二,老板舍得分钱,尊重技术。很多公司,老板吃肉,员工喝汤。这种 “尊重技术、善待人才” 的格局,太少见了。混日子的工作,越来越不值钱。真正值钱的,是你手里不可替代的硬核技术。选对赛道,深耕专业,把自己练成稀缺人才。第一,赛道硬核,门槛极高。芯片研发,不是谁都能干的。能进澜起的,都是行业里的精英。百万年薪,是他们用技术和汗水换来的,配得上。最炸的,不是老板千万年薪。而澜起的研发,直接人均百万。尊重技术,善待研发,不玩虚的。只有这样,国产科技才能真正崛起,越来越强。
2026-05-06 17:06:24
311
原创 马斯克求和被拒!OpenAI 总裁 300 亿身家曝光,硅谷大戏太炸了
求和被拒,马斯克当场放狠话:这周结束前,你和奥特曼,会成为全美国最招人恨的两个人。当然,布罗克曼也不是软柿子,他当庭反击:这些股权是 2019 年给的,那时候 ChatGPT 还没影,OpenAI 能不能成没人知道。现在靠着股权,躺赚近 300 亿。更狠的是,这段威胁短信本来要当证据,法官直接不让陪审团听,背后的门道,你们品品。但庭审真正炸翻全场的,不是威胁,是钱 ——OpenAI 总裁布罗克曼,身家直接被扒出来:接近。现在 OpenAI 估值超 8500 亿,准备两年内上市,布罗克曼的钱,还会继续暴涨。
2026-05-05 18:55:21
259
原创 打脸外界!梁文锋留住 97% 员工,DeepSeek 没凉
另一边却有一家公司,用一组数据狠狠打了 “人才流失” 的传言 ——DeepSeek 研发团队 270 个人,整个 V4 研发周期里只走了 10 个人,离职率不到 4%,换句话说,梁文锋留住了 97% 的核心员工。那些被曝光离开的,确实是亮眼的骨干,但放在整个 270 人的研发大盘里,真的只是极少数。在这个人人求快、人人焦虑的 AI 时代,梁文锋用 “慢” 留住了人心,用 “稳” 守住了团队,用实实在在的股权、清晰的估值、拿得出手的产品,让 97% 的人愿意留下来并肩作战。怎么到最后,走的人连零头都不到?
2026-05-04 19:03:51
458
原创 短剧霸总被 AI 逼回老家种地:时代抛弃你,连招呼都不打
是你愿意放下身段,是你能接受落差,是你不管站在舞台上,还是站在田地里,都能把日子过下去。谁能想到,那个在短剧里西装革履、抬手就甩巴掌、月入好几万的霸道总裁,一夜之间没戏拍,揣着 40 万积蓄,回青海老家种大棚、卖辣椒去了。现在的他,晒得黝黑,裹着军大衣,在大棚里择辣椒,对着路人吆喝:10 元 4 斤。风走的时候,我们落地生根。我们总以为自己的工作很稳,以为自己的技能够硬,以为风口会一直吹,可时代翻篇的速度,比我们想象得快太多。愿我们都能像他一样,高处不骄,低处不慌,无论生活甩过来什么,都能笑着接得住。
2026-04-30 16:47:45
276
原创 庭审首日曝光!马斯克和 OpenAI 的十年恩怨,彻底撕破脸
庭审第一天,三方吵得不可开交,核心就三件事:第一,马斯克的捐款到底有没有附加 “永久非营利” 的条件?庭审现场还有特别有意思的细节:马斯克大谈 AI 末日,说 AI 明年可能就和人类一样聪明,我们要《星际迷航》,不要《终结者》;大家好,今天咱们聊一个炸翻整个科技圈的大瓜 —— 马斯克和奥特曼,曾经并肩搞 AI 的好兄弟,现在直接对簿公堂,闹得人尽皆知。你可能不知道,十年前他俩是一起畅想 AI 未来的伙伴,马斯克当年掏了 3800 万美元,亲手把 OpenAI 做成了。没有我,就没有今天的 OpenAI。
2026-04-29 17:23:15
61
原创 为什么该团队A做的事情,却被其它团队做了
第一种原因,原本方案只需要直接改动系统 service1,但由于团队1并没有解决该问题的动力,其他人不得不绕道去修改系统 service2,service3,service4 来解决该问题。在一个大型电商系统中,有四个团队负责不同的服务:商品团队(负责service1,即商品信息服务),订单团队(负责service2,即订单处理服务),支付团队(负责service3,即支付服务)和物流团队(负责s...
2023-12-17 18:50:34
298
原创 分布式系统的状态就两种:有和没有
什么是有状态服务,什么是无状态服务?无状态服务和有状态服务是分布式系统中两种主要的服务类型,它们在处理请求时有着不同的特性和要求。1、无状态服务(Stateless Service):1)无状态服务在处理请求时不依赖其他请求,每个请求都是独立的。2)处理一个请求所需的全部信息要么包含在请求本身中,要么可以从外部资源(如数据库)中获取。3)服务器本身不存储任何与请求相关的状态信息,因此不需要在请求之...
2023-12-09 10:55:14
430
原创 <span class=“js_title_inner“>分布式系统的状态就两种:有和没有</span>
在这个系统中,用户服务负责管理用户的账户信息和登录状态,库存服务负责管理商品的库存数量,订单服务负责管理用户的订单信息,而支付服务则负责处理用户的支付操作。因此,购物车功能是一个典型的电商领域中有状态服务的例子,需要在分布式系统中采取一些技术和机制来维护状态的一致性和可用性。还有一个思考,我看了无状态服务的定义和自己的理解,那么无状态的服务的请求和幂等操作之间有什么关系?在实际的交易过程中,这些有状态服务需要进行一系列的交互和协调,以确保数据的一致性和交易的准确性。
2023-12-09 10:55:14
624
原创 <span class=“js_title_inner“>分布式系统的状态就两种:有和没有</span>
在这个系统中,用户服务负责管理用户的账户信息和登录状态,库存服务负责管理商品的库存数量,订单服务负责管理用户的订单信息,而支付服务则负责处理用户的支付操作。因此,购物车功能是一个典型的电商领域中有状态服务的例子,需要在分布式系统中采取一些技术和机制来维护状态的一致性和可用性。还有一个思考,我看了无状态服务的定义和自己的理解,那么无状态的服务的请求和幂等操作之间有什么关系?在实际的交易过程中,这些有状态服务需要进行一系列的交互和协调,以确保数据的一致性和交易的准确性。
2023-12-09 10:55:14
609
原创 软件只有两种复杂度:本质复杂度&偶然复杂度
图自网络我们知道软件设计的本质是持续对抗软件本身产生的复杂度。题目中的两种复杂度名称,最早来源自哪里呢?在《人月神话》这本书中,作者将软件复杂度分为本质复杂度(Essential Complexity)和偶然复杂度(Accidental Complexity)。这两种复杂度应该怎么理解呢?我们可以结合下面这段描述来理解这两种复杂度的定义。一个电商软件必然会包含交易、商品等业务复杂度,因此我们称它们...
2023-12-06 22:11:23
1173
原创 <span class=“js_title_inner“>软件只有两种复杂度:本质复杂度&;偶然复杂度</span>
例如,使用统一的接口标准和数据格式来规范与第三方系统的对接,采用中间件或集成平台来简化接口的开发和维护工作,建立健壮的错误处理和容错机制来应对第三方系统的故障等。而同一个电商软件,可以是基于容器技术实现(也可以不是),可以是基于 Java 编写的(也可以不是),因此我们称由于容器技术或者Java 技术而引入的复杂度,为偶然复杂度。例如,在一个电商平台中,如果没有充分评估和选择合适的前端框架和后端技术,可能导致开发过程中的不必要的复杂性。不合理的决策可能导致代码的质量下降和偶然复杂度的增加。
2023-12-06 22:11:23
519
原创 <span class=“js_title_inner“>软件只有两种复杂度:本质复杂度&;偶然复杂度</span>
例如,使用统一的接口标准和数据格式来规范与第三方系统的对接,采用中间件或集成平台来简化接口的开发和维护工作,建立健壮的错误处理和容错机制来应对第三方系统的故障等。而同一个电商软件,可以是基于容器技术实现(也可以不是),可以是基于 Java 编写的(也可以不是),因此我们称由于容器技术或者Java 技术而引入的复杂度,为偶然复杂度。例如,在一个电商平台中,如果没有充分评估和选择合适的前端框架和后端技术,可能导致开发过程中的不必要的复杂性。不合理的决策可能导致代码的质量下降和偶然复杂度的增加。
2023-12-06 22:11:23
555
原创 老板:快下班了,这有个小bug修复完再走
图片动画自网络1、这个小动画曾一度在研发圈里热传。它真实的展现了,现实中研发人员“苦逼”的一面。我们无奈地,苦苦地,一笑之后,思考一下这是为什么。2、大多数程序员以战术编程的心态来进行软件开发,他们的主要重点目标是新功能的上线或者错误的修复。咋一看,这似乎是合理的,还有什么比快速编写有效的代码更重要的呢。这样的开发者,着眼于使功能尽快运行,而不是想拥有一个良好的设计。我们称为:战术龙卷风编程者。...
2023-11-26 17:22:03
282
原创 大厂工作的跨域架构师,最好掌握这4个原则
今天学习的主要内容如下:什么是跨域架构师,在职责上跟单域架构师有什么区别?跨域架构师的勇气重要,还是技术重要?如何面对多领域之间的冲突,又如何解决冲突?我是一名跨域架构师,可以告诉我有哪些基本建议和原则?1、什么是跨域架构师。你看这个图,在领域拆分之前,人、系统、机器都在一个团队,只有一个管理者,这个叫单域,团队里面的架构师叫单域架构师。图自https://time.geekbang.org/co...
2023-11-25 15:50:21
230
原创 大家一起判,这个“锅”应该谁来背
在大厂里面,经常出现一个词,“背锅”。我们今天请大家一起来当判官。在郭东白老师的架构课里面,有一个场景,相信这个场景在团队里面,也具有一定的典型代表性。昨天,线上出现了一个事故,造成了资金损失。涉及到的团队有交易团队、支付团队、资金团队。它们分别对应了三个业务领域,交易业务域,支付业务域,资金业务域。起因是交易模式变更了,比如原来只有代收模式(适用于社群电商及微商,满足快捷收款的诉求,需要平台直接...
2023-11-19 12:23:53
118
原创 <span class=“js_title_inner“>大家一起判,这个“锅”应该谁来背</span>
支付团队也完成了自己的代码改造,只要支付成功,支付模块就会调用资金业务域的接口做资金结算。但是资金团队没有收到交易模式调整的通知,就没有做相应的账户配置变更,还是默认复用代收模式的结算方式,于是结果导致了资金计算错误,造成了企业损失。毕竟项目是交易团队发起的,资金团队沟通不到位,那是交易团队的问题。它们分别对应了三个业务领域,交易业务域,支付业务域,资金业务域。在郭东白老师的架构课里面,有一个场景,相信这个场景在团队里面,也具有一定的典型代表性。在大厂里面,经常出现一个词,“背锅”。僵持不下......
2023-11-19 12:23:53
23
原创 架构分四层,我的系统为什么越来越乱
上一期我们学习了,一个应用架构的四层及职责。但是,随着业务需求的增多,时间的推移,系统架构慢慢的就变乱了。本文视频语音版本:我们这期来分析是什么原因导致的。你说是因为“熵增”,这是肯定的。但熵增只是描述了一个概念。它的表现是什么,根本原因是什么,我们要具象化的来分析。所以,在这之前呢,先让我们先看看变乱后的现象。出现了两类现象。图自https://mp.weixin.qq.com/s/jJzzJI...
2023-11-18 17:31:23
193
原创 <span class=“js_title_inner“>架构分四层,我的系统为什么越来越乱</span>
原本bizA -> serviceA 的实现链路下,随着新增业务逻辑,又新起了一个serviceB,链路演变成了bizA -> serviceA -> serviceB。1、service本身设计的不能扩展,当多种不同类型的业务冲击过来的时候,比如健康、本地生活、门店等多态业务。但是,随着业务需求的增多,时间的推移,系统架构慢慢的就变乱了。起初service本身的划分和定位,都比较随意,不跟着领域设计划分,跟着个人的第一感觉划分。最后一点原因,我个人认为占的比重也是最大的,甚至是主要原因。
2023-11-18 17:31:23
28
原创 一名程序员能从俄罗斯方块游戏中得到什么
如今,俄罗斯方块游戏已经成为了一种文化现象,不仅是一款游戏,更成为了一种文化符号和代表,影响了全球无数的玩家和游戏开发者。在俄罗斯方块游戏的历史长河中,它不仅仅是一款游戏,更是一种经典、一种传承和一种精神。那么我们作为一名程序员可以从这款游戏中得到哪些启发呢。一、俄罗斯方块游戏的历史俄罗斯方块的原版作者是俄罗斯游戏设计师Alexey Pajitnov(阿列克谢·帕吉特诺夫),他在1984年创造了这...
2023-03-26 10:05:38
729
原创 如何对一个老系统进行梳理分析
我们大部分时候面临的都是老系统改造,在老的系统上进行代码的开发,需求的实现。当我们觉得老系统实在“太老”的时候,就想着应该怎么分析老系统,以便支持我们去重构。本文从老系统分析的方向开始,重点介绍技术架构、代码分析以及业务流程分析的方法。一、如何分析一个老系统对一个老系统进行分析,一般可以从下面几个方向入手。1、系统功能分析:首先要对系统的功能进行全面的梳理,理解系统的各个功能点是如何运作的。这可以...
2023-03-25 10:19:12
2944
原创 从原因到解决方案,深入剖析网络错误问题
当计算机系统中的客户端(例如浏览器、应用程序等)尝试连接到远程服务器时,网络连接错误是一种常见的问题。这种错误可能会对用户造成很大的困扰,因为它可能导致无法访问网站或无法使用某些在线应用程序。而网络错误其实是我们日常开发中很难完全避免掉的一个问题,只能降低,而不能杜绝。一、为什么会有网络错误?图自:https://time.geekbang.org/column/article/78585如果有一...
2023-03-19 19:28:29
10248
原创 一周技术学习笔记(第97期)-掌握DDD不是想象的那么容易吗?
1、(来自朋友圈):掌握DDD不是想象的那么容易吗?现在大部分的MVC代码都是面向过程编程的贫血模式,因为他更符合人的思维惯性。14年我们在通过微服务重构CRM系统时,业务的学院派架构师坚持用DDD和充血模型来解决版本1+N定制问题。架构衍生出了对微服务框架很多变态的需求,例如RPC支持多态、支持泛型参数微服务声明和IDL定义等,业界主流的RPC框架都不支持这些特性…总体而言,这个架构师的想法是好...
2023-01-15 20:18:09
647
原创 一周技术学习笔记(第96期)-如何判断一个核心系统受到伤害的程度
1、太用力的人,一般走不远(朋友圈看到)做任何一件事,已开始就拼劲全力,付出全部时间和精力,久而久之,越来越疲惫,没了冲劲和热情一开始有多用力,后来就有多无力。太用力的人,一旦没有得到想要的结果。心态就更容易崩;而轻装上阵的人,回旋的余地更大。真正坚持的幕后的人靠的不是冲劲,而是恰到好处的投入和喜欢。2、架构师的职责-三个确保确保应用系统能够不断演进,而不是采用了固化的设计方案;确保应用系统的技术...
2023-01-08 22:00:04
314
原创 一周技术学习笔记(第95期)-个人成长路上如何找到自己喜欢的事情?
祝大家新年快乐!1、研发做的纯技术工作或者提效类非业务性需求工作如何让业务方感知到?首先,需要互相建立信任。如果业务方提什么需求你都拒绝,也肯定不行。一方面要去接需求,一方面也要有勇气跟对方说我们的想法:为什么某个需求我们觉得不靠谱,为什么当前腾挪不出来研发资源来做新需求。可以主动把人员投入透明出来,让业务方知晓我们把人员都花在哪了。整个过程中,核心关键点是,如何让业务方相信研发人员的专业度。有时...
2023-01-01 17:19:22
463
原创 一周技术学习笔记(第94期)-为什么很多leader都喜欢做闭环
1、如何来评判一个程序员到底对OOP理解的怎么样呢?面向对象编程OOP,可以说是我们最熟悉的编程范式,结合实际的过程我们一般有如下2点理解:1、面向对象编程注重抽象和分层,这是计算机科学解决复杂问题的方案,甚至是人类解决复杂问题的方案。如 SpringMVC,就是典型的一种分层和抽象策略,它让我们设计大型复杂系统成为了可能,可以逐层击破,并且各自优化。2、面向对象编程还天然地契合现实世界的生活,如...
2022-12-25 19:54:42
718
原创 一周技术学习笔记(第93期)-请用代码的优雅取悦你的领导
1、请用代码的优雅取悦你的领导发现身边有很多人,总是喜欢学习和研究分布式架构相关的知识点,却不喜欢读《重构》、《代码整洁之道》这一类能够提高程序员最本质的写代码手艺的书籍。然而,每次CODE REVIEW,总会有一些让人摸不着头脑要讲半天的代码。或许是人人都是架构师的这个环境,让架构的课程戳手可得,确让人忘了自己应该去追求的整洁代码之美。其实,殊不知,一堆可维护的代码就是取悦同事,取悦领导的最佳方...
2022-12-11 18:45:21
230
原创 一周技术学习笔记(第92期)-为什么喜欢讨论技术而不是业务?
1、我们为什么总喜欢讨论技术,而不是业务?作为开发人员,我们平常讨论比较多的是技术层面的东西,比如 Spring 框架、Redis 缓存、MySQL 数据库等等,我们喜欢讨论这些,是因为纯技术的东西比较通用,和业务相关性不大,沟通起来比较方便。但你要知道,一个项目能否成功落地,首先需要的是把业务分析做到位,至于选用什么技术来实现,这是我们第二位才去考虑的因素。从架构角度看,业务架构是源头,然后才是...
2022-12-04 19:07:14
220
原创 一周技术学习笔记(第91期)-产品经理在做什么
这周跟大家分享3个收获,如下:我们设计一个服务往往有两难。第一难,我们事先对服务的边界没有进行很好的划分,结果在落地的过程中,大家反复争论具体功能的归属。第二难,由于对业务的了解不够深入,我们要么设计不足,导致同一个服务有很多版本;要么服务过度设计,实现了一堆永远用不上的功能。服务边界的划分和功能的抽象设计是核心。服务边界确定了这个服务应该“做什么”,抽象设计确定了这个服务应该“怎么做”。产品经理...
2022-11-27 23:36:33
190
原创 一周技术学习笔记(第90期)-分享两个技术边界的问题
第一个。在订单数据表里面会有个最终优惠后的订单金额,那么这个计算优惠金额是应该订单服务来做吗?商品的原价是多少,满减优惠了多少,特价减免了多少,优惠后的计算结果肯定是订单的一部分,也需要保存在订单服务里面。那计算优惠金额应该是订单服务来做吗。这里,我们不难看出涉及有订单服务和促销服务,两个服务。他们都是基础服务,基础服务是最底层的服务。各自提供了自身业务领域内的业务功能,订单服务提供跟订单数据相关...
2022-11-20 21:14:57
163
原创 一周技术学习笔记(第89期)-共享服务放大就是中台
整个架构结构发展的历程,大概是从单体到分布式,到SOA,到微服务,最后或者说是现在的中台。图自《架构实战案例解析》这个历程,以及最终结果的产生,都是因为系统要不断适应业务复杂化。一个业务流程从开始到结束的长度,我们称之为业务的深度。自然也就有它自身的复杂性。比如查看商品详情,自然要将商品信息从数据库里面读取出来,然后需要组装商品的促销信息和价格,以及有无商品标签,比如7天无理由退货等等,最后将全面...
2022-11-13 21:12:29
171
原创 一周技术学习笔记(第88期)-给你一个”编程拐棍“
1、编程,从本质上是一项无法监督的工作。一切度量都无效(尽管还是有各种各样的度量研发效能的实践方法,那也只是一个牵引作用)。我们都经常有这样的经历,耗费了80%的时间着力于项目的个别地方,而花费20%的时间来完成其余80%的工作。编程过程非常耗用脑力,这种特性使得个人性格显得很重要。人们都知道聚精会神地一天工作八小时有多么困难!也许你有过某天精力过份集中,以至于第二天无精打采的体会,或由于上月过份...
2022-11-06 20:40:44
188
原创 一周技术学习笔记(第87期)-代码上坚持是"坚韧不拔",也可以是"顽固不化"
学习需要定期投入知识投资和金融投资的一个主要区别是:所有知识投资都有些价值。即使你从来不会再工作中使用某项技术,它也会影响你思考和解决问题的方式。知识投资和金融投资的一个主要相同点是:需要定期投资。你需要定期投资最低限度的时间量。养成一种习惯,如果需要的话,躲到你的”家庭办公室“里去或者走进有无线网络的咖啡厅。并非每期学习都同样富有成效,但是只要定期安排学习,长期来看一定会有收获。如果你一直再等待...
2022-10-30 18:53:09
237
原创 一周技术学习笔记(第86期)-大促前系统备战可以看看这6个问题
扩容机器时需要注意什么?数据库连接:某服务集群一共有 10 个容器实例,每个实例会建立约 100 个数据库连接,加起来就是约 1000 个连接,假设数据库总共支持的连接数为 1200 个,这是能够支撑现状的。但如果考虑到近期业务增长较快,会导致服务负载较大,需要扩容 5 个实例,那么总的数据库连接数大约会达到 1500 个,这就肯定支撑不住的,所以对服务进行扩容时,对数据库也需要同步扩容。扩容机...
2022-10-23 22:01:01
514
原创 一周技术学习笔记(第85期)-两篇文章13个问题重入OO设计思想
学习了两篇文章,转换成13个问题,我们来模拟一个问答场景,带你一起走进正交的世界。开场关于面向对象,设计原则,你最想跟大家分享什么?那我想应该是,开闭原则?!就这一条原则,影响了开发30多年。以及围绕着开闭原则的“正交设计”。实际上,我们今天写的开闭原则的代码,就是正交设计的很好实践。开闭原则、正交设计、PaaS化,这些是不是都跟面向对象有关?谈到面向对象,我们就会有OOA、OOD、OOP三个方面...
2022-10-16 22:03:49
318
原创 一周技术学习笔记(第84期)-代码评审的六大方向
代码评审的六大方向1、代码逻辑主要看逻辑是否合理,有无多余的逻辑在代码里面,以防给别人和自己买坑,或者将来出现不定时的线上问题,有没有嵌套的过深的逻辑等等。2、代码调用调用是否恰当,有没有重复的调用等等。3、代码规范这个每个公司都会有,也可以参照行业上的标准规范,我个人认为主要是看代码的可读性是否良好,对在面临需求交付时间压力下能做到良好就很不容易了,另外再看看可维护性是否良好,等等。4、依赖管理...
2022-10-07 21:03:34
305
原创 一周技术学习笔记(第83期)-时间和空间到底哪一个更经济
这篇文字讲述时间和空间,但肯定不是去理解牛顿的绝对时空观,也不会去理解爱因斯坦狭义相对论的理论。我们今天说的是,程序世界的两句话“时间换空间,空间换时间”,这两句词语在我们的工作中经常会被提及。那么这中间的【换】我的理解是“被动的牺牲,然后再去争取”,有点置之死地而后生的气魄。比如牺牲时间,多“浪费”一些时间换取空间的延伸;牺牲空间,多“浪费”一些空间节省时间上的消耗。空间换时间空间换时间,比如...
2022-10-02 21:28:59
529
原创 一周技术学习笔记(第83期)-这一条原则竟然影响了现代编程30多年!
我们一般应该怎么衡量代码的质量?容易被阅读,容易被维护,其中在维护代码的过程中,代码的扩展又是非常重要的衡量标准。另外,在我们所熟悉的23种设计模式中,大部分的设计模式都是为了解决代码的扩展性问题而被总结出来的。而所有这些跟扩展性相关的设计模式又都是以一个很重要的原则作为指导原则的:开闭原则。架构分解中有两大难题:其一,需求的交织。不同需求混杂在一起,也就是存在所谓的全局性功能。其二,需求的易变。...
2022-09-25 20:53:47
219
原创 一周技术学习笔记(第82期)-你要的理论、法则、定律、效应都在这里了
72法则:72小时法则:当你决定做一件事的时候,你必须在72小时内完成它,否则,你很可能就永远不会再做了。金融里面还有个”72法则“,如果你投资收益率在12%,你想知道多少年你的钱翻一番呢,那么 72/12=6年。另外还有个“70法则”,比如 如果通胀率为3.5%,应用“70法则”,货币贬值一般的时间约为70/3.5=20年鳄鱼法则:这是经济学交易技术法则之一,也叫“鳄鱼效应”,它的意思是:假定一...
2022-09-18 21:45:57
633
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人
RSS订阅