周报 #3 - I’m 21, but I’ve been blogging for almost 10 years；技术文章中的插图和代码；优秀的重构 vs 糟糕的重构

本文是这个系列第 3 期了，虽然称为周报，但就更新频率来说应该算不上。之所以定义为周报，是为了形成系列，督促自己坚持写作。未来会写多少期呢？我也不清楚。

更多文章可以移步 往期周刊

十年的博客生涯

Everything I've learned in 10 years of Blogging

从文章开头，作者就给我们了一个 惊喜。

I’m 21, but I’ve been blogging for almost 10 years.

长期坚持写博客已是一件不容易的事情，同时保持高频率更是困难重重。前面读到一篇 「什么造就了一个出色的技术博客 」，里面详细的描述了博主自己关注 「My favorite technical blogs」 的一些原因，很有道理，给大家分享一下：

• Tackle hard and confusing topics
• Show working code
• Make things simpler
• Write regularly
• ...

对我来说，更新频率 和 文章质量 占同等地位，可能我还更倾向于经常更新的博主。

回到上面的文章，作者列举了他自己对写博客的一些看法，里面有些观点说的很好。比如：

• 开门见山

  • 文章的开头尽量写的简洁和有趣，才能更好地抓住读者的注意力。

• 好文章都是修改出来的

  • 文章本天成，妙手偶得之，就像《活着》里面 把落在地上的月光描述成撒在地上的盐用来形容悲伤，余华说过这是他偶然想到的。所以好的文章从来都不是一蹴而就的，50 % 的时间用来写作，剩余时间做润色、画图、重写，这些是重要的细节。

• 有想法就马上记录下来

  • 就像我 这篇文章 对「智慧」二字的解读一样，「灵感」总是稍纵即逝的。都 4202 年 了，大家应该都可以用手机随时记录吧。我个人手机上用的是 「flomo」，它的经营理念非常独具一格——「有一份给你的七年承诺」，感兴趣的可以读一读。

• 为了应对面对写文章时空白的困难，可以先写下文章的各部分的标题

  • 可能大家都有一定程度的拖延症，写博客也一样。
• 最新文章顶部链接一些自己旧的文章
• ......

回想一下当初的自己是为啥想创建一个博客呢？答案大概是当初的自己特别喜欢浏览各种独立博客，想着自己也有一个就好了。

ps：哪怕是现在也非常喜欢看别人的博客，原因呢，引用一下 pseudoyu 的回答吧：

最开始是 Hexo 托管到 Github 上面，还没开始写，就由 左岸博客 博主引入坑，转到了 「Typecho」博客的 Mirages 主题下了，可惜该博主不更新了。

欢迎在评论区说说当初的自己是为啥想创建一个博客呢

技术文章中的插图和代码

Learn OAuth 2.0 by Building Your Own OAuth Client

JavaScript Visualized - Event Loop, Web APIs, (Micro)task Queue

插图或者代码都是文章中的很重要的部分。好的插图能让人阅读体验感拉满，好的代码示例更能让人明白文章中讲的技术问题。

文章 learn-oauth-2-0 在讲解参数含义时，右边都会高亮与之对应的代码，不像传统技术文章里面的内容和代码不能够很好对应，导致视觉上的混乱。

而 event-loop 的文章的插图极其直观和优美，能够轻松理解“事件循环”这一复杂概念。想了解事件循环的非常推荐读一读这篇文章。

绘制优秀的插图和代码示例，可能都是需要花费相当的时间和精力的。平时自己很少画图，基本上都是用 ProcessOn 来画一些流程图和思维导图，很多时候都只是截图来作为文章的配图，目前用的截图工具：

• CleanShot X（用的最多，各种渐变背景、截长图、拼接图）
• ElemSnap（一个浏览器插件，支持主流社交平台合适尺寸的渐变背景）

更多或者更好用的工具，欢迎在评论区分享下。

优秀的重构 vs 糟糕的重构

Good Refactoring vs Bad Refactoring

「重构」，相信大家或多或少都重构过一些代码，先不说重构后代码质量的好与坏，自己重构完成后那种成就感是不是十分的令自己满意，就像完成一个喜爱的作品一样。

不过就像文中作者说的那样，在他遇到的大部分开发者中，不少都相信代码需要大量重构，但实际重构后的代码更加难以理解和维护。作者自己也曾经把一个严重依赖 SEO 的网站重构成了一个 CSR 的单页面应用，导致了严重的后果。

下图的 I have a plan.

作者列举了很多的对照例子，展示对应情况下好与坏的重构对比，比如：

• 没有了解业务背景情况下，进行重构
• 过度整合代码
• 代码风格不一致
• ......

最后作者也给出如何进行重构的建议。欢迎大家发表关于 重构 更多或者不同的看法。