Xiaofeng Yuan | 袁晓峰 Site

开发者为什么要进行写作？

Fri, 10 May 2024 00:00:00 +0000

本文已获得原作者（Nina Torgunakova、Travis Turner）和 Evil Martians 授权许可进行翻译。原文讲述了开发者为什么要进行写作，以及相应的三个原则和三个阻碍。

原文链接：Why should developers write? 3 reasons and 3 common blocks
作者：Nina Torgunakova、Travis Turner
站点：Evil Martians ——位于纽约和俄罗斯的 Ruby on Rails 开发者博客。它发布了许多优秀的文章，并且是不少 gem 的赞助商。

【正文如下】

引言

为了跟上新技术及其实践的最新步伐，开发者自然而然地会发现自己在不断阅览着技术文章。但是你有没有想过写一篇呢？本文中，我们将解释如何开始——以及为什么值得这样去做。

所有开发者都会编写代码，但只有一些开发者会进行写作。然而，写作有助于扩大职业机会，提升专业技能，并在整个社区内分享你的想法和知识。

尽管如此，尽管有这些好处，许多人还是很难迈出第一步：也许很难选择一个概念，或许很难处理潜在的负面反馈，或者有总是拖延的倾向。

本文中，我们将探讨三个因素，它们使得突破这些障碍中的任何一个来发表你的写作成为值得付出的努力，我们也将研究三个潜在的障碍以及如何克服它们。

然后，在本系列的下一篇文章中，我们将为那些准备采取下一步行动的人分享可操作的项目，但首先，我们需要回到一个关键问题：

为什么技术文章的写作很有价值？

让我们首先解释撰写技术文章值得你花时间的三个原因。

原因一：发表文章可以扩展你的个人作品集，扩展你的职业机会

首先，所发表文章的存在清楚地表明了开发者致力于专业的自我提升。

雇主可以很快认识到，开发者致力于他们的专业，而不仅仅是“工作”。所有这些都对正在招聘的公司具有天然的吸引力。

接下来，写作使雇主能够分析你的技术技能之外的东西：你的写作能力。

这很重要，因为写作和作文技巧通常伴随着高水平的沟通技能，许多雇主都非常欣赏这一点。在 37signals 的 Getting Real 一书中，他们分享了以下内容：

If you are trying to decide between a few people to fill a position, always hire the better writer.

如果你想在几个人之间做出决定来填补一个职位，请始终聘请写作能力更好的那个。

但是那些已经就业的人呢？

这就引出了第三点：在许多情况下，经理或团队领导会将发表文章视为晋升的额外积极因素。

而且，如果你想换工作，拥有一些出版物可以让你作为专家更出名，并为你开辟新的工作机会。

因此，如果你想总体上改善自己的职业生涯，开始写作练习是很好的第一步。

原因二：当你写一些东西时，你会更深入地调研这个主题

撰写技术文章时面临的最大挑战之一是让文字对某一范围内的读者尽可能清晰，而这些读者都具有不同的背景和知识储备。

Of course, some articles are intended for specialists with an already high level of knowledge in a certain topic–but this kind of text still shouldn’t be confusing.

当然，有些文章是为在某个主题上已经有很高知识水平的专家准备的——但这种文字仍然不应该让人感到困惑。

只有当你对你所选择的主题有足够深入的理解时，才有可能达到这种令人满意的清晰度。正如 Micheal A. Covington 博士在 How to Write More Clearly, Think More Clearly, and Learn Complex Material More Easily 书中所写：

Clear writing leads to clear thinking. You don’t know what you know until you try to express it.

清晰的写作导致清晰的思考。在你试图表达它之前，你不知道你所知道的。

为此，在写文章之前，我们必须研究相关资料，查找现有文献或类似文章，在某些情况下，我们必须编写代码为读者提供一个清晰的实际示例——所有这些都涉及更深入地研究该主题，因此，它使得我们增加了自己对该主题的理解。

还有一点：如果你有强烈的愿望，不要害怕写关于你不理解的主题的文章。

