杂谈 on 雪狼的书斋

1.君子不器

Mon, 01 Jan 0001 00:00:00 +0000

「器」的悲哀：你正在被定义为一颗螺丝钉吗？#

孔子在《论语·为政》中说：「君子不器。」

这句话流传了两千多年，在当下这个剧烈变化的时代，更显真谛。孔老夫子的意思是：君子不应该像器皿一样，只有单一的用途。

一个杯子，只能盛水；一把锤子，只能敲钉子。如果你把自己仅仅定义为「切图仔」、「Java 后端」、「测试工程师」，那么你就把自己变成了一个「器」 —— 一颗随时可能被替代的螺丝钉。

在工业时代，流水线需要的是标准的螺丝钉。但在 AI 时代，做一个「器」是极其危险的。因为所有的单一技能，最终都会被 AI 以极低的成本替代，甚至淘汰。那么，我们该如何避免这种「器的悲哀」？

打破边界：从「我」到「我们」#

很多程序员的职业天花板，往往不是技术能力，而是角色认知的局限。

前端说：「接口报 500 了，那是后端的事，别找我。」
后端说：「页面样式乱了，那是前端的事，我只管数据。」
开发说：「上线挂了，那是运维的事，我的代码在本地是好的。」

这种画地为牢的心态，就是典型的「器」思维。它让你把自己局限在一个狭小的舒适区里，看不见系统的全貌。

君子不器，意味着你要打破这些人为设定的边界。

当你是一个前端时，你应该去了解后端是怎么工作的，数据库是怎么设计的。当你是一个开发时，你应该去了解产品是怎么规划的，运维是怎么部署的。

这不是让你一个人干完所有人的活，而是让你拥有全局视角（Holistic View）。当你拥有了全局视角，你写的代码就会更健壮，你的沟通就会更顺畅，你的价值就会成倍增长。

全栈：不是样样稀松，而是触类旁通#

「全栈工程师」（Full Stack Engineer）这个词曾经很火，后来又被很多人诟病，说全栈就是「样样通，样样松」。

真正的全栈，并不是要求你精通每一门技术。人的精力是有限的，你不可能既是顶级的 DBA，又是顶级的后端架构师，还是顶级的算法专家。

全栈的本质，是解决问题的能力不被技术栈所限制。

当项目需要一个管理后台时，你可以用 Angular + NestJS 快速搞定；当需要做数据分析时，你可以捡起 Python 跑几个脚本；当需要优化性能时，你可以去研究 Nginx 的配置。

你可能不是每个领域的专家，但你拥有快速学习并解决问题的能力。这才是 AI 时代最核心的竞争力。

产品思维：技术人的终极进化#

比技术全栈更重要的，是思维全栈。也就是拥有产品思维。

很多技术人容易陷入「自嗨」模式：为了用新技术而重构，为了追求极致性能而过度优化。却忘了问一个最根本的问题：这能给用户带来什么价值？

拥有产品思维的技术人，会思考：

这个功能真的是用户需要的吗？
有没有更简单的低成本方案能达到同样的效果？
这个技术决策会如何影响产品的上市时间（TTM）？

当你开始用商业价值来衡量技术决策时，你就完成了从「码农」到「工程师」，再到「技术合伙人」的蜕变。

结语#

不要做一把只能敲钉子的锤子，要做一只拥有无限可能的瑞士军刀。

在这个技术日新月异的时代，唯一的铁饭碗，就是你不断打破边界、重塑自我的能力。

君子不器，周行天下。

2.直言不讳

Mon, 01 Jan 0001 00:00:00 +0000

为什么我们害怕说真话？#

在东方的职场文化中，「和为贵」的思想根深蒂固。我们害怕冲突，害怕得罪人，害怕因为一句批评而破坏了同事关系。

于是，在 Code Review 时，我们明明看到了一坨「屎山」，却委婉地说：「这个逻辑是不是可以再优化一下？」在需求评审时，我们明明觉得这个功能毫无价值，却沉默不语，心里想着：「反正产品经理让做就做呗，到时候没人用也不关我事。」

这种「一团和气」的背后，是对产品、对团队、对公司最大的不负责任。这是一种伪善。我们是否真的能做到在关怀与挑战之间找到平衡，让团队敢于直言不讳，共同成长？

