写文章可以帮助我们思考技术和项目的过程，从整体上总结自己的存在的优点和缺点，避免重复错误。但是博客切忌写成流水账，没有文章的结构和重点，看起来十分乏味，所以我这里总结不同博客类型的内容和博客书写应该注意点，希望在以后提高博客的可读性和逻辑性。
博客类型总结
好的博客需要明确的主题和内容，根据平常工作和学习的需要，通常将博客分成四类：A. 项目记录和总结 B.技术学习和扩展 C.问题解决方案 D.编程技巧。不同的博客类型记录要点不同。
写项目：
- 项目背景
- 自己在项目中的职责和完成度
- 使用技术和技术创新点
- 印象深刻的困难点
- 对比业界普遍的方案，整理自己方案的优势
写技术知识点：
- 自己运用知识点的总结，总结时需要注重遇到的问题和解决思路、方案
- 知识点的深入学习，注重周边知识点，最好是能和原先的知识点联系起来。
- 技术的广泛应用，学习技术需要它用在哪里，最好多了解一下技术的应用场景
写问题总结：
- 目录
- 问题描述
- 核心原因
- 解决步骤
注：如果有常见的但是错误的解决方式，可以写出以方便他人参考。 - 总结
- 参考文献
写编码技巧总结：
- 目录
- 应用场景
- 传统解决方案
- 存在问题
- 新的解决方案
- 优缺点
- 参考文献
另外，这是我看到的最有条理的debug记录格式，所以也记录在这里。
【日期】：2004-08-17【问题】：当解码 Q.931 信令时无限循环
【原因】：当在Q.931信令中发现一个未知的元素id时，我们试图通过读取它的长度来跳过它，并且将位置指针迁移几个字节。但是，在这个例子中的长度是零，导致我们反复跳过相同的元素id。
【怎么发现的】：在解码一个 Ethereal 从 Nortel 追踪到的安装信息时发现了这个问题。他们的信息是 1016 字节长度（包含大量快速启动元素），但我们的 MSG_MAX_LEN 是 1000。通常我们会收到一条来自 common/Communication.cxx 的信息，但现在，当直接输入需要解析的数据时，数组末端内存访问越界，其恰好是 0，暴露了这个问题。 为了找到它，我仅仅在 9931 解码中添加一些打印输出。但很幸运数据恰好是零。
【修复】：如果长度是零，设置为 1。这方式总是行得通。
【在哪些文件修改了】： callh/q931_msg.cxx callh/q931_msg.cxx
【我导致的】：是的
【解决Bug的时间】：1小时
【教训】：信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为 0 也同样不好。
博客的内容和格式要求
- 一篇博客至多只能包含两个主题，如果内容多于两个主题，内容过多，容易造成理解混乱，应该进行适当的拆分。
- 技术博客应该注重实用性。主要可以写该技术的原理、实现方法、好处，但不要写前500后300年的历史介绍和展望未来。博客内容应该追求小而精。
- 结构可以采取大纲-小结-总结的形式，要求逻辑清晰，内容详略得当。
- 尽量列小块代码方便读者阅读
- 可以增加插图，提高文档的可阅读性。
总结
在这篇博客中，我总结了四种博客类型书写要点和提高博客可读性的格式要求，以后写博客的过程中，要学会多多参考这次总结的内容，提高整理和总结的能力，也提高博客的阅读性。
顺便在这里列举一些不错的博客内容作为参考：
https://flashgene.com/archives/65584.html， 优点是用xmind做为提纲，每小节内容清晰，最后将所有的公式汇总，一目了然，整体理解起来非常通顺，值得学习。
参考文献：
https://www.cnblogs.com/climy/p/10787495.html
https://blog.csdn.net/fengsiyuan_88/article/details/82622192