转眼间，离接手友链朋友圈（4 月 7 日）已经过了 3 个多月。从 1.16 我简单的给朋友圈加了多线程文章抓取开始，就已经掉进了这个大坑

所以这篇博客其实也是个简单的开发日志，时间，就从 4 月 7 号开始说吧

如果看到哪看不下去我流水账式的吐槽，请划到最下边，听听我为什么接下了这个项目

我写 1.16 的多线程时，友链已经停更了一个多月。对于一个 1 月份开始做并在两个月内快速迭代了 13 个版本的小项目来讲，这算是陷入了停滞

那时候冰老师忙于找工作，而贤鱼也基本改完了友链朋友圈的大体结构，做完了大部分的组件模块化（但到我写下这篇吐槽的时候，还是没有做完这件事）

而我由于在二月份就说要给友链朋友圈写多线程，结果一直咕咕咕 （老鸽子了） ，到四月份我才觉得不能再咕咕咕了，就写了多线程（然后日志就由于多线程而变得混乱不堪，一直到 2.0 版本我才解决了这件事）。这也是接锅的开始

很多时候就莫名其妙的画了个大饼，然后一直坚持做了下来 QAQ

一直到 2.0 之间的更新

决定接手了友链朋友圈之后，我第一件事是好好的看源码。众所周知，冰老师学了一周的 Python 之后就开始写了友链朋友圈这个项目并逐渐觉得 Py 很香，但写出来的代码就及其不精炼而 冗长，以及主函数的代码也是乱乱的。

我就先把友链朋友圈的主函数修改了一下，并把主题规则那三个分开的文件夹整合成了一个。这样就有了 1.17 版本的友链朋友圈（感觉在水版本

由于是刚接手这个项目，有些许的不熟悉，然后就写出了 bug。以及对 sitemap 规则的不熟悉，我也没想到 sitemap 居然是先爬链接，然后对具体页面做笼统爬取。。。笼统爬取的后果就是时间错乱等等。

所以 1.18 就修了 1.17 写出来的 bug 和冰老师一个不知道什么版本流传下来的逻辑 bug，然后自作主张的把 sitemap 策略作为优先策略（那时候以为它通用的），又写了个 bug 出来

然后就有了糖果屋群里的一些反馈，然后就咕了好久才修了这俩 bug。这个版本倒没什么好吐槽的。顺手也写了两个新的主题爬虫。

然后就是酝酿了两个小版本的 2.0 啦

2.0 更新

1.18 的 sitemap 其实起源于我的一个想法：能不能找到一个更通用的方式完成对友链文章的获取。在 sitemap 失败后我把目光转向了 rss 和 atom（在准备做 3.0 的时候惊讶的发现 rss 其实也是不行的，但 2.0 时没有意识到）

那时看起来 rss 和 atom 是具有标题和发布时间的通用规则，于是乎就在打算把这俩规则也搓了。

想着 2.0 也不能做的那么草率，就更新个通用规则显然不怎么科学。所以顺便也把乱七八糟的多线程日志修了（原本的多线程日志只有我看的懂），另外贤鱼也基本把配置从_config.yml 基本迁到 setting.py。然后就（可能不是那么草率的）更新了

但基于 sitemap 的各种局限性，2.0 最终是移除了 sitemap，也算解决了 sitemap 的各种问题吧（逃

本来在 2.0 更新之后就打算养生了，但随着用户多了，用户需求就来了

关于 3.0 的引子（还在进行阶段）

一个本来我们看起来不怎么可行的 issue

我当时给的答复是这样的（也是我看起来不可行的 issue

这边需要说明一下我们为什么选择了以发布时间作为依据：

1，许多个人博客文章不怎么习惯给文章加 updated，那么文章的更新时间则会按照 hexo g 的时间。如果友链中的小伙伴没有对他的每篇文章加上 updated 的话，它的某一次更新博客会导致友链朋友圈的爬虫把未更新的文章一样当作有更新的文章进行计算，直接占满朋友圈（即使它只是新发布或更新了一篇文章或者做了友链的更新）