什么是「直言不讳」？#

「直言不讳」（Radical Candor）不是让你做一个只会喷人的「杠精」，也不是让你进行人身攻击。它包含两个核心要素：

个人关怀（Care Personally）：你必须发自内心地关心对方，希望对方成长，希望项目成功。
直接挑战（Challenge Directly）：在关怀的基础上，直接指出问题，不拐弯抹角，不留情面。

这两者缺一不可。

只有直接挑战没有个人关怀，那是恶意攻击（Obnoxious Aggression）。
只有个人关怀没有直接挑战，那是滥用同情（Ruinous Empathy），这是最常见的职场烂好人，最终会害了对方。
既没有关怀也没有挑战，那是虚伪操纵（Manipulative Insincerity），纯粹的职场厚黑学。

为什么产品研发需要「直言不讳」？#

软件工程是一个极其复杂的智力活动，没有人是全知全能的。

纠错成本：一个架构设计的缺陷，如果在设计评审阶段被指出，改动成本可能只是几句话；如果在代码写完后被指出，成本是几天；如果在上线后才暴露，成本可能是巨大的经济损失和品牌信誉。直言不讳能将纠错点尽可能前移。
激发创意：最好的创意往往是在激烈的思想碰撞中产生的。如果大家都唯唯诺诺，只会产出平庸的产品。
建立信任：这听起来很反直觉，但真正的信任不是建立在客客气气上，而是建立在「我知道你会为了我好而告诉我真相」上。当你可以放心地把后背交给战友，相信他会在你犯错时第一时间拉你一把，这才是最坚固的信任。

如何践行「直言不讳」？#

1. 对事不对人#

这是老生常谈，但很难做到。批评时，请聚焦于具体的行为和结果，而不是对方的性格或能力。

错误示范：「你写的代码太烂了，你是不是没带脑子？」（攻击人）
正确示范：「这个函数的复杂度太高了，嵌套了五层，导致可读性很差，且难以测试。建议拆分成几个子函数。」（讨论事）

2. 接受被怼的雅量#

作为团队的 Leader 或资深员工，你要带头接受批评。当新人指出你的错误时，不要急着辩解，先听完，如果是对的，公开承认并感谢他。

在 ThoughtWorks，我们有一种文化叫「No VIP」。无论你是刚刚入职的毕业生，还是工作二十年的总监，在技术真理面前，人人平等。如果架构师的设计有漏洞，应届生完全可以跳起来反对。

3. 赞美要公开，批评要私下？不一定。#

传统的管理学建议「公开赞美，私下批评」。但在高绩效的技术团队中，对于技术问题、设计方案的批评，公开进行往往更有效。因为这不仅仅是纠正一个人的错误，更是一次全员学习的机会，也是树立技术标准的时刻。

当然，如果涉及到个人态度、职业素养等敏感问题，仍然建议私下沟通。

结语：良药苦口#

直言不讳就像是一剂中药，入口虽苦，却能治病救人。

在一个充满不确定性的商业世界里，我们就像是一群在迷雾中探险的旅人。只有每个人都敢于大声喊出自己看到的悬崖和陷阱，我们这支队伍才能走得更远。

别做那个为了「面子」而眼睁睁看着船沉没的水手。

3.自律即自由

Mon, 01 Jan 0001 00:00:00 +0000

「七十而从心所欲，不逾矩。」这是孔子对自己人生最高境界的总结。一个「从心所欲」，道尽了极致的自由；一个「不逾矩」，又暗含着深刻的自律。这看似矛盾的二者，究竟如何在一个人身上达到完美的统一？这，或许正是我们每个人，尤其是技术人，在追求自我修养时所面临的终极拷问。

我们渴望真正的自由 —— 那种不装在套子里、不为世俗所累、不刻意特立独行的深刻自由。它意味着想我所想、做我想做、说我想说，达到立德立功立言的境界。然而，这份自由并非没有边界，它需要我们不断探索世界的规律、社会的规矩，并在对人性的深刻思考中，构建起一个统一的思想体系。

在成长过程中，我们总是在「他律」中被磨平棱角，学会适应规则。但这是否意味着我们必须牺牲内心的原则与自由的灵魂？当我们为了发泄而伤害他人，或为了「不逾矩」而委屈自己时，这两种损失都同样可惜。

