❝开头还是介绍一下群,如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, OceanBase, Sql Server等有问题,有需求都可以加群群内有各大数据库行业大咖,可以解决你的问题。加群请联系 liuaustin3 ,(共3000人左右 1 + 2 + 3 + 4 +5 + 6 + 7 + 8 +9)(1 2 3 4 5 6 7群均已爆满,开8群350+ 9群 100+)
很荣幸参与了OceanBase 社区在泛互场景的应用案例研究,并撰写了关于泛互SaaS行业对未来数据库的畅享和需求。虽在公众号和其他期刊各种文章撰写中已经获得了很多丰富的经验按每篇文字在2500百字左右,这几年我差不多一共撰写了 3,750,000字,三千七百五十万字。
然而此次撰写OceanBase 社区在泛互场景的研究白皮书中其中一篇《数据驱动下的泛互行业创新与变革,数据技术在互联网行业的新机遇》,我依然从OB的老师身上学习了不少,甚至让我有了我又重新学习了一次如何写作的感受,我总结了有这么几点。
一、打磨的精神
下图是我一开始撰写此次白皮书的开始时间和成稿时间,这里面还不包含一些在网络上的沟通后的小改动。保守估计此次的白皮书修改的版本在30个左右。写过专业文字的老师应该都明白,从第一稿到最后一稿,很可能满篇初稿已经剩不下几个字,重写,重写,再重写,推翻再重写。我从未觉得2000字是这么的难以成型,按照我目前垒字的速度,一天写出5000字不重样是不在话下的,甚至一天10000字在平和安静的情况下也是可以完成的。

区区2000字为什么那么的难,整整修改了1个月,这就要从打磨的精神来说起了。我记得初稿中,很多是以我对于泛互SaaS行业的理解撰写的,虽然在SaaS行业已经服务了4年,已经深刻领会了SaaS行业针对数据库的业务场景和客户需求,洋洋洒洒的2000字,一天就写完了初稿。
而负责此次这部分文字的温歌老师,告诉我,您的文字的风格有需要在斟酌的地方,白皮书要更专业,不应该带有个人情绪和个人主观因素。在提出建议后,我又重新审视了一遍2000字的文稿,其中大部分充斥了个人的看法,个人的觉悟,个人的畅想,是的第一稿全部作废。
直到写到了第7稿的时候,才逐渐符合白皮书的撰写风格,并逐渐领会其中文字如何表达专业性的问题,这里非常感谢温歌老师专业的点播。虽没有问,但给我感觉温歌老师的文字功底甚是了得,从每个字的意思揣摩,力争每个字都要言之有物,同时每个段落都要不带有商业倾向性,和少数个人的倾向性,文字要具有现阶段普世价值观下的普遍看法。
这个部分我学习到:
1 写白皮书要具有更平和的心态,心态不平和是无法写出白皮书这样的专业文字。
2 白皮书本身要具有更广泛的知识,虽此次的选题部分已经圈定了泛互,但在文字的落笔中,还是要考虑更多场景对于数据库本身的影响。
3 上下文要做到可以衔接,写一篇文章对我来说很简单,写一篇有导向性的文字也非难事,但写出一篇没有导向性,且包含上下文内容匹配的文字就需要更多的衔接部分的思考和相互的琢磨了。要具有更广的角度,不能单纯局限于个人的认知,要从本篇文章的立意角度出发,否则在和其他部分文字匹配的时候就会出现突兀和一脚深,一脚浅的问题。
二、 表达精准的问题
表达的精准性也是我此次和温歌老师学习到的,平时写技术文章或者观点文章都带有十分浓重的地域词汇,地域的写作手法。但在白皮书的撰写中这些都是要不得的,每个词汇必须要具有全面的精准的表达,不能有近似的意思,模糊的意思的表达,表达的意思从哪个角度都要无法推倒或误读。
举一个例子,比如我习惯使用“当前”“当下”这类词来表达某种动态趋势或阶段变化,在日常写作或公众号文章中,这是再自然不过的表达。但在白皮书中,需要更精准地指出这个阶段所指的时间范围,比如“2024年上半年”“现阶段行业普遍面临的技术演进节点”,这样才能让文字经得起时间和学术性的检验,也更适合在决策层或行业评审中被引用。当然类似的案例很多,比如爆发,和快速增长,显然快速增长在白皮书中更适合出现,而非劲爆吸引眼球的“特殊”词汇。
通过这次文章的撰写,彻底把拉升了我对文字表达准确性的问题的认识和高度的提升。
三、 协作共建的能力
基于此次的文章和研究,是多人进行的协作工作,那么这就和一个人写公众号非常的不同,试想每个人都在用自己的个性化的表达方式来去写作,就无法实现整体的白皮书的结构化,层层递进,表达统一的整体呈现,即使个人在有文字功底,而最终呈现的白皮书就无法进行上下文承接,语气和用词会和整体的风格不一致,这也是2000字被反复修改的原因之一。
在这个部分我又学习到了,专业的写作表达不等于夸张的表达,可信度建立于每一个精准化一和精雕细琢的词语。
四、 控制输出的力度,回归文字的本质
这个部分是让我感觉到最难,且让我有想放弃2000字的撰写。因为反复的改写,让我曾经一度认为我不太会写这样的专业性的文字,和在公众号撰写文章不同,我可以将脑子中的思维流用文字来直接输出。现在看来,这样的输出虽然有力,但十分的原始。
文字撰写要有结构,要对文字所阐述的场景,语境,乃至读者群有足够的了解。当一篇文字变得更加的专业和要带有高度的时候,必然每个词都要变得克制,精准,甚至让我感到了文字的本身的放大和收缩的能力。写作不再是单纯的输出,不光是堆砌观点,而是构建在行业认知和体系化后的文字输出,这些需要经得起同仁的质询和审视。
最终我完成了2000个字,在修改了30多次后。对我来说是一次彻底的写作观的刷新,也让我认识到,专业的文字是如何进行撰写的。感谢OB开源社区提供了这样一个机会和舞台,也感谢专业的温歌老师的指点和帮助。通过这次的锻炼让我有了更多文字表达手法的锤炼,体会到文字的意思精准度表达的重要性,也透过对文字严格的要求,体会到此次OB社区对于《在泛互场景的应用案例》这部分的投入和看重,感谢OB开源社区的帮助。

