英文博客伪原创(写一篇好的技术博客应该是怎样的自己的)

　　英文博客伪原创(写一篇好的技术博客应该是怎样的自己的)

　　在工作的过程中，我发现很多事情我都不是很了解，不是很透彻，最后很容易模糊。如果有一篇不错的技术博客可以总结一下，第一，即使忘记了，回头看还是可以从自己的思考中恢复过来的；其次，如果你总结一下，你会发现一些潜在的问题；第三，它将帮助每个人交流技术。很多大公司都有自己的内部技术博客平台，写自己的技术博客会给技术人员带来一定的成就感。

　　在网上查资料，经常可以看到一些技术博客。要么废话连篇，排版乱七八糟，要么代码占了60%的篇幅，有的甚至是错误的，都会造成误解。因此，这里总结一下一个好的技术博客应该是什么样的，同时也规范你的不良习惯。本博客纯属个人想法，是有原则的东西。不要一一接受。

　　这篇博文花了 2 个小时。

　　一、目标明确的博客

　　经常看到这种博客，为写博客而写博客。比如一篇介绍socket接口使用的博客，罗列一堆代码，拼凑几句：“第一……，第二……，最后……”，就算了。如果您的目标是“练习如何使用博客软件”或“列出界面”，甚至是“练习如何编写”，那么您可能已经实现了您的目标。但我觉得，写一篇技术博客，首先要明确博客的目的，通常是学习一个技术，解决一个技术问题什么的，比如“学习Linux内存管理机制”，“解决内核恐慌”、“打发时间”等。

　　并不是所有的东西都需要写在博客上记录下来，你必须对什么值得写什么不值得写有自己的判断。

　　二、写你自己的博客

　　网上有很多转载的帖子。一篇写得很好的博客经常被转载。建议不要轻易转载别人的帖子，而是自己写博客。对于同一个知识点或者同一个问题，你的理解很可能和别人不一样。如果你随便看了别人的博客，然后再转载，可能就意味着放弃了自学或体验的机会。. 可能有人会说：“同样的GFS架构图，我是这样画的，他也是这样画的，因为GFS就是这样设计的。” 这不是要求任何细节由你自己完成，而是要有你自己的想法。，你自己的理解，比如GFS分层的原理是什么？为什么要这样分层，分层的好处？如果我这样做了，我会怎么做？

　　写自己的博客并不意味着不转发别人的。比如我看了一篇博客，经过实验，和博客里写的完全一样，不多不少。写法基本一样，不用自己花时间写了。另外，除了纯纪实的博客，还可以转载，比如“C语言运算符优先级”，当然，不管是转载还是原创都无所谓。

　　另外，把别人的好博客当成自己的原创，不仅是失礼，也是自欺欺人。

　　如果在自己的博客中引用了别人的博客，可以在参考资料中提及。如完全转载，还应注明转载来源。

　　三、写博客是一个总结，而不是一个过程

　　博客有时可以是一个解决问题的过程。为了解决一个问题，我今天用了方法a，结果发现不行。我明天用了方法b，但是没有用。后天我用了方法c，发现行得通。那么最终的博客应该是在方法c解决问题后写的。当然，前面的方法a和b都需要记录，但是只记录博客的原创素材，而不是博客本身。

　　刚开始写博客的时候，经常会遇到这样的情况：对某项技术没有把握，想多了解一些，于是开了个技术博客，边看资料边填博客。结果基本上就是阅读、复制、粘贴、阅读、复制、粘贴的过程……。到头来，它在我手中是空的。我想起了一句谚语：“熊打破梆子——打破一个并扔掉一个。” 虽然我对为什么我的缓存这么小感到恼火，但我也想知道这是不是错误的方式？后来想了想，要想掌握一门技术和知识，大概需要这样一个过程：在实践中遇到问题——在理论中学习问题——在实践中解决问题——在理论上总结问题。我认为在很多情况下我遗漏了三个部分，只有“

　　后来，我按照以下步骤更改为写博客：

　　遇到问题，如果解决不了，但更有价值，可以先记录下来，作为博客的开始。

　　首先，首先自己分析问题，根据现有现象进行思考，将问题和可能的想法记录在笔记本上。

　　其次，从外界获取经验或知识，比如问别人、google等，向他们学习，把重点记在笔记本上。

