转眼间，离接手友链朋友圈（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算出来的吗！
我。。。算了，真的得重写，不然店长都不会写ui了
店长：我写UI的。冰老师的数据逻辑我压根不了解。
经过一番修改，新的api长这样（这个还没上线，因为对应的前端还没写
看起来舒服了，而且数据也拉到了后台算
店长：这tm才叫json啊
这个api上线得等到店长什么时候把新ui写出来、我把新文档写出来了。。。
感慨（瞎哔哔）
吐槽归吐槽，不过不得不说，冰老师这个友链朋友圈的项目，才真正算勾连起了个人博客。不像是开往和十年之约，虽然是个圈子，但是随机性和没有确定的文章获取勾不起太大点击的欲望。而大部分个人博客的质量又比csdn、博客园的博客高些（至少没那么多Ctrl+C/V），而在国内的百度等搜索引擎竞价排名的恶臭环境下，个人博客的优质文章几乎无法精准地被搜出（关键字搜索都不优先显示就很说明问题，明明有但它就要在好几页后边才给你出来）。文章被更多人看到只能靠个人博主们自身的宣传，并在不互相点进文章的情况下很难被发现优文，友链朋友圈就提供了这样一条简便的途径（供个人博主们抱团取暖）
在我看来，至少这是一个小小的前进，让更多优文有了被发现宣传扩散的可能。
这也是我为什么坚持继续做下去，并完善友链朋友圈各个功能的理由。也在此由衷的感谢冰老师的开创之举