Loading... # 0x01 时间一晃,写博客竟然写了 4 年多了,文章也即将突破 100篇。甚至有点不敢相信,以为计数器出错了还手动数了一遍文章的数量。 这 4 年里博客系统、地址前前后后也弄了几次。想当初写博客的动机还是因为大学操作系统课程设计太过于无聊,出于好玩,在 [简书](https://www.jianshu.com/) 上写下了第一篇博文。后来又因为嫌弃简书太过单一主题,又追求极客精神,在 [github pages](https://pages.github.com/) 上部署了 [hexo](https://hexo.io/zh-cn/) 静态博客。结果因为老是得在本地编辑器写好再用 git 传非常麻烦,切换到了 [Armeal](https://armeal.cn/) 推荐的 [Typecho](http://typecho.org/) + [handsome](https://www.ihewro.com/archives/489/) 方案了。 # 回顾过往 回看当年的文章,真有点不忍直视。 <div class="panel panel-default box-shadow-wrap-lg goal-panel"> <div class="panel-heading"> 这 100 篇文章里分为几个阶段 </div> <div class="padder-md wrapper"> <div class="streamline b-l m-b"><div class="sl-item b- b-l"> <div class="m-l"> <div class="text-muted">2017</div> <p>转载网络上随处可见的文章、记录一些很水的技术细节</p> </div> </div><div class="sl-item b-info b-l"> <div class="m-l"> <div class="text-muted">2018</div> <p>开始准备校招,找工作了,又是记录一些非常常见的基础知识点</p> </div> </div><div class="sl-item b-dark b-l"> <div class="m-l"> <div class="text-muted">2019</div> <p>刚开始工作没多久,再次记录一些学习、读书笔记</p> </div> </div><div class="sl-item b-success b-l"> <div class="m-l"> <div class="text-muted">2020</div> <p>开始记录一些工作中碰到的坑点,但是还是没有什么干货</p> </div> </div><div class="sl-item b-black b-l"> <div class="m-l"> <div class="text-muted">2021</div> <p>真正开始花时间好好写文章了, 文章的干度和肝度有一定提升</p> </div> </div></div></div></div> 今年以前的文章都没有怎么认真对待,是以一种水文章的心态写出的充数东西,仅仅满足了自己的表现欲,没有对整个技术生态做出很好的贡献。 每当我遇到技术难题,都会更偏向于点击 Google 出来各种自建博客博主的文章,这些文章相对于 CSDN 之流一般会有更高的下线。而我也是抱着为这微弱的生态做出一点点贡献,才选择购买服务器、自建博客的,哪怕这种博客非常难被搜索引擎(特别是国内某大搜索引擎)收纳,很难被人发现、收获点击量。 然而,今年之前的文章虽然也是自己一个字一个字敲出来的,但还是觉得不太够格。有想过把之前的文章当做黑历史全部删除,却又有些舍不得,还是留着以此为鉴吧 # 着眼当下 真正开始用心写文章的契机,还是下定决心准备转 Go 裸辞离职在家的这段时间了。本来我还是个认为 Python 天下第一的 Naive Boy,直到跳槽到上家公司。这里仅谈技术,没有任何黑这家公司的意思。 上家公司是一个拥有千万级用户量、百万级日活、成立 7 年并经过 C 轮融资的互联网公司。然而这都是 **曾经** 的辉煌了。在这家公司待了不长的两个月,但也能足够的发现一些问题。 首先这家公司 7 年前,早期为了抢占市场,后端使用 Python + 单体 Web 框架一把梭,快速开发功能。然而单体框架很大一个痛点就是部署起来相当麻烦,特别是这种没有基础架构部门的纯互联网公司。前辈们为了图方便,将很多明明可以拆分的业务写在同一个 API 项目里,后辈们看到前辈们这么写,也依葫芦画瓢将就着这么写,整个后台组都疲于业务开发没有时间进行业务拆分、架构优化。到我离职的时候,路由总数已经达到恐怖的数千条。 这么一个庞大的项目,可想而知内部的逻辑是有多么错综复杂,并且由于 Python 语言本身的灵活性到这开发人员的风格各不统一,更是提高了阅读代码的难度。每当要修改老功能,都会让开发人员痛苦不已,当初我修改一个看似半天就能完成的功能时,竟然花了几天时间,将一张 A4 纸整整画满才勉强梳理清楚。而这就意味着需求开发进度极低并且产生的 bug 非常多且难以定位修复,也导致了用户大量流失,用户一流失产品们也只能策划更多的活动来挽留用户,给开发人员带来了更多的需求。最后陷入痛苦的恶性循环,环节上的每一个人都得不到好处。 所以,我认识到了,Python 确实不是一门适合开发工业级后端程序的开发语言,并且一个可维护的项目必然要业务拆分乃至采用微服务架构。而 Go 就正好是微服务热潮中的中坚力量,且本身也是一门静态语言,至少能保证团队成员代码质量的下限。 其实一年前就有断断续续的学习 Go 了,源码分析也做过一点,但是都没有输出成文章。做源码分析的习惯,也是因为当初学 Python 的时候读到了小菜老师的 《[Python 源码剖析](https://fasionchan.com/python-source/)》,认识到了源码分析真的是一件对提升技术很有帮助的方法,能够做到知其然知其所以然。 有些扯远了,说回写文章本身。其实之前一直没有多大动力写比较干货的文章,主要就是因为太费时间了。但愈发的觉得读过的文章、源码,当时还记得比较清楚,因为工作生活中很难用到,渐渐地又遗忘了,得反复的再找相关资料阅读整理。所以乘这次辞职在家时间还算比较宽裕的、正式系统的学 Go 的时候,不如把所有学到的知识整理成干货文章,既能加强记忆,又方便之后查阅,还可能让我这微不足道的小站收获一点阅读量~多棒呀。 然而,写这些文章比我想象中还要花时间,就比如前几天写的关于 interface 的文章,翻找资料、阅读源码、和朋友们讨论、询问大佬们各种问题前后将近花了一周。开始动笔时又苦于措辞,做不到大佬们用很精炼的文字讲述硬核知识的水平,一篇动辄得花六七个小时,结果还对文章不太满意。 # 展望未来 当这篇文章发布的时候,也算是写了 100 篇文章了,虽然多少有点水分,但大部分还都是自己一个字一个字敲出来的。希望这篇文章能作为一个分水岭,之后的文章希望能更加的专业,甚至能像各种大佬一样出一个 GitBook 之类的系统的书,成为一个让现在的我能仰慕的大佬。 最后修改:2021 年 08 月 04 日 11 : 12 PM © 允许规范转载 赞赏 如果觉得我的文章对你有用,请随意赞赏 赞赏作者 支付宝微信
4 条评论
大佬牛逼
牛批啊,能坚持这么久很不容易,我的都快荒废了
向大佬学习ヾ(≧∇≦*)ゝ
大佬强啊!!!