OceanBase 开源生态总经理 封仲淹

OceanBase 开源生态总经理 封仲淹

置顶
疯狂老DBA 和 年轻“网红” 程序员 --火星撞地球-- 谁也不是怂货
和架构师沟通那种“一坨”的系统,推荐只能是OceanBase,Why ?
跟我学OceanBase4.0 --阅读白皮书 (OB分布式优化哪里了提高了速度)
跟我学OceanBase4.0 --阅读白皮书 (4.0优化的核心点是什么)
跟我学OceanBase4.0 --阅读白皮书 (0.5-4.0的架构与之前架构特点)
跟我学OceanBase4.0 --阅读白皮书 (旧的概念害死人呀,更新知识和理念)
MongoDB 相关文章
MongoDB “升级项目” 大型连续剧(4)-- 与开发和架构沟通与扫尾
MongoDB “升级项目” 大型连续剧(3)-- 自动校对代码与注意事项
MongoDB “升级项目” 大型连续剧(2)-- 到底谁是"der"
MongoDB “升级项目” 大型连续剧(1)-- 可“生”可不升
MongoDB 大俗大雅,上来问分片真三俗 -- 4 分什么分
MongoDB 大俗大雅,高端知识讲“庸俗” --3 奇葩数据更新方法
MongoDB 大俗大雅,高端的知识讲“通俗” -- 2 嵌套和引用
MongoDB 大俗大雅,高端的知识讲“低俗” -- 1 什么叫多模
MongoDB 合作考试报销活动 贴附属,MongoDB基础知识速通
MongoDB 使用网上妙招,直接DOWN机---清理表碎片导致的灾祸 (送书活动结束)
MongoDB 2023年度纽约 MongoDB 年度大会话题 -- MongoDB 数据模式与建模
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
POLARDB 添加字段 “卡” 住---这锅Polar不背
PolarDB 版本差异分析--外人不知道的秘密(谁是绵羊,谁是怪兽)
PolarDB 答题拿-- 飞刀总的书、同款卫衣、T恤,来自杭州的Package(活动结束了)
PolarDB for MySQL 三大核心之一POLARFS 今天扒开它--- 嘛是火
PostgreSQL 无服务 Neon and Aurora 新技术下的新经济模式 (翻译)
“PostgreSQL” 高性能主从强一致读写分离,我行,你没戏!
全世界都在“搞” PostgreSQL ,从Oracle 得到一个“馊主意”开始
PostgreSQL 加索引系统OOM 怨我了--- 不怨你怨谁
PostgreSQL “我怎么就连个数据库都不会建?” --- 你还真不会!
PostgreSQL 稳定性平台 PG中文社区大会--杭州来去匆匆
PostgreSQL 分组查询可以不进行全表扫描吗?速度提高上千倍?
POSTGRESQL --Austindatabaes 历年文章整理
PostgreSQL 查询语句开发写不好是必然,不是PG的锅
MySQL相关文章