这里最重要的是在准备阶段花时间进行彻底、详细的研究，以便以全面的方式向读者（和您自己）解释困难的事情。

写作是一个澄清你的理解和进一步自学的机会。

请记住，技术文章的写作本质上是一个教导读者的过程，正如一句拉丁谚语所说，“教导他人时，我们也在教导自己”。

原因三：发表文章可以让你参与并进一步发展软件工程社区

在软件工程领域工作，我们不断学习，以便与新技术保持同步。

但这个过程往往存在于任何职业需求之外：我们中的许多人，在空闲时间，从事自己的项目，阅读技术文章，相互讨论技术问题……或者争论它们。

所有这些事情都以某种方式促进了整个行业生态的发展，而撰写文章是我们丰富自身对软件工程社区的参与并进一步促进它的另一种方式。

何以致此？因为发表文章使我们能够分享有关开发、设计和业务的重要（甚至是独特）想法。

一篇好文章可以在短短十五分钟内扩展读者对某个主题的了解！如果你的写作涉及一个通常很少被报道的主题，那么它可能会特别有价值。

此外，新的方法和想法往往作为写作的结果而真正站稳脚跟。

实际上还有更多的好处需要考虑，在某种程度上，这将是一个单独的发现过程。不过，一旦你决定要这样做，那就成功了一半。

另一半是完成你的第一篇文章，所以接下来，让我们看看对于这个领域有抱负的作者经常面临的一些常见障碍，以及如何解决它们。

障碍一：我不知道该写什么

找到一个要写的主题通常是我们面临的最困难的挑战，而这个问题通常在这个过程的一开始就会给我们以迎头痛击。

Almost everyone faces this, and, actually, this is a recurring challenge beyond that first article.

几乎每个人都面临这个问题，实际上，这是第一篇文章之外的一个反复出现的挑战。

那么，写什么呢？让我们试着找到一种打破僵局的方法，与我们工作的技术方面进行类比。

试着想想你上一次在工作中遇到一些挑战的时候，比如实现一个复杂的功能。你有没有研究过这个问题，发现过一些关于它的有所帮助的新信息？

例如，是否有其他人已经在努力做你正在尝试的同样的事情？

事实上，这种体验可以成为新文章的良好起点！你可以描述这个克服障碍并找到最终解决方案的旅程。

你也可以写下你用来解决特定问题的技术和工具（只要确保你没有违反任何 NDA 规则）。

一个主题是否被涵盖并不一定重要，因为你的经验没有在内。实践和经验通常与文档一样有价值（甚至更有价值）。

再或，让我们看看另一个起点：有时，由于与同事进行了激烈的讨论，文章创意可能会变得呼之欲出。

如果一个热门话题足以引起你的兴趣，这意味着它也很容易与其他人相关。有了辩论、证据或实验所支持的观点，你就可以根据自己的信念和事实来写一篇文章。

谁知道呢？文章应该可能并不像社交媒体那样短暂，可能正是你的想法被坚持下去，并将行业推向一个新的方向。

如果看完以上内容后什么都想不到，试着给自己一个提醒：下次在工作中遇到困难的挑战，或者与持不同观点的同事进行有趣的讨论时，请注意这一点！

做笔记并反思讨论，因为这可能就是你下一篇文章的起源。

确定文章创作的主题是一项可以磨练的技能，但第一步是将你的思维方式转变为一种开放的模式，这样当机会出现时，你就能认识到它是什么。

障碍二：我害怕负面反馈（或缺乏曝光）

一个事实是：你的第一篇文章几乎肯定会比第十篇更糟糕——这几乎适用于你在生活中练习的任何其他技能。

（当然，即使是你的第一篇文章也有可能成为社区受欢迎和有价值的东西！）

无论如何，你撰写的每篇新文章都可以让你获得有用的写作经验，扩展你的作品集，并为社区做出贡献。

说真的，没有必要担心你的第一篇文章是否会立即流行起来——这种心态可能是一个巨大的心理障碍，阻碍你取得进步。