那么，如何才能找到那条既能「从心所欲」，又能「不逾矩」的通途？答案，或许就在于自律。它并非束缚，而是通向更高层次自由的唯一桥梁。

在成长过程中，你会不断的探索世界的规律、社会的规矩，并且在对人性的不断思考和理解中，将其构建成一个统一的思想体系。而你自己，在这个思想体系的指导下，做任何一件事，都不会引发自己的逻辑冲突。如果你这个思想体系的边界，能做到与社会的普遍规律相一致，那么这个世界便是你的天地。在你的天地中，便意味着无限的空间，不再有碰壁的可能。

在中国文化中，这种自由与自律的平衡与统一，固然没有几个人能做到，但是却渗透在我们的诗词歌赋中，渗透在我们的历史典故和民间传说中，渗透在父亲的责骂和母亲的哭泣中，永远难忘记。我们今天觉得每一句「子曰」都仿佛平淡无奇，其实是因为「子曰」是水，我们是鱼，而鱼是看不见水的。

当新冠来袭，很多中国人都默默地收起了旅行计划，准备把一场携天地之威而来的大洪水消弭于无形。我们不逃避，我们不求神，我们不拜佛，只想沉默地进行一场战斗，在打出「全剧终」之前，不言败。

我们没有斩天的刀，我们没有筑坝的息壤，但我们有人间最好的武器，那便是自律。

当武汉宣布封城，一千多万武汉人民速冻了自己的生活。没有打砸抢烧，没有哭天喊地，只有沉默的坚守，只有默默地承受、默默地牺牲。即使在痛苦中承受着别人的错误，也要让这种牺牲止于自己。他们，就是上甘岭上一动不动的英雄。中国，要给武汉人民一句感谢；世界，也要给武汉人民一句感谢。

中国其他地区能够得以复工复产的自由，来自武汉人民的自律，也来自全国人民的自律。一场《流浪地球》般的饱和式救援，在现实中上演。谁能想到在一个办公室中尚且内斗不止的中国人，竟然自发组织出了无数支大大小小的救援队伍，用人员、用物资、用难以想象的速度，硬生生把一条指数增长曲线给砸成了指数式衰减曲线？就连中国自己的防疫专家建立的计算机模型都脱靶了。把无数陌生人组织成战役小分队，并最终汇合成一场大会战的原力，除了「我们是中国人」的认同感之外，首推便是自律的力量。

展望#

自律，并非只在灾难中才能展现。生活中，我们也处处体现着自律。

在自律中，我们不断探索自由的边界。即使还有很多无奈，但只要一点点去争取、去改变，我们的自由总会扩展到让每个人都尽可能舒适的程度。当每个人的自由与自律都能合一的时候，那便是乐土。

世外没有天堂，乐土就在人间。

谨以此文，纪念我们的 2020 魔幻式开局，以及预期中的魔幻式结局。

4.Github 的用法与礼仪

Mon, 01 Jan 0001 00:00:00 +0000

你是否也曾想为心仪的开源项目贡献一份力量，却又担心「姿势不对」？抑或是初次接触 GitHub，面对 Watch、Star、Fork 等按钮感到一头雾水？前一阵国内用户滥用 Issue 的风波，更是引发了我们对全球开源社区协作规范的深思。

作为一名在 GitHub 浪迹多年的老兵，雪狼今天就来和你聊聊，如何在这片充满活力的数字土地上，游刃有余地穿梭，并成为一名受人尊敬的贡献者。

作为游客#

当你访问一个仓库的时候，会遇到三个按钮：Watch（关注） / Star（星标） / Fork（分叉）。

Watch 表示你对这个仓库中发生的事件感兴趣，比如出现了新的 issue 等。当这些事件发生时，GitHub 就会自动给你一个页面通知，并往你的注册邮箱发送一封邮件。当然，你也可以在通知设置界面禁止这些通知。当你 Watch 很多仓库的时候，通知邮件可能会把你的邮箱塞满。这时候，除了在自己的邮箱设置规则之外，也可以在这里禁用通知。

Star 表示特别标记这个仓库，这和邮箱中的 Star 是一样的。严格意义上，它只是你个人需要经常访问它而进行的快捷标注，这样你就能通过 Your stars 页面（比如我 Star 过的项目）来快速找到这些项目了。它经常被用作表达支持的投票，官方也提倡如此，不过我很少会这么做。