　　然后，用学到的方法在实践中解决问题，在笔记本上做笔记，把之前记录的想法像水流过运河一样流动起来。

　　最后，我拿着笔记本，把上面的过程总结成了一篇博客。

　　当然，并不是所有的博主都能从“实践遇到问题”开始，因为很多时候都是从书本理论开始学习的（这也造成了一定的局限性，有时你学的很好，反而陷入了固有的框架；有时你学得不好，显得更无知）。在这种情况下，问题需要自己总结。比如ULK会介绍中断和异常的处理机制，包括中断的过程、CPU的工作、内核的工作、软中断的处理、tasklet等。我们学习中断，不仅Linux内核在发生中断的情况下处理什么进程，但是要找到这个原因，也就是解决问题。有时候，实际验证的成本太高，

　　当开始学习知识时，往往只看到树，而看不到森林。俗话说：“孤树不成林”，只有得到三五棵树，才会有“林”的感觉。

　　四、尽量拒绝三手技术

　　在实际的学习或工作中，如果有不懂的问题，需要向他人寻求帮助。如果你能从你身边的专家和专家那里得到一个简单直接的答案，那是最好的。如果不能，则需要自己在 Internet 上查找信息。可能有问题。你可以在互联网上找到很多。选择看哪些是一个问题。尽量选择原创材料。如果要查找 gcc 的某个编译选项的含义，可以使用 man 手册。不清楚的可以去gnu官网查一下。最好不要从随机来源转载在技术博客上获取。如果你想找到x86平台的CPU访问内存的方法，你应该从英特尔官网找到CPU信息。

　　别人的博客自然有别人的理解，这种理解可能有一定的主观性，有时甚至是错误的，你应该养成从产地购买的习惯。如果有一天你能发明一项技术，那它就是一手技术；如果你学的是成熟的技术，那么技术就是二手技术，如果你是从非产地学来的，那么很可能是“三手技术”。当然，你需要考虑实际成本，有时你找不到原创材料，所以不要太勉强自己。另外，英文文章的水平普遍高于中文文章的水平，所以你应该尽量阅读英文文章。

　　五、分清主次和落地的重点

　　世间万物都是相连的，所有与本博主题相关的问题都在本博中描述，不切实际，也没有必要。在我看来，一个技术博客应该不超过两个主题。如果超过，则应拆分。但是，可能会有很多次要问题。这些次要问题不一定要解决，但必须优先解决。与主题关系比较大的先解决，关系不大的先解决，甚至同理。本博文中未提及。未解决的问题可以在“Remaining Issues”中列出，并提供其他博客中讨论的问题的链接。

　　根据自己的能力修炼到合适的水平。我把对一个技术的掌握分为以下几个层次，博客一般应该达到第三层次：

　　听说过该技术并了解它解决了哪些问题；

　　使用过该技术并熟悉该技术的使用；

　　解构技术，熟悉技术的架构和原理；

　　通过这项技术，该技术与他们现有的知识完全结合，可以利用该技术来构建或解决其他问题。

　　六、技术博客风格

　　技术博客不是论文，技术博客具有实用性。当然，也有人在博客上发表论文。例如，大多数技术博客的作者应该是工程师，而不是学者。技术博客可以是一项小的编程技能。可以写技能的原理、实现方法、好处，但不写前500年和后300年的历史介绍和展望。技术博客通常关注技术的实用性，而不是技术背后理论的复杂性。技术博主不应该过于全面而责备文章写大而全，而应该追求小而精。

　　技术博客应该以陈述的语气呈现，个人情绪应该被过滤掉。科技并不是生活中的一切。有的人写技术博客，经常喜欢加上自己的心情，“xxx让我很烦”，“xxx很难，我已经做了两天没睡觉了”，我个人拒绝这种“呻吟”的风格。

　　和上市代码。代码是实现的过程，而不是原则。列码是看流程，不是列码。我个人的习惯是尽可能少地列出代码。如果我能用小一点的空间，我可以说明原理，永远不要使用大代码。但如果简单的代码清单一目了然，描述过程绝不会浪费太多的笔墨。

　　图片胜于文字。带文字的图片比简单的文字更容易理解。即使是图片也可以省略文字。多画少写是一个原则。

　　考虑时间成本。写博客基本上是用时间换取知识，所以需要越来越快，还要时刻把握时间。

　　列出剩余时间问题以供以后解决。