Newsletter 分享的可行性 - 附带第一期试点

背景&前言:

自己平时会浏览一些新闻资讯或者技术干货文章，会碰到很多拼凑 /转载 /『没有价值』的文章，但是同时也会遇到很多优秀的文章，就有想把这些优秀文章分享出来的想法。所以想以不定期的 Newsletter + 公众号的方式分享出来。

也有个自己的顾虑就是这个东西为自己不能带来什么，也担心自己坚持不下去，所以还一个备选方案是 github 共建的方式，然后定期整理倒 Newsletter 。

想听一下大家的意见，下面会附带第一期的试点，其中的个人观点部分这次写的较少，真正执行下来会比较多。

正文

1. 条分缕析 Raft 算法

Raft 算法常见的一种共识算法，文章没有讲述太多 Raft 算法的定义，但是描述了 Raft 算法的核心实现和设计原理。主要参考的是 YouTube 的一个视频，也可以通过视频(时长 2 小时)详细的了解下。视频地址: https://www.youtube.com/watch?v=JEpsBg0AO6o&list=PL6vmIsTqsHFSMMjU2XkNR6A442c0QMW0g

2. 中文技术文档写作风格指南

一本词典性质的文档，可以很好的解决写文档的用词和组织形式。

3. 软件架构探索

一部以“如何构筑一套可靠的分布式大型软件系统”为叙事主线的开源文档，是一幅帮助开发人员整理现代软件架构各条分支中繁多知识点的技能地图

作者周志明，就是那本《深入理解 Java 虚拟机》的作者

4. 如何编写无法维护的代码

一个玩笑且严肃的趣文，摘抄其中的几点：

在注释中撒谎

实际上你不需要主动地撒谎，只要没有及时保持注释和代码更新的一致性就可以了。

只记录显而易见的东西

往代码里掺进去类似于 /* 给 i 加 1 */ 这样的注释，但是永远不要记录包或者方法的整体设计这样的干货。

记录 How 而不是 Why

只解释一个程序功能的细节，而不是它要完成的任务是什么。这样的话，如果出现了一个 bug，修复者就搞不清这里的代码应有的功能。

最近的一个思考：什么是架构设计，架构能力可以成为工程师的护城河么？

以上就是试点的全文内容，最后的最后希望听取下大家的意见：

1. 这种形式你是否会喜欢
2. 如何能够保证长期更新，自我驱动

打个广告：如果您认为可行，欢迎关注公众号『小 Z 的航海日记』,后面会同步到这个上面+专门的 Newsletter 邮件组 + Blog 的形式。也算是对我能够持续更新的激励。