- 博客(131)
- 资源 (11)
- 收藏
- 关注
RSS订阅原创 不被AI取代的工程师
爱人在一家设计公司工作，她们公司正在为一家著名的丝绸公司做设计。有一天，我突然接到她的电话，问能否用编程绘制一个形式如下的图形。他们需要设计一个类似的丝状logo。我虽然熟悉编程，但对于电脑绘图是一窍不通，面对这个新问题，完全是一头雾水，没有头绪。GAI（Generative AI，生成式人工智能）是个不错的起点。我把上面的图片上传到豆包，询问这样的图形如何通过编程实现？在其回答中，我第一次知道了...
2025-02-25 15:28:13
1386
原创 手把手教你打造最好用的任务框架
最近两个项目中都使用了任务框架。说实话，任务框架和流程引擎有点像，鉴于我曾猛烈批评过流程引擎，我对这玩意自然也没什么好感:( 。既然如此，我为什么还要实现一个任务框架呢？主要是出于以下考虑：我们很多现有功能都是基于任务框架实现的。大家的使用和运维习惯已经养成。即使重构，最好还是保留任务框架的能力。任务框架提倡把一个任务拆分成多个step，会自动引导开发人员进行结构化分解，分而治之，对处理复杂业务有...
2025-01-22 11:17:18
2261
1
原创 操蛋的软件工程
最近看到一个说法，说软件工程本质上是“手工作坊”，是知识手工业者的大规模协作。I can‘t agree more， 这玩意就是个手艺活，极大的依赖手艺人的个人能力。是的，你没看错，在这个软件定义一切的时代，在这些光鲜靓丽的App背后，是成千上万个手艺人堆出来的风格不同、形态各异、手法不一、带有强烈个人色彩的代码。截止目前，还没有一个有效的工业化、标准化生产软件的方法。不信你去问问Google的工...
2024-11-30 10:25:10
3178
原创 一文带你成为业务分析师
2024年度脱口秀冠军付航说他做过BA，这是典型的反差幽默。因为正常认知中的BA（Business Analyst，业务分析师）是一个听起来很高大尚的职业，和保安（BA）相去甚远。理论上说，软件研发开端于需求，需求来自于业务，所以BA应该是一个不可或缺的岗位。可实际情况是，在我的从业生涯，只有早期的阿里短暂的设立过BA岗位，便裁撤了。其它公司压根连这个岗位都没有，这样看来，BA并非是不可或缺，更...
2024-11-08 16:08:24
3923
原创 抽象不稳定，老大徒伤悲
稳定抽象原则（Stable Abstractions Principle）是非常重要的抽象设计原则。小到一个类的方法，一个组件或者微服务的接口，大到整个系统的架构，都应该尽量遵循该原则。抽象是基于归纳法，所以越稳定的东西，越适合提前做好抽象复用。因为你已经了解问题的全貌，而且问题域后续变化的可能小，所以抽象出来的东西就比较稳定，也容易被复用。而越不稳定的东西，越不适合做提前抽象。这就需要我们想清楚...
2024-08-14 11:13:57
5095
原创 未来十年不变的是什么
读《一如既往》有感，本书的核心是：未来是千变万化的，但是总有一些不变的建议来给你启发，帮助你顺利前行。亚马逊公司创始人杰夫·贝佐斯曾说，人们经常问他未来 10 年的变化趋势。“但是几乎没有人问过我：‘未来 10 年里有什么事情不会改变？’我认为，这才是更重要的问题。”实际上，对于商业而言，客户对商品的“多、快、好、省”的诉求从未改变，亚马逊以客户体验（Customer Experience）为核心...
2024-08-13 09:44:22
5168
2
原创 当我说维度的时候，我到底在说什么
维度是一个非常重要的抽象概念，即使我在《程序员的底层思维》花了一章的篇幅专门介绍“维度思维”，也难尽其义。随着LLM大模型的火热，维度、向量这些基础概念变得更加重要，所以非常有必要反刍一下。1. 维度到底是什么关于维度的广义定义是这样的：维度是事物“有联系”的抽象概念的数量，“有联系”的抽象概念指和任何一个组成它的抽象概念都有联系，组成它的抽象概念的个数就是它变化的维度。比如“面积”这个概念是和“...
2024-07-23 16:12:34
6541
2
原创 再谈软件设计中的抽象思维（下），从FizzBuzz到规则引擎
作为《程序员的底层思维》出版两年之后的再回顾，在上一篇《再谈软件设计中的抽象思维（上），从封装变化开始》中，我介绍了抽象设计的本质是发现变化点，结合问题域，提炼共性，沉淀领域知识。今天这篇我们通过实现一个通用的规则引擎，进一步讲解抽象思维在软件设计中的运用。1. FizzBuzz游戏FizzBuzz是一个在欧美非常流行的小游戏，类似于我们中国人酒桌上玩的“敲7游戏”，游戏规则是这样的，假设体育老师...
2024-06-13 11:50:44
7268
1
原创 再谈软件设计中的抽象思维（上），从封装变化开始
在我2022年出版的《程序员的底层思维》中，关于抽象思维的开篇，我这样写到：“ 每当我对抽象思维有进一步的理解和认知时，我都能切身感受到它给我在编码和设计上带来的变化，同时也不禁感慨之前对它的理解为什么如此肤浅。如果时间可以倒流，我希望在职业生涯的早期就能充分意识到抽象思维的重要性，能多花时间认真研究并深刻理解它，这样应该可以少走很多弯路。 ”2年时间过去，对于抽象思维在软件设计中的运用，我又有...
2024-06-12 15:47:28
6880
1
原创 微服务的单元测试，这样做就对了
前段时间写了一篇《这才是单元测试，也许我们之前都理解错了》，文章主要是从概念出发，重新定义了“单元测试”，获得了不少朋友的共鸣。本文可以当着上一遍的姊妹篇来看，如下图所示，在上一篇中，我提出粗粒度单元测试（CUT，Coarse-grained Unit Test）和细粒度单元测试（FUT，Fine-grained Unit Test）两个新概念。对于微服务而言，我们提倡CUT优先，FUT补充的策略...
2024-06-03 11:27:24
7385
3
原创 不要迷信响应式编程，它只是编程范式中的“小丑”
我不是很理解，为什么越来越多的项目打着高性能的旗号，迷信般的使用响应式编程框架，然后把代码搞的乱七八糟。响应式编程真的那么香么？还是“天下苦响应式编程久已”，在迫害我们的祖国花朵？。在我看来，响应式编程至少犯了三宗罪：1. 易造成复杂；2. 调试困难；3. 性能迷雾。 鉴于此，我希望开发同学们在选择编程范式的时候，能擦亮自己的眼睛，选一个真正适合自己和团队的编程范式。罪一、易造成复杂响应式编程的代...
2024-05-14 12:00:37
7191
4
原创 这才是单元测试，也许我们之前都理解错了
我今天要捅一个火药桶问题：如何进行单测。因为关于这个话题的争论实在太多了。为了减少非议，首先，我要界定一下问题范围，我这里所说的测试是针对分布式系统服务（微服务）的单元测试，不同的产品形态，测试方法差异很大，比如嵌入式系统、office软件的测试不是我们要讨论的范围。其次，我直接给观点，我认为微服务的单元测试的最佳实践就是：粗粒度单元测试优先，细粒度单元测试补足，关注测试效率（执行效率、代码效率）...
2024-04-07 15:27:43
9644
2
原创 这才是单元测试，之前我们都错了
我今天要捅一个火药桶问题：如何进行单测。因为关于这个话题的争论实在太多了。为了减少非议，首先，我要界定一下问题范围，我这里所说的测试是针对分布式系统服务（微服务）的单元测试，不同的产品形态，测试方法差异很大，比如嵌入式系统、office软件的测试不是我们要讨论的范围。其次，我直接给观点，我认为微服务的单元测试的最佳实践就是：粗粒度单元测试优先，细粒度单元测试补足，关注测试效率（执行效率、代码效率）...
2024-04-06 15:21:16
7247
2
原创 关于深度学习和大模型的基础认知
这年头，作为一个技术人，话头里没有“大模型”，和人聊天都聊不下去。为了让自己和大家能更好的参与话头，特撰写此文，提供一些对大模型的基础认知能力（门外汉，浅尝辄止）。旨在解自己的一些困惑，比如，模型是什么意思？千亿/万亿参数意味着什么？为什么大模型如此耗费算力？什么是机器学习？关于什么是机器学习，李宏毅老师在其课程中说地很精辟，即 机器学习 ≈ 机器自动找一个函数f( )函数（function）就是...
2024-02-19 09:16:46
9234
3
原创 Google云的平台工程
GCP（Google Cloud Platform）是Google云，为其内部（Google search、Gmail、YouTube等）和外部客户提供IaaS、PaaS以及Serverless computing等云服务的平台。本文将带领你走进GCP，并深入体验其产品功能，感受Google云的产品设计理念以及相关架构思想。从而可以淬其精华，为我所用。本文的主要内容如下：1. 注册Free Tri...
2023-11-14 09:43:52
10098
原创 Coding只是基础，思维能力才是关键
Software engineering isn't just about keystrokes; it's fundamentally about problem-solving and critical thinking.（软件工程不只是敲键盘，其本质是解决问题的能力和批判性思维的能力）这也是我写《程序员的底层思维》这本书的初衷，coding能力和经验固然很重要，但更重要的是如何从这些经验中提...
2023-08-11 15:37:45
11818
原创 深入Spring配置内核，感受抽象的力量
我在《程序员的底层思维》中说过，抽象思维是程序员必须要掌握的重要思维能力。好的软件设计离不开抽象和抽象层次的权衡。比如你说配置就是properties文件，这个抽象层次就很低，因为yaml也可以是配置文件。好的抽象能为系统提供必要的扩展性和可维护性。本文通过深入剖析Spring配置的抽象设计，以及讲解这套抽象是如何支撑Spring，以及持续支撑SpringBoot和Spring Cloud Config的功能扩展。带你一起感受抽象的力量。
2022-12-08 11:44:15
14949
1
原创 深入浅出日志体系（logback最佳实践）
日志是影响研发效能的关键因素之一，没有好的日志规范、日志框架、日志系统、日志实践，就不可能有高的研发效率。本文我会介绍一些这些年，我积累的一些我认为比较好的日志实践。
2022-11-23 09:50:50
14890
2
原创 软件设计的三重境界：守-破-离
规矩礼仪，务必先尽守之，然后破之，离之，然皆不可忘本矣。理解守破离“守破离”最初起源于日本剑道，是一种学习剑道的方法，后来，这种方法被发展到了整个日本武术界，乃至其他各个行业，成为一种崇高的工作精神和态度，也是“工匠精神”的一个核心。在理解了守破离之后，你会发现，我们的学习都要经历守——破——离三个阶段。所谓“守”，就是最初阶段须遵从老师教诲，认真练习基础，达到熟练的境界；“破”是在基础熟练后，试...
2022-10-01 09:32:21
15091
4
原创 软件设计的中庸之道
反者道之动，过犹不及，物极必反。做人如此，做事如此，软件设计也不例外。从业的时间长了，看到过、经历过太多教条式的错误。所以特意写此文告诉大家，软件设计无其他，唯有中庸之道。1. 理解中庸在进入技术讨论之前，让我们先理解一下什么是中庸。中者，不偏不倚、无过不及之名。庸，平常也。中庸的要义在于执两用中。我们知道走极端肯定不是中庸，然而正中间也不一定就是中庸。中，不是数学和物理的绝对中间、一半、百分之五...
2022-09-08 10:23:11
13797
2
原创 微服务到底要多微？
我经常会被问到一个问题：我们的微服务边界要怎么划分？怎样的粒度才算合适？面对这样没头没脑的问题，标准答案只有一个：看情况（It depends）。这不是我故意耍小聪明，而是事实情况的确就是如此。因为微服务划分并不是单纯的技术问题，它更是业务问题，甚至是组织问题。因此，脱离业务上下文和组织边界讨论服务边界是没有意义的。 说实在的，即使你把背景都和说清楚了，我也...
2022-08-17 11:36:43
13654
4
原创 如何减少软件设计和实现之间鸿沟
在软件领域，有一个古老的神话：即我能保证设计和代码实现完全一致。这的确是一个非常有价值的目标。试想下，如果我们的系统毫无设计，或者设计和代码实现毫无关联，在当今软件如此复杂的情况下，其实现和维护难度可想而知。本文将结合我最近给ICT做软件设计培训的一些感悟，尝试介绍一些减少设计和实现之间鸿沟的方法，这些方法包括语言一致，设计一致和代码一致。除了介绍方法之外，我会以运营商计...
2022-06-27 19:50:39
13319
3
原创 跨越DDD从理论到工程落地的鸿沟
DDD作为一种优秀的设计思想，的确为复杂业务治理带来了曙光。然而因为DDD本身难以掌握，很容易造成DDD从理论到工程落地之间出现巨大的鸿沟。就像电影里面的桥段，只谈DDD理论姿势很优美，一...
2022-03-03 17:42:36
19917
38
原创 Clean Code之封装：把野兽关进笼子
如何把复杂这头野兽关进笼子，的确是我们程序员面临的巨大挑战。正如Dijkstra所说：“软件是唯一的职业，人的思维要从一个字节大幅跨越到几百兆字节，也就是九个数量级（放在今天的话，恐怕还要...
2022-01-27 11:03:07
12803
2
原创 一文教会你领域建模
我们软件工程师实际上只在做一件事情，即把现实中的问题搬到计算机上，通过信息化提升生产力。信息化的过程就是从“问题空间”到“解决方案空间”的过程。然而，“问题空间”和“解决方案空间”之间有一...
2021-12-30 12:26:13
23440
4
转载 从七个维度教你进行业务分析和软件设计
1 为什么要写技术方案回顾软件开发的历史进程，我们可以将其分为程序设计时代、程序系统时代和软件工程时代三大历史阶段。在程序设计时代（1946-1956），软件开发主要依赖于个人编程技巧，技...
2021-12-25 11:43:05
17285
原创 强大的wrapper
最近在看大数据和容器相关的东西，发现有一个模式被反复使用到，关键是被用的很恰当且优雅，并能在这些关键技术中都发挥着至关重要的核心作用。我想你已经猜到了，他就是Eminem——强大的rapp...
2021-12-22 18:42:51
14212
3
转载 DDD的模式与实践案例
花名:神帅，毕业5年,混迹于大小厂打怪刷实战经验。资深Java开发工程师。在企业服务领域和电商领域均有积累,最近一直在研究DDD和低代码领域,对后端微服务业务平台架构的实践和发展比较感兴...
2021-12-07 09:31:59
14587
1
原创 关于上下文映射看这篇就够了
本文摘自《程序员必备的思维能力》限界上下文任何问题都是有边界的，这个问题的边界也叫这领域边界。也就是说，我们要对一个问题进行分析或者建模，一定是在一个特定的上下文（Bounded Cont...
2021-08-17 11:39:43
10665
1
原创 程序员的底层思维：逻辑思维
更多关于思维能力的内容，尽在我的新书《程序员必备的思维能力》“你讲话要有逻辑！”“你这逻辑不对！”“你的底层逻辑是什么？”“说说你的逻辑思维能力体现在哪儿？”在日常交流中，我们会频繁的使用“逻辑”这个词。但能够清晰的说出逻辑的定义（什么是逻辑）应该不多，能够正确的掌握逻辑推理的人就应该更少了。对于大部分人来说，逻辑更像是一个“熟悉的陌生人”。举个例子。小王说：“Frank真不是男人，竟然会怕老鼠。”小张说：“Frank怎么不是男人，他不是男人，怎么会有鼓鼓的二头肌呢？”你觉得小张的反驳.
2021-07-31 11:48:21
18237
13
原创 业务中台的困境、及可能的解
有一个事情已经困扰我很久了——大中台、小前台作为战略已经提出很久了，在业界也掀起了不小的波澜，可是反观阿里的业务中台，为什么总觉得旁边有朵小乌云，感觉哪里不对劲。业务中台小乌云建一所房子，你要挖坑打地基，铺钢筋，然后一块砖头一块砖头的往上磊。没办法，原子世界就是这么物质，一块砖头都少不了。软件是比特世界，软件开发很少是从买服务器开始，特别是在这个Cloud Native的时代，很多基建的事情云厂商都已经帮我们做好了。IaaS是对算力、网络、存储、操作系统等基础设施的复用；PaaS是对中间件的复用；基
2021-06-29 16:11:26
11488
7
原创 程序员必备的思维能力：结构化思维
在日常工作中，我们时常会碰到这样的情况，有的人讲一件事情的时候逻辑非常混乱，说了很多事情的罗列，却说不到重点。有的人写代码，本身的业务逻辑并没有多复杂，但呈现出的代码缺像一堆线团，混乱不堪，无法理解。这些都是典型的缺少结构化思维的表现，导致我们在写作（包括写代码）、沟通、表达的时候，思维混乱，逻辑不清。结构化思维是一种从无序到有序、从混乱到清晰的思维能力，可以帮助我们快速加工处理繁杂的信息，提炼要点，从而更加清晰的表达。 本文作为思维能力的第二篇，我会系统的跟大家说说结构化思维。什么是结构结构可以说是
2021-05-08 14:25:09
12865
8
原创 程序员必备的思维能力：抽象思维
若想捉大鱼，就得潜入深渊。深渊里的鱼更有力，也更纯净。硕大而抽象，且非常美丽。——大卫·林奇抽象思维是我们工程师最重要的思维能力。因为软件技术 本质上就是一门抽象的艺术。我们的工作是存思维...
2021-02-12 18:03:28
30793
62
原创 一文教你认清领域模型和数据模型
依稀记得我第一次设计一个系统的时候，画了一堆UML图，面对Class Diagram（其实就是领域模型），纠结了好久，不知道如何落地。因为，如果按照这个类图去落数据库的话，看起来很奇怪，有点繁琐。可是不按照这个类图落库的话，又不知道这个类图画了有什么用。现在回想起来，我当时的纠结源自于我对领域模型和数据模型这两个重要概念的不清楚。最近，我发现对这两个概念的混淆不是个例，而是非常普遍的现象。其结果就是，小到会影响一些模块设计的不合理性，大到会影响像业务中台这样重大技术决策，因为如果底层的逻辑、概念、理论基础
2021-01-13 15:57:30
18124
3
原创 COLA 4.0：应用架构的最佳实践
前几天和几个饿了么的同学聊天，一听说他们还在使用COLA 1.0，我二话没说，90度鞠躬，赔礼道歉，虚心聆听他们的吐槽。COLA的初衷旨在控制复杂度，救码农于水火，惭愧的是，早期的思想不成熟，设计也多有缺陷，不仅没帮到他们，反而坑了他们，实在抱歉。实际上，我在COLA 3.0迭代的时候，已经举起奥卡姆剃刀，砍掉了很多东西。然而还不够，主要体现在对架构的思考还不够透彻。因此，经过仔细反思，有了这一版最新的COLA 4.0，期望回归初心，让COLA真正成为应用架构的最佳实践，帮助广大的业务技术同学，脱离酱缸
2020-12-09 19:27:54
244433
240
转载 为什么说应用架构需要分类思维？
阿里妹导读：如何定义架构？应用架构的要素有哪些？什么是应用架构中的分类思维？开源应用架构COLA的作者张建飞介绍他在COLA架构设计中的一些思想经验，分享他的应用架构之道。模块（Modu...
2020-11-26 11:59:52
3471
3
原创 年轻人不讲code（抠德）
年轻人不讲code（抠德）看到需求，嗖，就干起来了，很快啊！左边一个if，右边一个else。我说，小朋友，你们这样不行，写代码不能用死劲，要学会四两拨千斤，Martin、Eric、Robert、Frank都不是这么做事的。他们不服气，又搬出了微服务、中台、codeless… 一个左正蹬，一个右边腿，再加一套组合拳…一开始系统都防出去了，艰难抗住，但很快，招架不住，被整的“噼里啪啦，天女散花”。这样好吗？不好。看着奄奄一息的系统，我流泪了，这是在做工程？来——骗！来——偷袭！代码界，当以好代码
2020-11-25 20:02:00
2614
5
原创 应用架构COLA 3.1：分类思维
模块（Module）、组件（Component）、包（Package），这些概念对于我们技术同学并不陌生，但并不是所有人都能理解其要义。深入理解之后，我才发现，其背后的深意是分类思维。而这种分类也是应用架构的核心所在，通过不同粒度、不同层次的分类，把复杂的软件系统实现控制在可以被理解、被维护的程度。否则，对于动则上100万行代码的软件，人类根本没有办法理解和维护。试想一个极端情况，假如没有这些概念协助我们分类，我们把所有业务逻辑都写在一个类里面，会是什么样的结果呢？我们很多的“非人类”系统，正是因为没有
2020-11-10 19:22:10
12369
10
原创 复杂性应对之道——维度思维
You should not be a if-else coder, should be a complexity conquer. -Frank这篇文章，是对之前我在《一文教会你如何写复杂业务代码》说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我们缺少一个多维度看问题的视角，这种维度思维的缺失，可能会导致miss掉一些重要的业务信息，从而使我们制定软件设计策略的时候，陷入困难。有了维度思维，我们便可以更加方面的去看清业务的全貌，更加全面的掌握业务信息，从而.
2020-09-25 13:36:08
5056
3
原创 35岁是技术人的天花板吗？
35岁是技术人的天花板吗？我非常不认同“35岁现象”，人类没有那么脆弱，人类的智力不会说是35岁之后就停止发展，更不是说35岁之后就没有机会了。马云35岁还在教书，任正非35岁还在工厂上...
2020-09-16 10:22:33
2041
1
实现领域驱动设计精华版（英文）
2018-11-12
亚马孙文化争议（Amazon Controversy）
2017-11-02
漂亮登陆界面+Struts2 验证码 完整实现
2013-08-07
Manning EJB3 in Action
2009-08-24
J2EE Tutoria in EJB
2008-12-24
EJB Design Pattern
2008-08-27
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人