以下是一些增加文章曝光度和反馈量的方法：

对于发布而言，请尝试找到一个拥有庞大而友好的开发者社区的平台，例如 dev.to 或 medium.com
不要犹豫，在社交媒体上与你的关注者分享你的文章
询问你重视其意见的人是否可以阅读你的文章。倾听他们的反馈，从中学习
寻找相关的 newsletters：根据你的主题，有许多广泛分发的电子邮件 newsletters;他们经常接受提交

不要害怕负面反馈——这很好！一些批评可以让你改进资料或学习新的东西。

最后一点：要记住的是，有时负面反馈可能不包括公正的批评，而是攻击性的评论。想想娱乐相关评论的个人价值。反思它真的能帮助你改进吗？

我们的建议是：不要把它放在心上。

障碍三：我有拖延症，我试图写一些东西通常会没结果

如果你想写作，但只是发现你无休止地拖延或推迟任务，这可能是一个迹象即你的大脑觉得这项任务不那么容易、不那么愉快，或者你对这个主题缺乏理解。

下面是解决此问题的一些建议：

试着采取一些小步骤——不要给自己设定一次写完所有内容的压倒性任务。例如，从文章大纲开始：定义文章的目的及其主要思想。这更像是一个粗略的草图，或者一个骨架。然后，开始填充结构，随后在每个点上展开。
不要因为试图立即写出完美的文字而使你的任务复杂化。先写草稿的第一版;然后重新阅读它，纠正任何错误，删除不必要的东西，并编辑你不喜欢的内容。重复几次，直到文本易于阅读。
当你完成你的文章时，向自己兑现一个愉快的奖励！每次你拿起键盘写下另一段文字时，都要表扬自己：这意味着你选择提高自己的技能并投资于自己——这是一件很棒的事！

写作是一项如同其他技能一样的技能，它会在多个方面影响你：它可以成为一种爱好，为自己提供无数机会，甚至可以激发未来。

而最重要的一条建议：不要怀疑自己。

每篇优秀文章的作者背后都是一个曾开始走上这条道路的人的故事。请继续关注我们的下一篇文章，我们将保持更新！

Vladimir Dementyev 赠书

Fri, 15 Sep 2023 00:00:00 +0000

2023 年 7 月，忽然收到了 Vladimir Dementyev 的一封邮件，说他写了本新书在 Packt 即将出版，也希望赠送我一本，让我把邮寄地址告诉他一下。前两天，这本书终于姗姗来迟，我收到了 DHL 的清关申报通知。而今天，DHL 寄件已放入丰巢的微信通知出现在我手机上。

拿到包裹后看了下，发现 Packt 的发出地居然是印度，有点意外。还以为它家在日本或东南亚会有仓库呢，没想到离中国最近的地方居然是印度。属实没想到。

Vladimir 在 RubyConf 2023 做了一个主题演讲：“Rails as a piece of birthday cake”。这是关于领域驱动设计方面关于分层架构在 Ruby on Rails 上的一个探讨。

他在最后说道：

“Okay, final thing. What’s missing from this talk? A lot of things, because this talk is just 40 minutes and to better reflect on these ideas, I had to write a book, the whole book on exploring the extended Rails way.” 😄

然后……这本书就如约而来👍。Evil Martians 也专门著文推荐了这本书：“It deserved its own tome: Layered Design and the Extended Rails Way”

我收到的，正是这本。🍺🍺

懒惰的 Neovim

Mon, 13 Feb 2023 00:00:00 +0000

“懒惰是程序员的美德”，这是一句计算机软件开发领域的名言。越是好的程序员，越追求高效的工作模式。这种高效，在旁人看来，往往体现为一种“懒惰”的外在形式。换句话说，“懒惰”不过是“高效”的一件伪装而已。