2，同时在没办法保证每位小伙伴都在主页的文章处有更新时间的情况下，主页爬取规则会失效。而 sitemap 规则我们已经打算在 2.0 版本废弃，换成更通用的 atom 和 rss，虽然一样可以爬到更新时间，仍然受上一个原因影响

3，在文章没加上 date、链接不变的情况下，发布时间改变不会导致重新爬取而导致出现原因 1 的情况，只会被当作重复爬取而不被上传。

我们经过讨论觉得没办法很好的处理上述问题，因此可能不会增加此功能。如果对这个功能有自己实现的想法可以回复提出，感谢您的支持与反馈！

之后这位小伙伴提出了个貌似可行的解决方案，但是其实对于我来说却是已经排除掉的方案。我给了这个 issue 一个测试的回复（但我是真的不想做，就放着了

然后又经历了大概一周左右，我突然感觉貌似确实可以做。不过前端改 ui 后端改 api 的更新，显然比 2.0 的更新还更大很多，放到 2.1 显然是不合理的。于是我给了个设想并在前天做了新的回复，也达到了这位小伙伴的预期

所以继大改后端爬虫后，我终于是向冰老师的保留地（api 和前端 ui）发起了进攻（逃，等会下面还会吐槽这件事

一个朋友的墙裂愿望

这个功能是来自于我的一个友链朋友 @火喵给我的留言。我俩经常在他的博客下面交流，然后就讲到了这个。他希望 typecho 也可以有友链朋友圈

这给了我一个点子。我能不能把友链列表丢进配置里，这样就不一定要适配主题啦

我又在通用化的道路上更近了一步

就有了 setting.py 的新配置（这个功能已经上线了，并且可以使用，只是还没推正式版而已）

3.0 的更新点子就这么出现啦！

现在 3.0 开发的一点点吐槽

后端爬虫部分修改也不是很麻烦，主要是 api 和前端咱是真不会

前端短时间我肯定是没空学的，毕竟暑期还有校训在身，没空再学一门新语言。所以新 UI 的设计咱就交给万能的店长 @Akilar 去做啦

但前端怎么做也得看咱 api 怎么给是吧。所幸 api 看着做起来不太难，然后就去看了看冰老师的 api 输出长什么样。这不看不知道，一看吓一跳

老 api

前面的友链数据姑且看得懂，但传友链我不太理解。那，文章数据。。。我能推出来，但可读性太差了吧。

对于冰老师的 api，店长是这么评价的：

冰老师做了一堆的数据切片。

他写的 api 就是一堆数组

不是对象。

只有他自己知道那个字段是啥

我差点笑死。仔细思索我才知道。。。

你丫这玩意是在前端算的？？？这玩意不该在后端 api 算出来的吗！

我。。。算了，真的得重写，不然店长都不会写 ui 了

店长：我写 UI 的。冰老师的数据逻辑我压根不了解。

经过一番修改，新的 api 长这样（这个还没上线，因为对应的前端还没写

新 api（测试中）

看起来舒服了，而且数据也拉到了后台算

店长：这 tm 才叫 json 啊

这个 api 上线得等到店长什么时候把新 ui 写出来、我把新文档写出来了。。。

感慨（瞎哔哔）

吐槽归吐槽，不过不得不说，冰老师这个友链朋友圈的项目，才真正算勾连起了个人博客。不像是开往和十年之约，虽然是个圈子，但是随机性和没有确定的文章获取勾不起太大点击的欲望。而大部分个人博客的质量又比 csdn、博客园的博客高些（至少没那么多 Ctrl+C/V），而在国内的百度等搜索引擎竞价排名的恶臭环境下，个人博客的优质文章几乎无法精准地被搜出（关键字搜索都不优先显示就很说明问题，明明有但它就要在好几页后边才给你出来）。文章被更多人看到只能靠个人博主们自身的宣传，并在不互相点进文章的情况下很难被发现优文，友链朋友圈就提供了这样一条简便的途径（供个人博主们抱团取暖）

在我看来，至少这是一个小小的前进，让更多优文有了被发现宣传扩散的可能。

这也是我为什么坚持继续做下去，并完善友链朋友圈各个功能的理由。也在此由衷的感谢冰老师的开创之举