时光
按年份归档
根据文章发布日期整理。
2026
大家好,我是Z哥。 你有没有见过这种场景? 一个后台 Job,因为运行时间长、资源消耗大,被提议单独拆一个服务。 一个商品详情页,因为要聚合商品、库存、营销、评价,也被提议单独建一个聚合服务。 App、H5、PC 三端字段不一样,于是有人说,那就每端一个 BFF。 再加上 CI 慢、部署慢、扩缩容策略不同、MQ Con
大家好,我是Z哥。 最近很多团队都在聊 AI 落地,我也分享下我实践下来的一些感受和观点,供大家参考和讨论,欢迎大家在评论区一起交流下经验和心得。 与身边的朋友交流 AI 落地话题的时候,我发现一个很常见的问题是:大家容易把 AI 落地理解成「给团队配工具」。 比如给大家开通一个 AI 编程工具,做几场分享,沉淀一些
2024
我们总是在感叹“时间不够啊”、“来不及了”、“我太忙了”。 作为一位程序员,我们可以以代码视角来理解我们与时间的关系。
当流量瞬时激增时,API会出现大量 HttpCode 为 503 的错误。与此同时,发现另一个错误 `responses.go:69 write response failed, error: context canceled` 与该错误具有很强的相关性。
2023
熔断是一种通用能力,可以在服务端做也可以在客户端做。我们的项目中大多数都基于 go-zero 框架实现,而使用 go-zero 框架实现的项目自带服务端熔断能力,所以本文的目的是阐述如何在客户端侧实现熔断机制。
最近在想一个问题,为什么大多数软件开发的工作都深陷在“吃力不讨好”的困境中。为什么这么说呢?因为我看到很多程序员小伙伴工作很辛苦,但是往往最终获得的结果或者说外部评价并不好。
前几周和团队里的「DDD」爱好者交流的时候,有人提到了一个概念叫「DCI」。我当时就想我只知道「DI」和「CI」,「DCI」又是什么鬼。
2022
作为一个团队的Leader,对于团队的建设自然也离不开以上这些,但是不管你做什么其实都是围绕“人”在展开。因此我认为要做好团队建设,主要是做好以下四件事
在编码实现一个功能时,发现有一个逻辑如果按照全面去考虑的话需要改动很多地方,甚至可能要推翻当前已经写过的部分代码,但是呢现在实际场景并没那么多,当前的实现已经能满足。算了,先这样吧,后续业务怎么发展还不知道呢,到时候再说。
《数学之美》这本书买来在书架上放了很长时间了,一直没看。虽然在很多地方看到有人推荐它,但是我认为这本书毕竟还是属于工具类的,对于我之前来说用处不大,所以没有动力马上看。
很多人觉得 DDD 很难落地的一个原因在于,团队中的所有人是否能够对核心概念形成共识。
做技术的都知道,程序之间的通讯,常用的方式有两种,RPC 和 HTTP。普遍的共识是系统内部的各个子系统之间的通讯用 RPC,与外部系统之间的通讯用 HTTP。
最近系统在压测过程中发现有一个程序在压力增大后会内存溢出。正好之前自己对 Golang 里分析 dump 这块还没怎么涉及,借此契机学习一下。
最近虽然忙,但是Z哥也不忘关注一下行业的情况。一直在做投资的小伙伴应该知道,最近一段时间中概互联相关的股票跌得超级惨,好多公司跌了 70 %~80 %。
最近工作中正好在设计一个方案,以支持 CD 环节的第一个部署节点可以完全自动部署,并且整个环节中尽量减少人为干预的节点。
最近正好在工作中遇到一个问题,需要对 Golang 中的 goroutine 和 panic & recover 稍做深入的了解,算是忙里偷闲学习一下。
这一年对我来说是一个巨变,这些巨变主要发生在三个方面:工作、思维、投资理财。这些变化给我带来了新的生机、新的希望,让我对未来有了更好的憧憬。下面我与你分享一下我的这些变化,希望也能给你带来一些启发。
最近在项目中遇到了一个使用 RabbitMQ 时的问题,这个问题我觉得还是有一定普适性的,和大家分享一下,避免大家后续在同一个问题上犯错。
如果每个子系统都能够内置一个mock工具(模块),通过数据的自动生成,导入和导出,可以灵活地在不同环境上快速地让系统run起来,哪怕自己还没有真正地完成内部的业务逻辑代码编写。
最近正在做新老系统切换的准备工作,对于新老系统的切换方案,正好最近有做一些了解和思考,在这里和大家分享一下,可能你以后也会用得到。
这段时间在新团队用golang做开发,摸滚打爬完成了项目的搭建、并完成了4个用户故事的开发,对于golang的使用算是勉强达到了较为熟练的状态。 简单聊聊感受吧。目前感受到golang的几个明显优点:
一直关注我的小伙伴应该知道,Z哥在国庆前换了一份工作。去到一个目前处于初创期的公司。工作强度是真的大……,我那老旧的发动机刚开始还有点不适应……
2021
你是不是有时候遇到一些问题,脑子会很蒙,没有任何头绪?但是觉得身边的那些高手们好像永远没有问题可以难倒他们,总是能由浅入深地触达问题的本质,逻辑清晰,思路开阔。很羡慕能有这样的能力?
研发考核难是整个软件开发领域众所周知的问题,甚至可以说是跨世纪的难题了(上个世纪开始至今未被有效解决)。 近期我对这个问题有了一些新的思考,在这里和大家分享交流一下。
不知道你是否还记得去年微软有两个政策的推出,让我们国内被 996 困扰的互联网人很是羡慕。 一个是在日本推行一周工作 4 天。另一个是提出允许员工每周不超过 50 %的工作时间在家工作,甚至是经过管理层的批准之后可以选择永久在家里进行办公。
在软件开发领域一直流传着一句话,它说明了程序员的水平和资历之间并不存在着相关性,并且可能相差特别大。 到底是货真价实的十年经验?还是一年经验重复用了十年?
你卷,我卷,大家一起卷。
因为搜索引擎搜的是信息,有信息的地方便意味着有信息差,而信息差就你是能不能挣大钱的关键。当你知道别人所不知道的,你就能比别人做更多事来利用这些信息为你创造价值。
所谓“跳槽爽,一直跳槽一直爽”。但是,世上哪有那么好的事哦,跳槽虽然可以带来更快的涨薪机会,但是你也是要面对和克服一些新挑战的,其中最大的挑战莫过于要熟悉一个陌生的项目。
如果有较好的数据分析能力,不管是对你的生活还是工作,都将带来巨大的帮助。因为你比别人拥有更好的“洞察力”,看到别人看不到的信息,这些信息可以帮助你更好地做出决策。
最近几年 DDD 一直很火,网上的课程也有很多。但是说实话,DDD 里面的大多数概念还是很晦涩的,没有那种特别清晰规则,可以像代码规范那样明确指导我们如何 coding,什么是好代码,什么是坏代码。
你最近正处于自我否定的状态吗?如果不是的话,回想一下最近的一次处于这种状态是什么时候?当时的感受如何?以及,最终是如何走出这个状态的?
最近正好在学习 Golang,对它的里面用到的三色标记法的 GC 机制有些好奇(
不知道你是不是经常在和别人聊天的时候,发现对方讲的东西自己都略懂一些,但是要让自己说出来,甚至主导聊天的方向却很难。
不管是十几年前 SOA 的流行,还是 7、8 年前微服务的大行其道,还是如今云原生的展露锋芒,背后都离不开一件事,程序拆分或者说服务拆分。否则,一个单体应用,以上的这些技术潮流好像都与它没什么关系,只是一个看客。
这里的第一篇文章发布于 2017 年 6 月 20 日,至今有 4 年多了。当时之所以开设这个公众号,原因有两个。
很多人吐槽老项目是怎么怎么垃圾。这的确是一个很大的问题。
Sam Thomas Davies曾经精辟地概括过「自律」。他认为自律就是学会抵抗。不管你感觉如何,都要采取行动,有计划地生活。
不知道在看这篇文章的程序员伙计们平时是如何写代码的?有参照什么原则吗?还是说写到哪算哪?
我觉得这篇文章特别适合你收藏一下,为什么呢。首先,当你再次遇到这种情况的时候,翻开这篇文章,可以帮助你降降火,让你冷静下来。其次,还能时不时地在朋友圈转发给你的“稍懂技术”的同事看看,给他一些暗示,哈哈。
懂了不一定能说出来,说得出来,不一定能写出来。这也是“费曼教学法”所提倡的,以教促学的思路。
程序员群体中有个很好玩的现象。 工作年限短的程序员热衷于设计“高大上”的技术方案,而工作年限长的则对技术方案好像不太感冒,上手就撸代码。
在这个越来越内卷的时代,我想你可能时不时,甚至经常会觉得压力好大啊,那些来自生活的压力、工作的作压力、社交的压力、……
我相信每位程序员都有过这样一个困惑:“如果我在一家公司蒙头钻进业务里去,扎得很深,是不是就相当于把自己困死在这条船上了?”因为业务了解得再多,跳槽换一家公司后就毫无价值了,需要重新与业务方扯皮。
最近正好在编写一套新的面试题,其中有一道是与高并发相关的。出题的目的是想了解一下候选人面对大流量场景下的优化思路。在出这道题的过程中,我自己也梳理了一下自己对这个问题的思路。
之前很少分享我自己的成长经历,今天恰好心血来潮来分享一下,也正好能让最近刚关注我的新朋友更快地了解我。
有时候,我们被动的需要去了解一个新行业或者领域。比如,工作需要、投资需要等等。 在这个时候,你能不能快速弄懂一个行业的80%,成为一个内行就很关键了。毕竟时机可是很重要的。
很多在一线做coding工作多年的程序员朋友好像对「架构」有着一股特殊的情感。 一方面是自己长期在一线的各种项目中coding,好像除了业务代码以外,「架构」就是体现在项目中用到的一些框架。而且每个项目里用到的框架好像还都差不多,都是spring、redis什么的。觉得做架构并不是什么难事。
从这些经历和观察中,我总结了一些经验,我想它们对你提高开发效率或多或少会有些帮助,下面我来分享给你。当然,也欢迎你在留言区分享你觉得好用的方法。 我想,没有人不愿意成为10倍程序员吧?肯定都希望自己变得更牛逼,是吧?
具体谈加薪的时候有三个核心要点。找对要点,找对人,找对时间。
在Debug方面,水平高的人可能在效率上能领先至少一个数量级。
我相信每个人都会在意别人的看法,只是程度不同。但是如果你觉得它已经严重影响了你的正常处事判断,那么不妨来看看我这篇文章。
我相信每一位程序员最怕遇到代码质量堪忧的项目,毕竟增加一个同样的功能,在一个代码整洁、清晰的项目里与在一个代码混乱不堪的项目里,效率和质量上的差距达到一个数量级一点也不奇怪。
每年年初立的flag都完成了吗?没有完成不要紧,因为大部分人都没完成。 我还记得与Z哥年龄相仿的这辈人,在微信朋友圈刚出来的那会非常流行在朋友圈立flag,当然其中也包括我自己。 但是现在还在继续立flag的人越来越少了。我估计是因为脸被打疼了,都不好意思立flag了。
而且有些巨型源码库,如果你不掌握一些高效的方式,那你阅读起来会让你绝望。就像往大海里投个石子,虽能掀起一丝涟漪,但海面很快就归于平静。
每次过完年,不少人会多增加一份焦虑,这份焦虑表面上看是“不想上班”,但实际上可能是职业规划的缺失导致。因为缺少对未来的预期、憧憬,导致对自己的工作没有热情。
我们程序员虽然每天都和代码打交道,但是大多数时候都是在「写」而不是「阅读」。
不知道你有没有定期整理衣柜的习惯。你有没有发现,当你不去花时间整理衣柜的话,慢慢地,你的衣柜会越来越乱,找衣服的难度越来越大。然后你痛定思痛,打算抽个周末好好整理一番,但是过了半年或者几个月,找不到衣服的情况又开始发生。
大部分的互联网公司都有产品经理这个岗位。据我的观察,这个岗位其实有一个临界点。如果没达到这个临界点(60、70分的及格线),产品经理不但起不到应有的作用,甚至可能起反作用。
其实我们每个人的工作本身就是为了解决问题,老板通过经营企业解决社会问题,管理者解决组织问题,员工解决现实中的具体问题。 因此,一个人的解决问题能力高低在职场中非常重要,甚至可以说决定了你收入的高低。
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「175」篇原创敬上 & […]
这一年过得太快了,虽然坎坷,还得总结一下。
2020
在大家都认为越来越内卷的当下,注重和提升代码质量我认为是每个程序员的必修课。说的严重一些,它影响了你在团队中的价值,说的表面一些,它是你在团队中的“面子”。
在职场上,我们大部分人的能力都是差不多的,都处于中等水平,符合正态分布。但是如果你仔细观察的话,你会发现能力差不多的两个人,对于同一件任务的完成时间也会大不一样,甚至有很大的区别。
突然发现叫我们程序员“码农”还挺形象的,因为写代码和种田很像,想有个好收成,就要好好管理代码,让它们井井有条。
那些说服能力强的人工作总是顺风顺水、左右逢源,而如果你的说服能力不强的话,会觉得自己的工作不但处处遇阻,而且在生活中也总是会不如意。
我想,做「架构」是每个热爱技术的技术人在不断追求想进入的领域。但是很多人可能工作了很多年也没能真正参与到做架构这件事上。
如果你也想写点东西,但迟迟未开始,也不妨看看我的这些经验心得。
所以,很多人没有把单元测试当作一个“工具”,而把它看作是一种“负担”。 在这种心态下,就算要写单元测试,也是为了写而写。更可怕的是,通过mock工具,还真能给任意代码写单元测试。
有一种类型的故事大多数人都喜欢,就是“屌丝逆袭”的故事,这也是很多小说的题材。 不管是在小说还是现实中,这样的逆袭都不是一蹴而就的。并且,大多数人一直只在逆袭的路上,最终能成功完成逆袭的总是少数。
相信每一位真正的程序员心里都有这样一个念想:只要我的技术够牛,就能驱动业务的发展。但是往往我们在不自觉间做的是背道而驰的事情。
每个人也都知道留下好的第一印象很重要,但我估计很多人对这件事的解决方式,也就在网上找个自我介绍的模版就完事了。
应该有不少程序员受过这样的困扰,特别是做后端的。项目一直在持续不断的迭代,但是呢老版本的代码还不能直接删掉,因为不一定所有的调用端都能在同一时间点完成升级。你是怎么处理这种情况的呢?
今天我们来讨论一个日常工作中很常见的现象:面对质疑,我们的第一反应是不承认,甚至是辩解。
NCDP的全称是:No-code development platform。无代码开发平台。 乍一听这个名字挺厉害的,甚至不少人提出的问题是:以后是不是程序员要失业了?
职场就是战场,你有多大价值才能获得多大利益。
相信大家和我一样,对于那些拥有过目不忘的超强记忆力的人羡慕不已。因为自己总是在关键时刻想不起重要的信息。 可以说,我们这一生的人生道路会怎么走,记忆力也起到了至关重要的作用。
不知道大家有没有发现。如今,曝光某些知名公司信息泄露的事件频率越来越高。与之对应的,网络安全问题也越来越受到重视。
不知道你有没有过这样的困惑,想学习某项新技能,但是很容失败。比如,出于职业发展的考虑,想学习一门新的编程语言,或者想了解一个新的技术框架;又或者看了某些综艺节目后想玩一玩滑板、练一下街舞等等。
从产品视角是怎么看程序员的呢?我根据我自己的经历以及与其他产品经理的交流下来看,吐槽的主要是以下几点
如果你是程序员可以看看以下这些描述是你眼中的产品经理么?如果你是产品经理可以看看从程序员起家的Z哥给出的一些建议。
萧伯纳说过,世界上只有两种物质,高效率和低效率;世界上只有两种人,高效率的人和低效率的人。
一提到架构,对于工作经验不多的小伙伴来说会心生敬畏之心。觉得是一个很高端、很难、很有挑战的事情。 没错,架构不像我们平时的coding工作,这是一个宏观层面的事情。而对我们内心来说,越宏观、越大的东西,我们总会觉得更不容易控制,所以会心生敬畏。但实际上,架构的“世界”在复杂度上可能还不如coding上的细枝末节那么大。
复杂的职业规划大多不靠谱。职业规划其实很简单,就2个问题。
线上故障不要慌,按照这个思路来。
相信你也有过这个疑问。
你写的系统错误提示形同虚设?试试这4个方法。
你参加过多少又臭又长的会议?来一起摆脱他们吧。
近期这类信息被报道的频繁度进一步增加。这不,最近陆续又有一些国外公司宣布退出微服务架构的迭代路线,逐渐将一些小粒度的服务进行合并成一个更大粒度的服务,甚至还发明了一个新的名词——「宏服务(macroservices)」。其中不乏像Uber这样的体量的大公司。
造火箭级别的面试,不适合大多数企业。
「做事容易半途而废,缺乏毅力」,我想100个人里面有99个是这样。
想在黑盒测试的范围内如果要做得优秀,我觉得有两个方向可以走,「业务」和「体验」。而且基于这两个方向你可以平滑地延展自己的职业发展道路
啥都能不行,表达能力不能不行。
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「142」篇原创敬上 大 […]
当今的社会文化越来越「快餐化」,在各种爽的、刺激的、娱乐至死导向的信息熏陶下,间接地把我们每个人身上的一股“坚持劲”给磨没了。喝惯了可乐,再回去喝白开水就会索然无味。
相信大家也感受到了,随着互联网加速了信息的流动速度,知识的更新迭代也在加速。可能原本靠着一门手艺可以过一辈子,现在可能每5~10年就需要一次大的迭代才能跟上社会的发展步伐,不被out。
我们大多数人的职业最终都会进入「内卷化」的状态。
最近有很多发生大逆转的事情,让我感触颇深。 新加坡从佛系抗议到开始实施安全社交距离措施;最快ipo中概股瑞幸咖啡跌落神坛;投资大神孙正义125亿美元巨亏;孙杨的兴奋剂事件等等。
之前写了一篇应应聘者视角的「面试中要注意的点」,《聊聊面试的事(应聘方)》。这次再来一篇面试官视角的。
我们中国有句古话,分久必合,合久必分。 很多事物的发展都逃不开这个规律。如今,这件事也正在分布式、微服务概念大行其道的软件开发领域里发生。
相信大多数人也都已经复工了。之前进行远程公办的,大多也都回到了原先在公司集中办公的常态。 最近在和一些读者伙伴、身边的朋友交流的时候,发现很多人觉得说,复工后在公司工作的感觉和春节前有很大的区别。特别是现在明显地感受到公司的氛围变得更加的紧张了。
想要抓住宝贵的面试机会,争取拿到更多的offer,那么在面试这个环节就不能掉链子,必须得认真对待。 作为担任了7年的面试官,我来分享一些我以面试官为视角所看到的应聘者踩进去的那些坑,以及分享一些可以加分的点。希望能帮助打算换工作的你,更快地找到新的工作。
这周微信公布了一个我期待已久的好消息。周一的时候对外公布说,已经完成了iOS版本的Dark模式开发,可能会在下一个版本上线。
伴随着复工潮的开启,最近也有不少小伙伴要准备找新工作了。不知道你是其中的一员吗? 如果不是也没关系,可以收藏此文,后续可能会用得上。
今,大环境遇冷,红利逐渐消失,未来想要赚更多的钱,你得重新找到一个让你能变得更值钱的途径。否则,你未来的薪资不升反降也不是没有可能。
这次的疫情对我们所有人影响都很大,除了让你心怀忐忑的过了个春节之外,呆在家的时间对很多人来说也是格外的长。 这样的突发事件,除了能看出不同公司之间应对突发状况的能力差异之外,不同人之间的差异也会清晰地凸显出来。
相信我们每个人在平时的学习和生活中,都可能有过这样的经历,心里想要做某件事,但过了好久发现还在原地踏步;或者觉得有力气使不出来,不知道从何下手。这样的情况在越枯燥、越困难的事情上会表现的更加明显,比如「学习」。
这次的春节情况特殊,疫情席卷了几乎整个中国。网络上关于疫情的官方消息、小道消息是层出不穷。 然而这些消息带给我们大多数人的可能只有情感上的感受,恐惧、惋惜,或是同情。真正去思考这些信息背后真实性的人估计少之又少。
一年一年真是快。之前在1月1日的时候有过一波年终总结的热潮,由于恰好我当时身边事情比较多,没能抽出时间来进行回顾和复盘。索性放到这次农历新年来写写,顺带发个红包,大家乐呵乐呵。
职场上最重要两个能力,一个是情商,一个就是逻辑能力了。前者做人,后者做事,缺一不可。
我们程序员应该算是相对比较有毅力的一个群体了,毕竟入行的高门槛首先就刷掉了一批无法坚持到胜任coding工作的人。况且,新技术的更迭相比其它行业快的多,需要持续学习。即使这样,肯定每个程序员都还有过做一件事半途而废的经历。并且,不是由于不可行而停止,而是你自己主动放弃。
在一个大系统中,数据就像水,整个系统就像是一个漏斗,漏斗的每一层代表每个子程序。上层的子程序对性能的损耗越低,能流下去的水就越多,直到最后一层「数据库」处,也可以理解为是存储。
愿你在这个充满机遇的时代,每天都能精力充沛,成就真正的「超级个体」。
2019
不知道你有没有过这样的感觉,那些比你更厉害的人,在一件事中往往可以轻易地从一个「点」延展出一条「线」,甚至一个「面」的知识点。对我们真实感受的冲击是,在大局观上被碾压,相比之下觉得自己总是考虑不周,甚至考虑的东西完全是错的。
上周的《解决问题的能力 > 10倍程序员》发出后,有人给读者给我留言说,让我写一写「如何评估一个人解决问题的能力」。那么就趁热打铁继续把这个话题给写了。
我们的工作中,每天会遇到大大小小的很多问题。其中有些是之前从未遇到过的问题,这对很多人来说就会很棘手,不知道该怎么解决,可能吭呲吭呲折腾好几天都不一定能搞定。
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「117」 […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「118」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「119」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「115」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「114」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「113」 […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「112」 […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「111」 […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「110」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「109」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 当然了,也会时不时加个餐~ 我的第「108」篇原创敬上 & […]
这里是Z哥的个人公众号 每周五11:45 按时送达 有时也会有感而发,来加个餐~ 我的第「107 […]
因为最近工作比较忙,没太多时间思考和写东西。所以今天偷个懒,发一篇实操类文章。 这 […]
Hi,大家好,我是Z哥。 熟悉我的小伙伴应该知道,我平时看书大多都很快,之前还把自己的速读技巧分享给了大家。( […]
俗话说的好,不以规矩,不成方圆。 但是有些时候,可能破坏规则反而是一个更有效的方式,这个时候到底 […]
随着20年来互联网的蓬勃发展,一个软件系统所要面对的访问压力上限被逐渐提高。 虽然如此,但是那些 […]
前天早上,在36kr看到一篇文章《一个负能量的人,可以轻易搞垮周围人的生活》,讲述了可能我们每个人身边都存在的 […]
之前618活动的时候买了不少书,最近一段时间集中看了四本管理相关的书籍,收获颇丰。在这里分享给大家。 &nbs […]
这周末有个超超超大型的“夕阳红团建”活动你知道不?不知道你有没有参加,反正我是参加了。我来和你说说我的感受。 […]
大家好,我是Z哥。 对,就是脑袋很大的那个。大到什么程度呢?我给新来的小伙伴们说说。 我昨天还打算配副 […]
我们大部分做技术的,对新技术是又爱又恨。 爱的是他能让枯燥反复的工作重新获得新鲜感。 恨的是新技术太多了,学不 […]
最近有点忙,搬出之前攒的一篇文章来应急一下。 一篇能助你挣更多钱的文章。好了,下面开始。 我的读者 […]
今天来纠正一个错误。先和大家说一声抱歉:D 昨晚睡觉前,惯例打开「订阅号助手」回复一些留言。有一 […]
在一个分布式系统的开发团队中,有一些问题是很容易产生程序员之间矛盾的。 其中之一就是「业务归属」 […]
hi,大家好。三周过去了,上次教你的几个「速读」技巧练习的怎么样了? 上周,已经有不少小伙们开始催我发这篇了。 […]
是的,这份礼物最佳受众是程序员。但是,如果你不是程序员,相信这些能使你更懂程序员,能更好的与他们交流。 有些小 […]
今天端午节,估计这篇文章送达的时候你还在睡觉:D,Z哥先祝你度过个愉快的小假期。 这篇是「分布式系统理论」 […]
最近和团队里的小伙伴1对1聊的时候又聊到了关于怎么读书学习的问题,这已经不是第一个人问我了,所以我直接先问他现 […]
这篇是「分布式系统理论」系列的第20篇。提前预告一下,后面还有一篇文章,这个系列就结束了。 在之 […]
这周工作比较忙,又恰巧这周末出去旅游要准备一下,今天就唠唠嗑吧。聊一件和我们每个人都有关的事。 […]
前面一篇文章中,Z哥和你聊了「异步」的意义,以及如何运用它。错过这篇文章的可以先去看一下再来(分布式系统关注点 […]
为了连载「分布式系统理论」系列,产品和运营题材的内容好久没写了。 这篇文章其实写好有一段时间了, […]
放假第二天,不知道你在哪里堵着呢。 今天就闲聊一下,发一篇简短的快餐文。不知道我的读者里有多少是 […]
Z哥在前面的三篇文章里和你一起聊了「高性能」主题下与「缓存」相关的内容。这次和你来聊聊提高性能的另一个大招—— […]
2月底的时候Z哥写过一篇《在“寒冬”下的金三银四求职,Z哥给你几点建议》帮你分析了在当下时期该如何考虑跳槽这件 […]
今天是周末,和大家聊聊天,难得一篇短文。 996的火烧的挺久了,昨天马云好像又来给这把火加了一波 […]
有句话说得好,欲要使其毁灭,先要使其疯狂。当你沉浸在缓存所带来的系统tps飙升的喜悦中时,使你系统毁灭的种子也 […]
今天小长假,我们就不搞太正经的了,就聊聊天吧。 最近程序员圈子炸锅了,诞生了史上star数增长最 […]
本想一篇写完 后来发现篇幅太长 怕大家看不下去,故做拆分 望对你有所帮助:) 在前 […]
这里的粉丝大多数可能还是做技术的,哪怕不是做技术的,只要在互联网行业的话可能平时也会或多或少和技术人员打交道。 […]
此前的「伸缩性」章节结束了,此文是「高性能」章节的第一篇。 只要是位正儿八经的程序员自然知道「缓 […]
今天恰巧是38节,昨天是女生节,不管怎样这两天都是妹子们的节日,Z哥先给这里10%的妹子们说句“节日快乐,祝你 […]
没想到这篇文章写了这么长,一时半会没消化完的话,可以收藏一下先。 这是「伸缩性」章 […]
这是一篇以程序员视角写的文章,但是内容是互联网行业通用的。 文章虽然有点长,但是这里的读者大部分 […]
如果我们的开发工作真的就如搭积木一般就好了,轮廓分明,个个分开,坏了哪块积木换掉哪块就好了。 但 […]
今天初四拉,大家这年过的怎么样呢?是不是和Z哥一样,肚子上的肉又多了一层 最近几天 […]
这是春节前最后一发拉,z哥先提前祝大家春节快乐~ 回家路途漫漫,不妨好好读一下本文。 前阵子,在互联网圈有 […]
下面的这个场景你可能会觉得很熟悉(Z哥我又要出演了): Z哥:@All 兄弟姐妹们,这次我这边有 […]
先来聊一下这个问题的背景吧。 前两天有小伙伴问到Z哥这个问题。 其实坦白说,我刚做 […]
前面聊完的2个章节「数据一致性」和「高可用」其实本质是一个通过提升复杂度让整体更完善的方式。 接下去我们开始聊 […]
这篇文章源自前天的一次部门内问答。基于此做了更多的发散。 前天晚上,公司有一位小伙伴问到一个问题 […]
来来来,z哥今天发文加个餐~ 掏心掏肺一下~ 此时此刻大家可能在外面聚餐,happy?Z哥也是, […]
18年即将进入尾声,现在让你回想一下过去这一年你从外界接收了哪些重要的信息?更进一步,这些信息中哪些有让你变得 […]
首先声明一下,这篇文章不是“消费”ofo的,因为ofo已经被各路大咖360度全方位“消费”过了,z哥我就不炒冷 […]
也许你对降级已经有了一些认识,认真看完,我想这篇文章可能会给你带来一些新的收获~ […]
来,这次我们带着一个问题来看全文: 当你和别人在竞赛(如,体育、打竞技游戏)的时候,如果输了心里会不甘心、不舒 […]
迟到3天的文章来了~ 可能你在网上看过不少「限流」相关的文章,但是z哥的这篇可能是最全面,最深入浅出的一篇 […]
这篇文字稍多,不过是篇白话文,好读。 《第一财经周刊》携手优衣库发布《2018年中国Z世代理想生 […]
当我们工作所在的系统处于分布式系统初期的时候,往往这时候每个服务都只部署了一个节点。 那么在这样 […]
最近机缘巧合的看了《第二十四届世界哲学大会”中国商业哲学论坛”》,我们 […]
这篇是《分布式关注点系列》中负载均衡相关的内容最后一发了,后续也会继续讲高可用相关的其它主题, […]
首先声明一下,本文并不回答小马哥的问题,对问题感兴趣的话,看完本文后可移步知乎~ 关注这个号有段 […]
前面两篇《分布式系统关注点——初识「高可用」》、《分布式系统关注点——仅需这一篇,吃透「负载均 […]
本来这周想发一篇产品思维相关的文章的。但是最近和团队中的几个小伙伴聊了聊各自未来的规划,感受颇 […]
不知道大家国庆去哪玩了呢?感受如何。小Z我怕看到𠈌山𠈌海,愣是一点游玩的欲望都没有。而且看到下 […]
最近在身边了解到不少公司陷入了发展困境,相比16年那会,整个市场现在的确紧绷了许多,唱了好久的 […]
咳咳,从这篇开始,正式拉开分布式系统关注点中,我认为第二重要的内容 —— 「高可用」。 &nb […]
职场是一场长跑,想要名次靠前,不看一时的快慢,而是能否持之以恒的匀速前行。 算算正式踏上工作岗位 […]
这次准备开启一个新的系列来写了,聊聊分布式系统中的关注点。节奏不会排的太紧凑,计划两周一更吧,中间穿插着输出一 […]
前段时间有位朋友给我留言,问到微信体系内的运营该怎么做(具体场景不记得了,抱歉~)。我给TA的 […]
这次准备开启一个新的系列来写了,聊聊分布式系统中的关注点。节奏不会排的太紧凑,计划两周一更吧, […]
从自己的感受来看,今年苏宁发起的818购物节,好像气势比以往几年都要大。虽然和京东618、双1 […]
这2天大家是不是被这些图片被刷屏了。 目前网上能查到的成绩是: 连咖啡官方提供的数据,在活动上 […]
周末去看了《西虹市首富》,冲着开心麻花去的,现在开心麻花知名度越来越高,也逐渐已经成为喜剧电影 […]
最近觉得自己的“演讲技能点”没点够,想提高一下,所以才有了这篇文章。本文是阅读完《高效演讲》(某东几W销 […]
又有2周时间没冒泡了,最近实在没有大块的时间来写文章,就当找个理由。。。 也因为碎片化的时间多了,所以 […]
一、Graphql是什么 最近在折腾使用Github api做个微信小程序练练手,本篇文章就是在这个过程中 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
本书是Eric Evans对他自己写的《领域驱动设计-软件核心复杂性应对之道》的一本字典式的参考书,可用于快速 […]
出来冒个泡,又有些时日不见了。今天发一下最近针对沟通效率这个问题的思考和总结,给大家参考参考。可能有些内容大家 […]
首先真的灰常抱歉,停更了好些日子,也不给自己找借口了,现在双12也过去了,开始加快更新步伐。虽然这个号的用户数 […]
一、背景 这个标题起的有点标题党的嫌疑,这个事情的原委是这样的,有个Web API的站点在本地使用Rele […]
一、背景 大家应该在从事软件开发领域工作时间有一段时间之后,就开始有画图的意识,不管是懵懂的学别人还是想更 […]
一、背景 可能刚踏入职场的小伙伴们感受不深,毕竟初出茅庐敢闯敢拼没有包袱。但是随着工作年限的增加,开始成家 […]
一、背景 在上一篇尝试CockroachDB(传送门在此:http://www.cnblogs.com/Z […]
一、什么是领导力 评定一个领导的能力最核心的基础素质是领导力,那么领导力是什么? 领导力(Leader […]
一、什么是同理心 同理心(Empathy),又叫做换位思考、神入、共情,指站在对方立场设身处地思考的一种方 […]
一、什么是跨界 跨界的本质:是整合、是融合。通过自身资源的某一特性与其它表面上不相干的资源进行随机的搭配应用。 […]
2018
这是本系列中既「数据一致性」后的第二章节——「高可用」的完结篇。 前面几篇中z哥跟你聊了聊做「高可用」的意 […]
这次准备开启一个新的系列来写了,聊聊分布式系统中的关注点。节奏不会排的太紧凑,计划两周一更吧, […]
2017
一、CockroachDB是什么 CockroachDB(https://www.cockroachlab […]
一、前言 首先本文仅作为笔者在做一些调研之后的总结,仅提供思路,不提供源码,所以如果是想直接冲着源码来的, […]
一、单据号是指什么 我们作为一个软件系统,肯定到处充满着各种单据,也必然需要有各种单据号与之对应。 比如:电商 […]
一、前言 这是本系列的最后一篇了,后续可能会有一些关于DDD方面新的想法和问题的解决过程的文章,会另起标题来写 […]
一、前言 上篇中我们初步运用了领域事件,其中还有一些问题我们没有解决,所以实现是不健壮的,下面先来回顾一下。 […]
一、前言 之前的十一篇把用户购买商品并提交订单整个流程上的中间环节都过了一遍。现在来到了这最后一个环节,提交订 […]
一、前言 最近实在太忙,上周停更了一周。按流程一步一步走到现在,到达了整个下单流程的最后一公里——结算页的处理 […]
一、前言 之前的文章中已经涉及到了购买商品加入购物车,购物车内购物项的金额计算等功能。本篇准备把剩下的购物车的 […]
2016
一、前言 在上一篇中(如何一步一步用DDD设计一个电商网站(八)—— 会员价的集成),有一行注释的代码: 其中 […]
一、架构的定义 所谓一千个架构师中有一千种“最好的架构”模式。 “架构”是我们这行业种一个很常见的词,表明其必 […]
一、前言 前面几篇已经实现了一个基本的购买+售价计算的过程,这次再让售价丰满一些,增加一个会员价的概念。会员价 […]
一、前言 上一篇我们已经确立的购买上下文和销售上下文的交互方式,传送门在此:https://zacharyfa […]
一、前言 前几篇已经实现了一个最简单的购买过程,这次开始往这个过程中增加一些东西。比如促销、会员价等,在我们的 […]
一、前言 实际编码已经写了2篇了,在这过程中非常感谢有听到观点不同的声音,借着这个契机,今天这篇就把大家提出的 […]
一、前言 上篇中我们讲述了“把商品卖给用户”中的商品和用户的初步设计。现在把剩余的“卖”这个动作给做了。这 […]
一、前言 结合我们本次系列的第一篇博文中提到的上下文映射图(传送门:如何一步一步用DDD设计一个电商网 […]
一、前言 上一篇我们讲了DDD的核心概念(附上链接),并且设计了我们的上下文映射图,那么接下来就准备开始立项了 […]
一、前言 DDD(领域驱动设计)的一些介绍网上资料很多,这里就不继续描述了。 自己使用领域驱动设计摸滚打爬也有 […]
一、背景 在某些情况下,我们需要植入AOP代码的类并没有默认构造函数。那么此时动态生成的代理类也需要相同签 […]
上篇中说到了面临的问题(传送门:DDD设计中的Unitwork与DomainEvent如何相容?),和当时实现 […]
最近在开发过程中,遇到了一个场景,甚是棘手,在这里分享一下。希望大家脑洞大开一起来想一下解决思路 […]
2014
一、背景 随着公司的业务发展,项目越来越多,越来越大,复杂性也越来越高。查找一个BUG变得越发抓狂;新人熟 […]
一、前言 1.在项目中无处不充斥着记录日志的代码,各种try catch,实在是有点看着不爽。这不,果断要 […]