D 的个人博客

以目前来看，GitHub 上有用的仓库大致分为两种类型，项目和文档。

以代码为主的可运行项目

这类项目（排除那些没有替代品的）是有具体使用场景的，或是框架或是应用。如果从星数看，这类项目是比较难获得星的，因为：

• 项目具体的使用场景相对固定，这也就决定了其目标用户毕竟是少数
• 项目的效果非常直观，通过代码质量、运行结果、文档、社区等可以很容易对比出同类项目的优劣

如果你“看不起”或者“看不懂” 的项目有较多星，说明的确是对一部分人有用，这是真的有价值的项目。它们节省了目标用户的时间、减少潜在的缺陷等。另外，这类的项目同质化严重，基本都大同小异，但它们之间的星数还是会有数量级上的差距的，这就是优秀、一般、一般般的直观差别。

如果要从设计或者代码上看这类项目有啥值得学习的，那可能还真没有。因为这类项目的本质其实就是干了一些脏活累活，而正是这些脏活累活很少人愿意自己干，更何况干得漂亮的了。

漂亮的 API 背后都是丑陋不堪的实现，丑陋是因为我们不想看，看不懂，发现不了它们的美。

以 Markdown 为主的文档

这类仓库在我看来大部分都是没用的：

• Awesome-xxx
• 面试宝典-xxx
• 书籍收集-xxx
• 核心、进阶、高级、架构-xxx

但无法否认的是，它们还是有价值的，至少帮助了没有信息搜索/鉴别能力、急于求成的人。

最有意思的是这类仓库甚至会让人产生一种奇特的优越感：加星就等于自己已经掌握精通，加星就等于自己已经能学以致用，加星就等于自己已经学会了独门秘籍；不加星自己就慢人一步，不加星自己就找不到工作，不加星自己就没知识走不上人生巅峰，甚至不加星自己就不是中国人（对那些“国人开源”而言）。

这类仓库中确实有价值的一般都会出书，消费市场会反映出它的优劣的。

关于指南、教程和笔记

暂时不讨论 GitHub 仓库了，说说写文章的情况。我观察到一个现象，现在有越来越多的文章作者都在“打新”，追求新技术上市后的红利。这没啥问题，因为新的市场总需要有人来推广，推广的人从中获利也是天经地义，消费者也有一定的收获。但追新技术写文章的主要问题在于内容质量堪忧：

• 既然是新技术，那作者自己必然是缺乏生产验证的，甚至有的可能直接就没用过，按照官方文档以及以往经验臆想，添油加醋一番后看上去成熟可用。读者浅尝辄止问题不大，对扩宽视野有点帮助，但绝不要认为看几篇文章就能把这个技术用于生产（即使文章中列举了一些生产案例）
• 即使是不太新的技术，作者也未必在生产上实施过，只是搭建了个开发环境随便试试。这类文章更像是《xxx 安装教程》，一般来说，读者不如参考官方的文档更准确
• 有的文章是作者的笔记，记录了实践过程中容易犯的错误，这类文章可以看成《xxx 避坑指南》，要写好有很大难度，并且受众有限

总之，对于介绍技术的内容我更倾向于直接看官方文档，需要深入一些的话就翻一下项目的 issues 列表。看第三方作者写的“入门指南”、“安装指南”、非常浪费时间。写得质量高的“技术心得”值得一读，当可惜这类文章少之又少，也难成体系，对新手云里雾里。

知识来源于书籍

综上，对于系统性知识的来源我觉得还是通过阅读出版的书籍最靠谱。我非常反对视频类教程，要从视频教程中能学到有用的知识几乎不可能，除非你是在安慰自己，并为所谓的“知识付费”献身。

好的书籍是值得反复阅读的，如果你能重复看同一个教学视频很多遍，那说明这个老师很用心，可以肯定这个视频的价值，否则不要浪费生命了，远离它们吧（茶余饭后当做看娱乐节目的话除外）。

各大平台群发

对于很多作者同时将文章发布到各个平台，本身这个行为无可厚非，为的就是宣传推广。可惜这样做有一个弊端：读者过于分散。你可能会问了，分散不是很好吗？这样能带来更多的读者！

互联网和传统出版除了效率外，很重要的一个特点就是交互性。读者的提问对作者来说非常有价值，因为作者可以通过解答读者问题来修缮文章，使文章可以更上一层楼。而读者分散带来的问题就是作者基本不可能解决所有平台上重复的提问，这需要大量的时间精力，而且重复做一样的事情就是在浪费生命。

最终，真正要做价值输出的作者都会选择独立博客，建立自己的媒体平台。那既然最终都是这条路，为什么不一开始就确定这样干呢？因为一开始没流量，没人看怎么能坚持得下去？那到底你是为了输出价值还是为了有人看？

酒香不怕巷子深，除非你不卖酒。

GitHub Star 的意义

GitHub Star 对加星的人来说，意义在于收藏，只是 GitHub 没有多度实现对已收藏仓库整理的需求，他们把这部分实现交给了开发者来做，所以有很多应用就是帮助收藏者整理加星仓库的，它们可以让你很方便的管理、搜索收藏的仓库。这也正是 GitHub 成功之处，把核心难做的事情做好，外围生态交给其他开发者，共建共赢。

而 Star 对于被加星的人来说，目前的意义在于引流。前面我们说过卖酒的问题，在 GitHub 上酒很好量化，酒好不好先看几星级，等你喝了，等你醉了，消费者也就忘记这里是卖酒还是卖肉的了。其实什么酒都差不多，喝多了一样吐，但对于卖酒的人来说，招牌却更闪亮了一些。

在 GitHub 上要客观判断一个仓库的优劣，需要从以下几个方面：

• 看仓库时间：时间越久并且近期还在活跃的比“xxx 天获得 xxx Star”好，前者至少久经考验
• 社区活跃度：无论是 issues 还是邮件列表、论坛，如果提问的人少之又少，即使 watch、star、fork 再多也不要用，因为这几个数据是结果，不是过程，制造结果比制造过程容易得多
• 代码 PR：数量、质量以及合并难度，越有价值的仓库的所有者对于 PR 合并也越“小气”，这就是仓库影响力给作者带来的压力

多年以前，我也是一个到处跪求 Star 的少年；
多年以后，我发现 Star 在一定程度上还可以变现；
最终，我成为了那个我曾经嗤之以鼻的人。

此文是对如何在 github 赚 star ? 如何在行业圈子内达到一定的小有名气？有感而发，不当之处还望各位指教。