我最近接触到了一个超大的 Rails 项目，其目录下包含的文件数量达到了 10 万的级别。当我用 Neovim 打开它开始工作的时候，无论是搜索文件进行切换，还是在项目内 Grep 查找文本，都明显感觉到了响应速度的迟缓，达到了 3 ～ 4 秒的延迟。要知道，这些操作是开发时会频繁进行的操作，一天估计怎么也要数百次，要每次都是这种迟钝的顿挫感，那对工作影响是极大的拖累，已经到了必须要解决的地步。

而故事就从最近刚刚出现的一个 Neovim 插件（Plugin）—— lazy.nvim 说起。lazy.nvim 的作者是 folke。这可是 Neovim Plugin 社区一个著名的作者，

他推出了许多高质量的 Neovim 插件，例如：which-key.nvim，trouble.nvim，noice.nvim，和当前 Neovim 最火 🔥 的配色主题（colorscheme）：tokyonight.nvim。这些插件现在都高居 GitHub 同类插件排名的前一页或前三页上。

而他最新（2022.12.22）推出的一款 Neovim Plugin Manager（插件管理器），则以极其出色的功能特性和加载速度，从诞生至今不过短短的两个月，就已经迅速在 Neovim 社区内获得推崇无数，把之前一直排名第一的另一款插件管理器 packer.nvim 挤下了王座。lazy.nvim 可以说是站在了 packer.nvim 的肩上，吸取了后者在设计上的经验和教训，做出了更好的使用体验。尤其是在速度上完胜后者，成为其最大的亮点。

从 lazy.nvim 推出之日起，我就一直在关注它的发展——因为 folke 的 GitHub 早就在自己的收藏夹里了 😄，而出于上述两个方面的原因，终于决定花点时间，对自己的 Neovim 配置进行一次完全的重构，基于 lazy.nvim 的重构，而且是全部 Lua 语言的实现方式。

重构的过程就不赘述了。值得一提的一个点是重构之后的文件目录结构更加合理了。原先我是把很多插件的声明加载代码和它们的配置代码进行了分离，写到不同的文件中。这既让文件目录结构变得臃肿，也不那么优美。要修改维护的时候得在多处地方调整，容易遗漏掉。而本次重构则使用 lazy.nvim 的 lazy 加载特性很好地解决了这个问题——每个插件都跟自己的配置放在同一处。

至于重构前后的加载速度有多大差别？用截图直接对比看看吧：

旧配置（packer.nvim）
新配置（lazy.nvim）

从 216.1 ms 到 23.46 ms，几乎是 10 倍的提升！❤️

回到本文开头的那句话，那么这里可以续一句：

懒惰是程序员的美德，懒惰（Lazy）的 Vimer 就用 lazy.nvim。

如果对我的个人 Neovim 配置有兴趣，可以在这里查看，欢迎交流🤝

10 倍生产力程序员的特质

Tue, 06 Dec 2022 00:00:00 +0000

今天看到 37signals 最新的一篇博客，Alberto Fernández-Capel 所写的《The 10x Development Environment》。针对近两年比较流行的“10 倍生产力程序员”的说法，他在里面提出了一个观点，很有意思，在某些方面引起了我的共鸣。遂以记之。

Alberto Fernández-Capel 在文中认为，那种“10 倍生产力程序员”，之所以能做到远超一般程序员的 10 倍效率，归根结底，是能够自己打造出一个适合自身的“10 倍生产力的开发环境”。在这样的环境里，就能如虎添翼，把工作效率提升到极致。

Alberto Fernández-Capel 在文中以他自己为例，详细列举了从工作流程到技术栈再到团队等各个方面是如何打造出这样一个环境的。当然具体细节可以去看看原文，里面都是满满的值得借鉴的经验和技巧，足以让你收获十足。

Alberto Fernández-Capel 在最后总结了这类人（“10 倍生产力”）的特质，从某些角度看，我自己的工作或生活中，也在自觉或不自觉地践行着这些思想。😄

比如这个：

In our culture we seem to be obsessed with productivity tips. We want to know about this secret productivity hack, this little detail that you can easily change in your morning routine and suddenly be 2x more productive. Bonus points if you can stack it up with other improbable productivity gains and be 4x, 8x, 16x… more productive.