Fork 有两种用途：

你要参与它，为它提交代码，这部分我会在稍后的【作为贡献者】部分细讲。
觉得这个仓库可能会被原作者删掉，因此 Fork 出来一份。这样即使作者删掉了，你这里也有一个 Fork 那个时间点的版本的快照。不过要注意，Fork 出来的版本是不会随着原始仓库而自动更新的。

理想情况下，后一种情况该算误用，因为已经开源出来的代码原作者是不应该删除的。但是确实有过被删除的情况。所以有时候我会把 Fork 但不打算发 PR 的行为看作是对库作者的「不信任投票」。当然，大多数的仓库作者可能不会这么想。

作为贡献者#

贡献的形式有两种：提 issue 和提 pull request（简称 PR）。这两者有一些共同的要求，包括：

认真看并遵循对方给出的 issue 模板 / PR 模板。
及时跟进，当对方有回复时，应该尽早给出足够明确的回答。如果觉得对方的答复已经解决了你的问题，或者这个确实不是问题，就及时关闭，不要等作者动手。
大多数仓库都要用英语提，但专门面向中文用户的仓库是例外。其实这一点并没有想象中的那么难，现在的 Google Translate 已经非常强大了，而且 https://translate.google.cn 不用翻墙也能访问。只要写好中文，然后在里面翻译成英文，再修正一下英文翻译就可以了。

接下来我再分别细说一下它们。

提 issue 也就是提问题，可以再细分为两种：提 BUG 和提需求（Feature Request / Proposal）。

5.开发人员要掌握的十八条 Docker 知识

Mon, 01 Jan 0001 00:00:00 +0000

为什么说 Docker 是轻量级虚拟技术？#

虚拟技术按照重量级大致可分为如下几种（从重到轻）：

硬件仿真

典型的有 QEMU 、Android 模拟器以及各种街机模拟器。它们会在宿主机上运行一个 CPU 指令的解释器，因此可以运行不同 CPU

指令集下的应用。硬件仿真方式的额外运行开销极大，限制了其应用场景，但是只是有些场景下只有这种方式可以解决。
设备虚拟化

典型的有 VMWare Workstation、Virtual Box 等。与硬件仿真不同，它们只负责把客户机对设备的请求，转发给宿主机，因此无法跨 CPU

指令集。相应的，其额外开销也小得多。根据是否需要修改宿主操作系统以配合客户机，它又可分为全虚拟化和半虚拟化。
容器技术

典型的有 Docker、LXD 等。它们的内核都是 LXC，这是 Linux

操作系统提供的容器化技术，它不会虚拟化任何设备，只会利用命名空间对系统资源进行隔离。显然，这种方式的开销是极小的，和原生应用几乎没有差别。

这样一来，每个容器中的进程都只能访问所属命名空间中的资源，不同容器中的资源彼此独立，它们可以使用相同的端口、文件名而不会互相干扰。这种特性，让应用在部署时不需要考虑所在的环境，从而显著简化了运维工作。这促成了

Docker 的流行。

值得注意的是，Docker 自己实现了一个特殊的文件系统，这个文件系统的思维模型类似于 Git 或

CSS，其最终结果是由一系列单层镜像叠加而成的。镜像（image）中包含的层都是只读的，而容器（container）则会在镜像层之上叠加一个读写层，所有你在容器中进行的修改都会保存在读写层中。当你用 docker commit

命令提交这个容器时，这个读写层就会变成只读层，并连同其基础镜像的只读层一起变成一个新的镜像。

先对这个文件系统有个印象，后面的很多内容都与此相关。
专用子系统

典型的是 Windows 10 下的 WSL，它可以让你在 Windows 上运行绝大多数 Linux 程序。事实上，Windows 10

中和我们打交道的那部分叫做 “Win32 子系统”，而 WSL 的全称则是 “Windows Subsystem for Linux”。顾名思义，WSL 是个跟 “Win32

子系统” 平等的专用 API 层。在这种模式下 WSL 中的文件、端口等资源都是共享的，因为这些都是属于 Windows 内核的一部分，而

Win32 子系统和 WSL 子系统都共享同一个内核。