在我们的文化中，我们似乎痴迷于生产力提升的各种技巧。我们想知道那个生产力的秘诀及其微小细节。这个秘诀可以很容易地改变你的日常工作，并突然提高 2 倍的生产力。如果你能将其与其他不可思议的生产力提高叠加起来，并提高 4 倍、8 倍、16 倍……生产力，那就更棒了。

这个：

In the programming world this manifests as endless discussions about workflow improvements: which editor — vim or emacs — or which keyboard layout or key bindings allow you to type faster, or how to make your tests run faster, or about the nuances of a linter rule. These are all fine and useful — I like nuanced discussions more than anyone, and I’ll take any marginal improvement that I can get! But the big productivity gains only come from getting the fundamentals right.

在编程世界中，这体现为关于工作流改进的无止境的讨论：使用哪个编辑器（vim 或 emacs），使用哪个键盘布局或键的绑定而能使你更快地输入，或者如何使测试更快地运行，或者关于 linter 规则的细微差别。这些都很好，也很有用——我比任何人都更喜欢细致入微的讨论，我会接受任何所能得到的微小改进！但生产力的巨大提升只能来自于正确的基石。

以及这个：

To do good work you need to have time to focus on the work itself. You need to have a solid technical foundation. You need autonomy. You need to make hard decisions about what’s important and what’s accessory. That’s what makes the big difference and can increase your productivity manifold.

要做好工作，你需要花时间专注于工作本身，需要有坚实的技术基础，需要自律自主，需要做出艰难的决定来决定什么是重要的，什么是次要的。这些，就是能够在各个方面提高你生产力并造成巨大差异的原因。

我想，如上所述的这种追求，对于一名开发者而言，值得一直坚持下去。

TestProf 文档中文版翻译完成上线

Tue, 18 Aug 2020 00:00:00 +0000

我在前几篇博客中翻译推荐了关于 TestProf 的一些使用方法和技巧，这个 Evil Martins 出品的 Ruby 测试工具 Gem 的强大和有趣，从中可窥一斑。要想了解和使用 TestProf 的全部功能，当然还是需要去看它的官方文档（地址：https://test-prof.evilmartians.io）。顺便说一句，连这个 Gem 文档的网站都秉承了 Evil Martins 的一贯风格，同样的精致，同样的讲究设计感。

为了更好地推荐给国内的 Ruby 开发者，于是我有了一个大胆的想法。我给 TestProf 作者 Vladimir Dementyev 发了邮件，向他询问关于把 TestProf 的文档进行中文化的意向。Vladimir 技术很厉害，没想到人也非常好沟通。作为作者，当然他也是希望把文档翻译成更多的本地化语言，好推广给更多的 Ruby 开发者了。不过他同时回复说文档网站目前还不支持多语言，需要先调研一下，尽快告诉我结果。

而他只用了两个晚上，就搞定了把原本只支持英文的文档网站，扩展升级为支持多语言的版本，并且添加了全部文档的俄语版本进行验证。既然文档的网站一切准备就绪，那么接下来就等我的中文化翻译了。

翻译工作从 2020.07.24 开始，到 2020.08.12 完成最后一篇，共耗时 12 天。

中文版本来可以那时就上线的，不巧的是，正好碰上是 Vladimir 的假期，只能等他回来再处理。

今天，TestProf 文档的中文版终于正式放出，可供所有 Ruby 开发者查阅了。效果如下：

Vladimir 也在 Twitter 上发布了中文版文档上线的消息:)

衷心希望 TestProf 的中文文档能够帮助所有国内的 Ruby 开发者把测试写得更加高效，也让编写测试成为一种乐趣，从而让 Ruby/Rails 程序更加完美！

附注

TestProf 中文文档的 GitHub 地址是：https://github.com/test-prof/docs-zh-cn，欢迎各位小伙伴针对文档中翻译不准确甚至有误的地方提 issue 给予反馈。