技术分享

日迈月征，朝暮轮转。这一年里，科技开拓者们，产业同行者们用科技汇聚向上的力量步入了数智时代的 “星辰大海”。数字化是咱们发明进去的一个永恒并且充满活力的安装，数智技术正在以前所未有的速度倒退，并引发颠覆式的改革。 低提早、高通路的网络通信技术减速古代人类的“千里传音”；产业AI、泛在利用助力人类"身临其境"畅游虚拟世界；人工智能生成内容AIGC，让人工智能如同手握画笔，在一幅幅画卷上“妙笔生花”...... 京东摸索研究院联合近年来征询公司、学术界和产业界的热点钻研方向，公布了2023十大科技趋势，包含了自动化工具、产业AI、计算机通信、基础科学等畛域。 在这份报告中，咱们详细分析了十大科技趋势的要害因素，并依照其商业价值和技术栈层级，绘制了科技趋势全景图。技术的组合效应将放大并减速新的商业模式和翻新，通过颠覆现状和发明新的机会来扭转行业格局。 一、低提早、高通路的网络通信技术 低延时、高通路的网络通信技术是指可能缩小现有网络的限度及通信的提早，通过应用人工智能、边缘设施、基站上的加速器来解决运算负载，从而提供超低提早、高连贯密度和网络切片的独立网络，并促成基于互联网的生态系统的一种即时通信技术。 将来趋势： 高下轨卫星联结组网，单星与星座互补是发展趋势低延时高通路的网络通信为用户提供沉迷式娱乐、生存体验，减速XR设施在生产端的利用卫星通信与5G兼容方面的后期摸索，为6G有机交融高中低轨卫星通信与高空挪动通信倒退打下坚实基础二、下一代计算 下一代计算是以量子计算、专用集成芯片、硅基光电芯片等技术为代表的，冲破经典计算架构提供指数级算力增长的软硬件能力汇合。 将来趋势： 立法与标准化是将来五年重点科技企业更加器重量子伙伴关系的建设和坚固“量子服务”新型服务机构将会呈现神经状态计算的翻新架构办法将为倒退自主人工智能提供能源三、可信赖科技 可信赖科技旨在制订保障措施、加强隐衷计算、构建可信赖平台、治理工程危险，从而取得内外部利益相关者的信赖的零碎。 将来趋势： 新的数据分享技术无望保留隐衷的面纱，催生新的商业模式和产品数字主权将缩小网络安全/软件等畛域的信赖危险，为新的CX、EX和近程经营工作提供一个根底人工智能技术作为根底，将助力零售业，晋升供应链流程以及促成医疗行业倒退，晋升诊断效率及精度四、绿色 清洁 可继续科技 绿色、清洁、可继续科技旨在从清洁技术、人工智能和商业模式角度登程，满足对环境、可继续倒退和治理指标的需要。 将来趋势： 数字化向可继续方向变动人工智能将反对能源零碎的自动化云通信数据中心设施供应商正在减少可再生能源的耗费，并承诺实现碳中和经营。五、超自动化 超自动化是一种业务驱动的办法，用于辨认、审查和自动化尽可能多的业务流程、IT流程和算法流程等。它须要协调应用多种技术工具和平台，包含机器人流程自动化(RPA)、主动机器学习 (AutoML) 、人工智能工程化 (AI Engineering)、低代码平台等。 将来趋势： AI门槛将失去升高以及实现普及化AI工程实际一直失去欠缺，以继续的从人工智能中提取业务价值数据驱动的通用人工智能减速超自动化的实现云边一体化的协调主动优化，将扩充自动化的利用范畴六、人工智能等技术向实体畛域深度交融 随着技术能力晋升，先进科技正逐渐地利用于实体企业的设计、制作和经营工作。 将来趋势： 人-机-物共存的混合多智能体交融体系必然成为万物互联时代的新规范与实体深度交融的技术堆栈有可能扭转现有商业模式工业技术栈实体化交融、多智能体群体智能的高效扩大将促成无人驾驶、智慧城市、智慧工厂的减速落地七、指数级智能 AI大模型领有超大规模参数、巨量训练数据，通过模型的巨量化能够进步人工智能的通用属性，并升高人工智能的利用门槛。 将来趋势： 大模型倒退聚焦实现真正的多任务学习、推理与部署跨模态将海量数据积淀为海量常识，进步人工智能程度，进而进步生产力和商业价值面向决策和管制的认知智能将失去倒退，以全面实现面向视觉、语言等场景的通用感知智能八、数实融生、泛在利用 随着元宇宙（生产级体感设施、 XR设施与利用）开始衰亡，数字服务将突破虚实界线，深度交融数字经济与实体经济。 将来趋势： AR眼镜实现内容沉迷化、交互实时化与服务泛在化实时情境下的内容创作、散发、搜推能力助力售前决策、进步流量转化，重构实体零售业态设计制作、经营合作和翻新形式无望重塑，将推动实现元宇宙内容供应链九、人工智能生成内容AIGC 人工智能生成内容AIGC是继业余内容生成(PGC)和用户内容生成(UGC)后新兴的内容生产方式，具体指应用人工智能技术主动或辅助地生成或编辑文本、音频、视觉等数字内容，提供更加简略、高效、智能、业余的内容编辑、制作和发明技术与工具。 将来趋势： 多模态大模型为代表的新兴人工智能技术成为了AIGC能力降级的新引擎AIGC将不仅能够构建更加巨大的虚构数字场景，同时具备了语义了解、管制、创作能力AIGC的产品类型逐步丰盛、场景利用更多元AIGC技术不断进步将促成通用人工智能倒退十、AI for Science 基础科学减速冲破 下一代算力和人工智能的迅速倒退，使咱们可能充分利用更高维度、更多模态的数据中的信息、仿真更加简单的生、理、化过程，AI for Science就是让人工智能利用自身弱小的数据演绎和剖析能力去学习迷信法则和原理，得出模型来解决理论的科研问题，特地是辅助科学家在不同的假如条件下进行大量反复的验证和试错，从而大大减速科研摸索的过程。 将来趋势： 基础设施建设预计到2026年实现，将打造一系列工业级的2.0算法，建设与新计算状态相匹配的基础设施人工智能在基础科学畛域的广泛应用将在2030年失去实现，零碎扭转工业行业研发流程，AI for Science算法走向3.0与脑科学联合的下一代人工智能技术得以倒退，将人类迷信总结的先验常识更好地融入人工智能模型AI for Science扩大AIGC技术应用领域，加强人工智能在合成生物学、分子结构学、纳米材料畛域的预测能力2023年见证科技向善之力指引咱们一路繁花相送、过青墩。

数据是数字经济时代的基础性资源和战略性资源，也是重要的生产力。 在数字转型中，大多数企业在转型中面临的最大挑战往往都与“数据”非亲非故，比方数据的品质不高、数据孤岛重大、数据难以迁徙，原架构冗余、资源投入限度等问题，导致数据的实时性、准确性无奈失去保障，数据分析复杂度、难度较高，数据价值难以无效开掘。而 Apache Doris 作为业界最风行的实时剖析型数据库之一，自开源伊始的指标就是帮忙更多人解决数据分析的难题。截止目前已播种寰球超过 1000 家企业的认可，助力企业构建高效的数据分析平台和服务。 今天 9 点， Doris Summit 2022 正式启程！ 近 40 场精彩演讲，涵盖热门畛域、前沿技术解析！ 追随泛滥知名企业技术大咖，享受这场技术盛宴！ 还等什么？即刻扫码锁定直播间！ 残缺议程 各论坛亮点介绍： 核心技术个性全面解读！Doris Summit 2022 主论坛议程介绍商业与数据生态议题解读，Doris Summit 2022 分论坛议程介绍行业最佳实际论坛议题解读，Doris Summit 2022 分论坛议程介绍**Doris SummitDoris Summit 是 Apache Doris 社区举办的年度技术盛会，大会汇聚世界各地 Apache Doris 社区成员及实时剖析数据库畛域的专家。社区通过大会颁布最新动静及年度 Roadmap，集结国内外各大厂商分享基于 Apache Doris 的实践经验及行业将来发展趋势，更有畛域内大咖与大家在线互动交换。这是相干畛域从业者不可多得的技术盛宴，不容错过，期待您来加入！ 对于主办方SelectDB 是 Doris Summit 2022 的主办方，也是 Apache Doris 背地的商业化公司。SelectDB 致力于为 Apache Doris 社区提供一个由全职工程师、产品经理和反对工程师组成的团队，凋敝开源社区生态，打造实时剖析型数据库畛域的国内工业界规范。基于 Apache Doris 研发的新一代云原生实时数仓 SelectDB，运行于多家云上，为用户和客户提供开箱即用的能力。 ▼   点击浏览原文，获取峰会观看地址！

1、演讲题目利用RDMA减速FaaS服务 2、演讲工夫2022年11月6日上午10:30 3、演讲人李弘宇 北京邮电大学 网络与替换国家重点实验室硕士研究生 4、引言FaaS (Function as a Service)服务灵便可扩大，然而受制于隔离带来的开销。能够利用RDMA来减速FaaS服务，晋升性能，本次分享将从目前学术界的钻研（论文）登程，论述学界的最新研究进展以及能够从哪些方面进行减速。 5、内容简介云计算承载着聊天、领取、娱乐等多种需要，而FaaS 服务是云计算提供服务的新兴形式，然而FaaS服务中隔离环境的开销不容忽视，无论是启动容器的工夫，还是容器虚拟化的开销。这就导致了FaaS服务性能不佳，能够承当的业务品种受限。因而，利用新兴硬件，如RDMA，来减速FaaS服务是新的趋势，它涵盖了从启动、执行、到治理的全生命周期。 6、直播预约欢迎您预约直播，或者登陆腾讯会议观看直播： 会议号：581-8301-3525

主题：分享发表在OSDI2022的论文zIO: Accelerating IO-Intensive Applications with Transparent Zero-Copy IO 内容简介从最开始数据拷贝导致了内存和CPU的开销，限度了IO密集型利用的性能。零拷贝（zero-copy）IO是广泛谋求的长期指标，但已有的钻研次要关注缩小IO栈内拷贝次数，疏忽了利用中的内存拷贝。以Redis为例，一次SET操作经验了4（利用）+ 2（IO栈）次拷贝。zIO提供了一套用户态库，可在用户无感知且无需批改程序的状况下缩小利用中的内存拷贝次数。本次分享将介绍zIO的设计，并就开发中的内存拷贝问题做梳理和提醒。 zIO设计示意 常见利用中的内存拷贝次数 直播预约欢迎您通过微信视频号“达坦科技DatenLord”预约直播，或登陆腾讯会议观看直播：会议号：772-6477-5345https://meeting.tencent.com/d...

作为国内挪动互联网、云计算畛域的行业巨擘，阿里巴巴在大前端、云原生畛域有着丰盛的实战经验。阿里技术人从2016年开始逐渐将阿里团体外部成熟的利用中间件云化输入，并在2018年推出了挪动研发平台EMAS。 >>快来收费下载《云原生时代下的App开发》<< 现在，EMAS曾经逐步成长为横跨多端（挪动App、H5利用、小程序、Web利用等）场景的云原生利用研发平台，基于宽泛的云原生技术（Backend as a Service、Serverless、DevOps、低代码等），为企业、开发者提供一站式的利用研发治理服务，涵盖开发、测试、运维、经营等利用全生命周期。 点击收费下载《云原生时代下的App开发》 为了让大家更全面地理解EMAS产品背景、产品内容以及相应的利用案例，特此推出该电子书——《云原生时代下的App开发》走进阿里云一站式利用研发平台EMAS，心愿对宽广开发者们有所参考和帮忙。 >>精彩内容领先观看<<**EMAS产品背景： 端利用研发进入云原生时代EMAS产品全景介绍： 开发更便捷 阿里云推出一站式利用研发平台 EMAS 2.0EMAS客户案例：杭州银行：动摇投入挪动化策略，借助EMAS研发平台迈入挪动开发3.0时代 隐衷政策爱护下EMAS的产品升级： EMAS公布最新隐衷协定，为客户信息安全保驾护航EMAS旗下挪动性能测试： 云上的挪动性能测试平台EMAS旗下低代码mobi产品背景： 什么是低代码（Low-Code）？EMAS旗下serverless小程序开发： 基于小程序云Serverless开发微信小程序**

有限用户散发因群成员数量多、业务需求量大面临音讯散发量激增、音讯状态多样等多种挑战。 为了保障超级群在超大规模用户散发上的极致性能，融云超级群从设计阶段便综合思考了服务部署模型、音讯投递形式以及资源隔离等外围难题的解决方案。 本文次要分享融云超级群有限用户散发的架构设计和实施方案。 有限用户散发 面临的技术挑战 每个用户上行发送的每条音讯，都须要实时分发给所有用户。即便指标用户不在线，也须要转成推送，触达这个用户。有限用户可能过于形象，咱们以领有 1000 万用户的一个群为例，一个用户发送的每条音讯都会变成 1000 万的上行散发。在面对突发峰值，特地是群内有爆点音讯或大规模成员被带起节奏的时候，数据的存储和网络的散发压力会急剧回升。 超级群内成员可能面对海量信息。无论是客户端的性能或者用户的心力，都是有瓶颈的。成员量宏大的超级群会产生不同于一般聊天室的独特需要：用户心愿既能够在有须要的时候不脱漏信息，又能在无关的时候不要被打搅。 所以，哪些音讯、哪些场景须要推送，会话和音讯以什么频率和聚合的形式告诉到客户端，须要有一个微小的可定制空间。 也就是说，作为一个通信平台，在海量信息和实时聊天之间，须要把能力形象，并赋予 APP 弹性调整的能力。 因为超级群中的信息量太大，须要反对将群宰割为不同的频道，相似传统的 topic 或 channel。即便雷同的群和群成员，通过不同的频道，依然能将会话、音讯、未读数分门别类聚合。用户能够更关注本人感兴趣的局部，晋升用户粘性。将信息和聊天联合的场景，个别都有多端的需要。不同的平台，比方 Android、iOS、Web 等，在海量音讯的网络申请和存储方面都有不同的技术特点，甚至同平台不同厂商的推送通道个性也不同，这些都须要一一思考。当然，有限用户群，还须要为每个用户提供寰球的优质网络接入，保障客户端和服务器之间音讯不重不丢不乱序。 在这方面，融云平台每天承载亿级用户和千亿的音讯散发，曾经提供了松软的根底，毋庸特地思考。 计架构和实施方案 服务散发分层架构 融云超级群从设计阶段便综合思考了服务部署模型、音讯投递形式、以及资源隔离等外围问题。 无限的扩散模型： 主节点负责外围校验，扩散节点则负责数据读写，保障主节点高可用和扩散节点分组内高可用，确保强数据一致性 低劣的资源隔离： 反对私有云、专有云，分级的资源隔离，精准的流控策略 动静的投递模型： 依据群类型抉择音讯投递模型，多级音讯缓存构造，在线状态联动，多种音讯定向投递策略 存储和散发 对于底层存储而言，群成员无下限和有下限区别很大，有下限咱们能够依据下限进行设计。 比方，一般群的音讯，通常能够抉择写扩散，能够在实时投递中取得比拟好的速度和并发性。联合半写扩散（援用散发）的机制，能够在工夫和空间上做肯定的均衡。 然而超级群的场景，为了升高读写压力，默认采纳读扩散的形式进行优化。原则上 1 写 N 读，通过上下行节点拆散和一致性 hash 的特点，能够对读和写别离进行特定优化。针对热点数据引入内存级音讯环和二级 LRU 缓存，保障读写性能。 散发模式 面对海量音讯，用户心愿既能够在有须要的时候不脱漏信息，又能在无关的时候不要被打搅。 对这些业务状态进行剖析和实现，落到散发模型上，能够分为两大类。 一类是音讯驱动型，比方 Telegram，一个用户实时接管所有会话的音讯，会话状态、未读数、告诉揭示其实都是由音讯驱动的。 另一类是会话驱动，比方 Discord，用户有选择性地接管某些会话的音讯，关注度低的会话，仅须要接管会话状态、未读数、@ 信息等告诉就能够。和第一类联合起来，还能够做到订阅式的会话驱动。 散发机制决定了群的治理节点、会话节点、音讯散发节点都必须是独自的高可用逻辑单元。 音讯投递形式 用户不在线的状况下，超级群依然反对给用户进行推送。然而，思考到用户体验，APP 能够设置按工夫聚合，或者仅推送 @ 等关联度较高的音讯，也能够让用户自行抉择，设置全局、群组级别、频道级别的免打搅，缩小对用户的打搅。 用户在线的状况下，IM 长连贯个别有间接推送、告诉拉取、聚合告诉等形式。超级群的音讯和会话，会动静地联合这几种形式。协定层反对 QoS 并保障每条音讯都有惟一值，客户端能够通过增量工夫戳的形式，进行同步和弥补。 用户离线再上线的状况下，客户端会首先增量同步超级群会话信息，并通过会话和音讯的 merge 和音讯断档机制，同时保障音讯的疾速获取和信息的齐备性。 局部操作内化 一般群场景下，大部分的状态、未读数、正在输出等会话信息，默认交给客户端进行解决，以保障灵活性。 但在超级群场景下，因为海量的历史音讯和多端的特点，这些信息的存储和获取，须要内化在超级群的通信模型中。 针对音讯的变更，融云超级群也提供了一系列扩大和内化的能力，比方音讯发送时、发送后的扩大信息，并反对音讯的撤回、删除、批改、援用批改等操作。 而针对 APP 罕用的告诉或者管制信令的场景，融云也提供在线音讯等形式，保障在线用户的触达并升高散发量。 ...

明天，简直没人再狐疑云计算的价值和倒退空间 —— SaaS 市场空间微小，能最扼要地为客户输入商业价值，头部公司市值已破万亿；IaaS 代表了云计算的最后状态，将基础设施以“服务”的模式提供给客户，价值无可替代。 但在最近几年，最引人瞩目的其实是 PaaS 。据相干机构预测，从 2019 年到 2023 年，中国 PaaS 服务市场年复合增长率将达到 31%，PaaS 业务的支出将占整个云支出的 48.5%。 人们逐步发现，PaaS 平台的引入，是企业构建本身技术生态的要害一环。PaaS 的实质是软件模块的疾速构建和高度复用，关注定制化的平台能力，是企业实现麻利响应的基本。对于大中型企业而言，是否将业务、技术、数据合并成一个整体，并集中对生态凋谢和赋能，决定了其最终的倒退高度。 能够说，在翻新倒退达到肯定阶段，每一家企业都终将遇见 PaaS。 在明天，企业级 PaaS 平台也迎来了其新的倒退挑战和时机，大部分人只晓得与云原生、中台无关，却不甚具体。为了更好地解读当下企业级 PaaS 平台的技术倒退，咱们访问了用友，具体理解了用友 iuap 的技术演进和布局。iuap 是用友商业翻新平台 YonBIP 的 PaaS 云平台，也是 用友 BIP 松软的技术底座，为用友及平台生态提供开发、集成、监控、服务治理等 PaaS 服务。 用友 iuap 的倒退历程，也是国内企业服务软件技术改革的一个缩影。 1.iuap 倒退历程与外围架构 用友从 2006 年着手平台产品研发、积淀技术能力，倒退至今，用友 iuap 服务过上万家大型客户，研发老本投入超百亿。 2006 年，在《2006-2020 国家信息化倒退策略》的政策激励下，国内企业纷纷投入到信息化建设的大潮中，为了可能帮忙企业更疾速地建设信息化，用友基于应用软件，积淀平台能力，为 iuap 的呈现奠定了根底。 2010 年，在通过一段时间的技术积淀之后，用友 iuap 正式进入企业级 ERP 市场，满足企业定制开发、系统集成的需要。 2014 年，iuap 开始引入云原生技术，同时实现了从单体利用到分布式服务架构的降级，从单体利用中抽取出了要害的技术服务能力进行组件化封装，例如分布式缓存、分布式锁、打印、工作流等，更加灵便地服务于企业。 2015 年，随着企业一直上云，iuap 实现了云原生技术的重构，成为国内企业服务畛域首款齐全云原生的平台，并同时在平台之上搭载了 SaaS 服务，例如纯云原生的友云采、友报账等。 2018 年，企业对于云计算的认知逐步深刻，单纯的私有云服务不能满足所有需要，混合云成为了新趋势。因而，iuap 再次降级了架构，采纳混合云架构，全方位买通了云上云下用户、根底档案、认证、性能等，并推出了中台架构。 ...

一、前言挪动互联网时代，网页仍旧是内容展现的重要媒介，这离不开 WebKit 浏览内核技术的反对与倒退。在 iOS 平台下开发者们须要通过 WKWebView 框架来与 WebKit 打交道。尽管苹果官网提供了对于 WKWebView 的 API 与应用阐明，但这并不能满足开发者们的需要，各类简单场景仍旧让咱们焦头烂额，而解决方案却不易寻找。此时，优良的开发者们将眼光移向苹果开源的 WebKit 内核代码，试图从中寻找解惑之道，却发现仍旧困难重重，崎岖一直，次要问题如下： 内核源码简单难懂：动辄几个 G 的源码，且不足要害代码正文与阐明，跟踪剖析工作量大；零碎兼容分支较多，一块代码可能辨别 iOS、Mac、嵌入式等分支；历史代码或试验性能较多，导致查看源码并不容易缕清逻辑。无奈联合业务代码剖析：异样问题往往在简单场景下才会呈现，不足业务代码的联合，问题无奈复现，咱们也就无奈定位问题，最终容易走上猜想起因、更换计划尝试修复的路子。无论你是出于趣味还是以上起因，想要摸索 WebKit 源码而不得其法，本文都将帮忙你疾速入门。接下来，咱们将依照源码下载、源码编译、创立调试工程、源码实战剖析的步骤助力你深刻浏览内核摸索之路。二、源码下载编译及调试之前咱们首先须要获取一份苹果官网的 WebKit 源码。 github下载 (举荐)： https://github.com/WebKit/WebKit官网下载：https://WebKit.org/下载后的 WebKit 工程通过 Xcode（ Xcode 是苹果官网举荐的 iOS 利用开发工具）关上后目录如下图。WebKit工程目录其中gtest / MiniBrowser / MobblieMiniBrowser / TestWebKitAPI / WebKitTestRunner仓库为测试仓库。思考到编译效率的问题，通常状况下不须要编译测试仓库。因为本文前面将形容如何无效利用这些测试仓库，咱们此处抉择进行全源码编译。 三、源码编译获取到源码后，接下来咱们介绍下命令行及 Xcode 的编译形式。本文举荐先应用命令行编译一遍，再用 Xcode 编译。从实际来看，如果编译过程中出错，命令行编译形式更易追踪到具体异样信息。1) Embedded Builds下载的 WebKit 目录外面有一个Tools/Scripts 目录，这外面有各种脚本，包含应用命令行编译 WebKit 的脚本，其中一个重要的脚本就是 configure-Xcode-for-embedded-development，在 Mac 终端控制台运行如下命令:sudo Tools/Scripts/configure-Xcode-for-embedded-development之所以须要执行这个脚本，是因为 iOS 属于嵌入式平台，编译嵌入式平台的 WebKit 须要用到一些命令行工具，Xcode 正是利用该脚本构建这些命令行工具。否则，在编译诸如 JavaScriptCore 等工程的时候，就会报如下谬误：‘com.apple.product-type.tool’, but there’s no such product type for the embedded platform，找不到对应的架构。 ...

前些日子我给 Santd 的 Tree 组件减少了虚构树的性能，用于解决 Tree 组件在渲染海量数据时的性能问题。 虚构树这个货色，大家当前在前端业务中可能有机会用到，即便没有间接用到，理解一下虚构树兴许也能给大家提供一点解决问题的新思路。 Santd 是 Ant Design 的 San 实现，服务于企业级中后盾产品。0 目录1 什么是虚构树？ 2 为什么要用虚构树？ 3 怎么实现虚构树？ 4 最终成果 5 参考资料 1 什么是虚构树？可能有的读者还晓得一个概念，叫 “虚构列表”。 虚构树和虚构列表实质其实是一样的，只不过前者的原始数据的构造是树，而后者的原始数据的构造是列表，以及最初的表现形式不一样。 不论是虚构树还是虚构列表，外围原理都是只渲染可视区域内的数据，也就是说，用户看不到的数据就不渲染了，这也是之所以称之为 “虚构” 的起因。 一言以蔽之，虚构树就是只渲染可视区域的数据的树。 2 为什么要用虚构树？因为渲染耗时。 如果一棵树含有海量数据，比方上万条，那么，这棵树的渲染耗时会很长。 咱们能够通过一个理论的例子直观感触下。 上面的代码是应用 Santd 的一般树组件创立一个有 11110 个节点的树，代码的具体细节咱们不须要关注，咱们只须要晓得它创立了一个有一万多个节点的树并打印出了树的渲染工夫就能够了。 <template> <s-tree treeData="{{treeData}}" defaultExpandAll="{{true}}"></s-tree></template><script>import {Tree} from 'santd';function dig(path = '0', level = 3) { const list = []; for (let i = 0; i < 10; i += 1) { const key = `${path}-${i}`; const treeNode = { title: key, key, }; if (level > 0) { treeNode.children = dig(key, level - 1); } list.push(treeNode); } return list;}const start = Date.now();const treeData = dig();setTimeout(() => { console.log(`渲染耗时：${(Date.now() - start) / 1000} 秒`);}, 0);export default { components: { 's-tree': Tree }, initData() { return { treeData } }}</script>而后，咱们就能够看到，这个 11110 个节点的树在我的 2019 款的 MacBook Pro 的 Chrome 里渲染了 26 秒，将近半分钟。 ...

简介：本文探讨了如何让技术一号位可能从实践上、以宏观的视角看清日常工作非亲非故的事物的倒退法则，从而为适应法则办事或者创造条件突破法则提供理论依据。 往期技术一号位方法论系列文章： 「技术人生」第1篇：什么是技术一号位？「技术人生」第2篇：学会剖析事物的实质「技术人生」第3篇：解决问题的法则总结 本期文章篇幅较长，倡议珍藏浏览。 背景本期文章将接上期《「技术人生」第3篇：解决问题的法则总结》持续探讨技术、业务、组织的个别法则及应答策略。须要留神的是，以下内容为集体实际后果的总结和剖析，受限于集体能力和教训无限，在形容法则的过程中，可能会存在维度的缺失；或者以后形容的法则所波及的维度并不是某些读者认知中的重点，因为事物不同的维度在不同角色和级别的人的认知中重要水平不同，即：PD和研发对于同一件事件的侧重点不同；P6到P11对于同一件事件，很大概率看重的侧重点不同，咱们特地欢送不同档次的同学分享你眼中的法则进去指引其他人实际。 而对于明天本文接下来要探讨的内容，须要大家辩证地去对待，并且在探讨初始须要从新对齐以后事物的探讨范畴：以后对组织、业务和技术的法则的探讨，限定在“技术团队leader率领研发团队负责某个业务或负责某个业务的一部分”的状况下，“技术”一词指代研发人员应用的信息化技术；“业务”一词指代研发人员应用信息化技术解决的问题域的统称，“组织”一词指代技术团队 Leader 率领的团队（可能是跨团队的组织）。 同时依然须要留神的是： 上述范畴中提到的组织、技术、业务没有加上“规模”相干的限度，能够了解为，任何规模都合乎上面探讨的法则，即咱们探讨的是个别法则。同时，不同规模，即团队规模、业务规模、技术深度实质上都是非凡条件，非凡条件的存在可能会触发非凡的法则，然而还是那句话，非凡法则存在并不影响对个别法则的探讨。并且受限于自己以后理论的实际状况，不同规模所触发的非凡法则并没有全副都直观感触过（实际缺失），也没有看过相似的书籍（实践输出缺失），所以不在本文内进行相干非凡法则的探讨。不排除将来有了更多的实际会来欠缺，同时更欢送有实践经验的人整顿总结成法则分享进去。 上述范畴中提到的剖析问题的主体是技术 leader，所以对于其余角色类型的同学而言，探讨之后造成的论断须要辩证地去了解，可能有很大部分都是相通的（留神不是雷同，而是相通，象征能够互相借鉴），然而同时也有一部分是不实用的，是和探讨的主体自身的特殊性相干的。而这种特殊性对于其余类型的角色并非没有意义，恰恰相反，这可能是比拟宏观地、间接地理解另外一种角色的十分无效的路径。即经营一号位或产品一号位或业务一号位能够看到技术一号位所负责的事件中的个别法则和非凡法则，而个别法则大概率相通，而理解非凡法则是了解彼此差异性的在宏观层面的认知。 业务的倒退法则及应答策略业务的倒退法则业务的生命周期如下图所示：看图时，须要留神以下内容： 图中的曲线仅用于定性分析，非定量分析的准确图表，因而生命周期中各阶段的长度、和业务规模、利润规模的比例关系也都是示意型的，而非准确的比例关系。不同的业务，生命周期长短可能不同，各阶段继续的工夫也不同，业务方冀望各阶段持续时间长短也不同，须要具体问题具体分析。不同的业务，利润呈现的工夫和业务生命周期的阶段对应关系不同，利润规模和生命周期各阶段对应关系也不同，须要具体问题具体分析。 在此基础上，咱们简略用语言讲清楚业务倒退过程是怎么的： 启动期启动期能够粗略分为立项期和验证期。 立项期个别都是业务侧如PD或者经营发动，要做很多事件，例如围绕业务产生的价值是什么、指标客户是哪些、如何交付给客户、如何收取对应的费用继而维持业务运行上来，这个过程往往还须要联合大环境的要求补充更多细节，即以后事物的主要矛盾次要矛盾的剖析解决要合乎大环境的主次矛盾，即以后事物倒退法则遵循于事物所属大环境的倒退法则，因而须要联合组织策略、组织价值、业务所属大业务的战略目标等一系列大环境的要求来实现立项信息的筹备。 如果持续探讨，就会波及到这个探讨事物的实质剖析，咱们前面有精力的状况下会新开文章去剖析，本篇内容不再开展。这个阶段的次要作用就是通过正当的业务模式设计拉通各方对新业务的认知，获取组织的反对。优良的技术一号位会在这个阶段就染指进来，为业务发起者，通常是业务一号位，提供必须的技术视角的剖析和反对。验证期个别是在立项通过后。次要是通过疾速的产品原型的实现，证实业务模式是行得通的，证实业务或产品是能解决客户问题，并且指标客户群体的客户代表是违心为这种产品付费的。这个阶段个别会投入大量的研发人员来做对应的信息系统来撑持业务的运行。研发团队个别从这个阶段开始做深度染指，并且相较其余角色的团队而言，研发团队在该阶段是配角。 发展期当启动期内实现了价值证实之后，接下来的重点就是如何将单个客户验证的业务模式疾速地规模化复制到更多的客户场景中，从而可能让业务在肯定工夫内实现业务规模的暴发。研发团队在这个阶段会次要解决零碎齐备性的问题，因为波及到越多的客户，新的共性的场景就会越多，为了承接规模化的用户而须要补充对应的业务场景的撑持。这些补充的业务场景，往往是技术系统核心畛域的补充以及撑持。 同时，这个阶段的配角不再是研发团队，意味着研发团队的体现逐渐从次要口头方逐渐转变到幕后成为根底参与方，而其余团队如经营、PD、销售、客服等团队会独特入场互相协同形成以后阶段的配角。所以研发团队除了反对客户自身的业务需要外，还承当着业务上下游合作角色的需要的信息化工作，这一点往往是老手技术一号位可能会漠视的点。 平台期当业务通过规模化复制推广造成肯定规模当前，增长会逐渐受限于指标客户群体规模，规模增长达到下限，逐渐趋于平缓，同时利润曲线也应该在此阶段之前转正并且在以后阶段达到最大。这个阶段谋求的不再是规模化增长，而是开始持续谋求利润的最大化，降本提效往往变成该阶段的主旋律，而很多业务环节和参与方也往往会在“降本”提出当前，呈现较多的矛盾，呈现较多的问题，实质上是之前的几个业务阶段中留下的隐患，即：为了达到业务指标而采纳了看似过后荒诞不经然而实际上对整体无害的形式。 这个问题看似是短期利益和长期利益的抵触，然而对于技术一号位而言，须要寻找既能满足长期利益又能兼顾短期利益的计划，并且肯定是以长期利益为宗旨的，作为次要做事准则的，而不能反过来。其余的业务参与方应该放弃同样的认知，并以之作为实际行动准则。 业务进入平台期之后，随着整个业务进入成熟周期，很多流程逐步完善，组织撑持逐步形成体系，这套配套的组织和流程能让业务持续安稳地倒退上来，并且尽可能维持成熟期的长度，然而同样也会带来新的问题，即组织僵化后，业务对市场、客户的变动的感知敏感度降落；针对客户、市场变动的决策被提早或者阻滞；最终后果就是业务当初产生的价值不再可能满足目标群体的要求，如果不做任何调整和干涉的话，业务进入衰退期是必然的。这个阶段，业务和技术都不是破局的要害，而是组织自身。 衰退期业务进入衰退期没啥好说的，技术团队须要思考的一个问题就是，业务经验残缺的生命周期而做没了是自然规律，那么对应的技术是否也须要随着业务的沦亡而沦亡？如果技术和业务耦合度太高，那么业务沦亡天然会株连技术，而导致后续新的业务无奈利用起来。所以不管从哪个方面思考，都须要在技术设计和实现过程中，将技术体系进行系统性的、结构性的分层，底层的通用技术和通用的业务服务自身要做到业务无关，而业务相干的局部要构建成通用的业务畛域，确保业务变动当前，畛域依然是可用的，因为业务畛域自身是业务内核的反馈，只对业务实质相干的事件负责；而最上层的和产品展现层相干的内容都束缚到最上层的业务利用中，业务利用中对产品的展现和交互负责，对场景化的技术需要负责。 沦亡期如果业务进入沦亡期没啥好说的，及时转身止损，投入正当的资源善后即可。 各阶段的主要矛盾次要矛盾剖析在整个业务发展过程中，不同阶段的主要矛盾不同，不同的矛盾须要用不同的形式解决。咱们这里只探讨最根本的状况，为的是寻找法则。在理论业务的发展过程中，很可能业务属于某个阶段，然而在其余条件的作用下，主要矛盾产生了变动，这一点并不意味着咱们明天探讨的内容没有意义，因为矛盾的普遍性和矛盾的特殊性自身都是客观存在的，不能因为特殊性而漠视普遍性，当然也不能因为理解了普遍性，就不再关注特殊性。 • 启动期：前半段有无是主要矛盾，业务价值证实是次要矛盾；后半段业务的价值证实是主要矛盾（业务是否可行），业务规模化倒退、大规模获取收益是次要矛盾。• 发展期：业务规模化复制从而高效发明商业价值是主要矛盾，业务老本管制和价值变现效率是次要矛盾。• 平台期：业务老本和价值变现效率是主要矛盾，其余问题是次要矛盾（组织等）。• 衰退期&沦亡期：业务进入平台期，如果不可能基于过来的业务求变求新适应新的市场环境，则业务很快会衰败，则业务的可继续倒退就成了业务的主要矛盾。 各阶段的应答策略及如何突破法则3.1 从总体上看如何突破法则业务生命周期的各阶段并不是肯定必须要串行的，也不是有明确的界线的，所以对于某些业务，能够多阶段并行推开。 比方业务一号位能够从一开始就基于过来的业务教训和组织教训提供业务保障的流程和标准，在业务进入平台期之前即具备相干的组织保障能力；技术一号位能够在开始即构建良好的架构设计，关注业务特色，理解业务特色对技术架构的影响，也理解不同业务阶段对技术架构的影响，从而在起步阶段即实现整体设计，从而让架构设计具备前瞻性，同时基于理论状况逐步推进架构向终态的演进。简而言之，就是：既然晓得了前面哪些事件必须要干，那么在最开始的时候在解决主要矛盾的时候就棘手逐渐干掉，而不是非要重复地踏入业务倒逼技术架构扭转的圈子外面。 在生产力无限的状况下，能够减速某些阶段，压缩这些阶段继续的工夫，然而永远要晓得它是无奈跳过的。 作为业务一号位或者技术一号位，要晓得在不把握更高的生产力的状况下，业务每个生命周期都是不可跳过的，主观能动性不能让某个阶段凭空隐没，加人进来也不能让某个阶段凭空隐没，都只能是用资源老本来换工夫。要么就是压缩那些投入期的环节；要么就是缩短那些回报期的环节，然而无论如何不能扭转这些环节本来的生命周期。 所以当决策者发现主观能动性和砸人进去都不好使，都不能达到你想要的成果的时候，很大可能不是团队执行力不够强，而是做执行的人生产力不够高，至于为什么生产力不够高，是受到了生产关系的制约，还是自身在生产力方面的投入有余所以积攒无限，那就要具体问题具体分析了。 当然还有一种可能，就是决策者本人不晓得本人做的事件的客观规律是什么，主观认知上达不到这个高度，所以只能出于集体志愿和设想来提出不切实际、不符合规律的要求。当然，辩证地去看，即使是这种最极其的状况呈现了，也最终还是因为生产力不够先进，如果足够先进了，再夸大的要求、再不切实际的要求其实都能实现。 在生产力很先进的状况下，能够跳过某些阶段，或者连续某些阶段的持续时间，然而要关注高生产力带来的老本问题。 在生产力进步到肯定水平的时候，业务生命周期内的某些环节能够借助生产力跳过，而这种跳过并不是这个环节凭空隐没了，而是曾经被高级的生产力做掉了。例如能够利用成熟的中间件服务来解决分布式系统中的各种问题，而不须要反复从新做一遍。先进的生产力自身造成也是有其自有的生命周期和阶段的，在初步呈现阶段，先进生产力带来的各种老本必定是高的，甚至会高到无奈大规模推广，而随着先进生产力自身一直倒退，随着周围环境对先进生产力的适配，先进生产力的应用老本逐渐降落到正当的范畴内。因而在决定应用先进生产力影响业务生命周期的某些阶段的时候，须要关注投入的老本。 随着生产力的晋升，生命周期的每个阶段仍然能够持续细分为多个阶段，并且生产力越高，参加业务的各方能够管制和干涉的业务生命周期的粒度就会越细，能够管制的维度也越多。 如何了解这句话呢？首先要明确到底什么是生产力。生产力不是单纯地指技术人员把握的技术，而是以 “劳动者”——就是指人、“劳动资料”——就是指人应用的工具、“劳动对象”——就是指被人应用工具扭转的对象为因素，形成的概念。 所以生产力的晋升蕴含了人的晋升、人应用的工具（对于研发同学而言就是技术，对于PD或经营同学而言就是你们的工作方法论）的晋升。所以当人变得更强、工具变得更先进当前，能够革新的对象的粒度就越小，能够革新的对象的维度也就越多。 这是普世的个别法则，想想物理上化学上随着生产力的晋升人类能够革新的对象的维度和粒度是如何演变的。而这个法则在业务上的体现就是技术能力更强、PD经营方法论更先进更适宜业务的团队，可能感知并管制业务的更多的维度，业务的倒退周期也会拆解地更细。这一点其实是最和咱们日常工作最为非亲非故的一个法则。 咱们能够利用这个法则来针对“生产力不够先进的业务”构建构造上的劣势，例如在业务的“启动期”，生产力落后的一方在解决零碎有无问题时，而生产力先进的一方曾经同时在着手解决塑造品牌形象等问题。 这些问题看起来不是主要矛盾甚至都算不上次要矛盾的维度的事件，之所以在同样的业务倒退阶段，两种团队解决的问题齐全不一样，起因就是在于生产力的差别，即：落后的一方在以后阶段解决骨干问题时，先进的一方曾经解决了主要矛盾并实现了多轮“由主到次”的解决过程，而每一轮“由主到次”的过程，都是拓宽问题维度、拆分问题粒度的过程。这种劣势是结构性的，比工夫上发力更早而造成的后手劣势更高级，也更难被追上。同样的，这个法则也会在技术上同样起到作用，上面在探讨技术的个别法则的时候，会提到这个法则的具体体现。 3.2 从具体的倒退阶段上看整体应答策略• 启动期：尽可能利用现有积攒或与三方单干减速或跳过启动期。• 发展期：具体问题具体分析，与非凡法则无关。• 平台期：做好孵化新业务的技术筹备和业务筹备，防止业务进入衰退期当前组织随着业务沦亡而价值升高。• 沦亡期：利用转型或孵化新业务形成第二业务曲线，从而在宏观上看到以后组织的业务规模没有产生消退。 4 从整个业务倒退的法则来看，技术一号位须要具备哪些能力从业务倒退法则来看，技术一号位的能力大多数和做业务相干，同时和宏观的技术架构及落地把控能力相干，具体如下： • 剖析业务实质的能力，即能看清业务外部主要矛盾次要矛盾，能依据业务外部和外部环境的互相关联和相互影响来判断业务将来的发展趋势。• 剖析业务各参与方的外围利益诉求，可能正当利用商业模式尽可能多的均衡各方利益诉求，并从技术零碎上针对这种业务模式给与反对。• 剖析业务各参与方的外围利益诉求，可能应用指标别离体现各方的外围利益诉求，并且可能以体系化的维度将指标拆解，防止看问题的片面化；同时可能分阶段理清不同阶段的重点指标并在技术支持上予以歪斜，防止看问题动态化。• 在业务初期，可能联合业务的问题域，实现正当的业务领域建模；并且联合市场调研及业务发展趋势，正当设计零碎架构，体现出架构的前瞻性和扩展性。同时要开始做技术生产力上的长线投入，借短期业务需要落地长期技术布局。• 在业务中期，逐步完善业务撑持维度，全方位构建支撑体系。将支撑体系解决方案化，并且将业务撑持解决方案跨业务复用。同时利用业务初期投入的生产力的晋升，来推动业务倒退。• 在业务末期，可能实现技术侧的积淀，并且有能力孵化出新的技术产品。 技术的演进法则及对应的应答策略对于技术一号位而言，技术畛域是本职畛域，探讨技术畛域的法则时，要充沛联合组织、业务对技术的影响来谈。因为组织特色、业务特色独特决定了技术特色。在咱们开始谈个别法则时，先把“技术”这两个字讲清楚，不是要讲概念，而是要讲这两个字在不同语境下的侧重点，而后别离从不同的视角来探讨他们具备的法则。 咱们常见的研发过程分类来看，一种是业务研发过程，一种是技术研发过程。两者在某个层面恪守同样的个别法则，同时也因为各自受生产对象的不同而别离有“各自的个别法则”。留神，这里讲“各自个别法则”是指探讨范畴别离限定在各自的话题之内，而在更大的技术范畴上看，它们则是非凡法则。 为了能清晰地讲清楚业务研发过程中的技术和技术研发过程中的技术到底有什么个别法则，咱们先明确二者之间的辩证关系，对立大家的认知，为前面的探讨扫清阻碍。 从实质上讲，所有的研发过程都是业务研发过程，技术研发过程只是业务研发过程的一种非凡状况。业务研发过程服务的对象，是客户的业务人员，要解决的问题域集中在宽泛的客户业务畛域上；技术研发过程服务的对象，是客户的技术人员（请辩证地、狭义地了解客户，不要狭窄的了解客户二字），要解决的问题域集中在狭窄的技术畛域内。即：业务研发过程的内核是业务问题，技术研发过程的内核是技术问题，而技术问题是一种非凡的业务问题。 业务研发中的技术解决的对象是个别的客户业务需要；技术研发中的技术解决的对象是非凡的技术需要。技术研发过程中的技术的特殊性在于需要不是间接来源于客户在业务发展过程遇到的业务问题，而是来源于客户在业务发展过程中遇到的非凡畛域的、业余的技术问题。 技术研发过程中的技术的一般性在于不论需要从哪来，需要类型是什么，需要有什么特色，都属于狭义的业务需要，因而技术研发畛域中的技术也同样恪守业务开发畛域中的技术所恪守的个别法则。 业务研发过程和技术研发过程在肯定的条件下和非凡的阶段是会互相转换的：业务研发过程一直由主到次地解决问题，最终问题的畛域会聚焦在繁多技术问题上，变成技术研发过程；而技术研发过程一直由主到次地解决问题，最终会在进行对外价值传递时变成业务研发过程。所以业务研发过程的次要问题是对外传递业务价值，主要问题是技术在某些畛域的先进性；而技术研发过程恰恰相反，其次要问题是在以后技术畛域的先进性，其次才是自身价值的对外传递，因为其价值自身是基于它本身的先进性的。这就是业务研发和技术研发的对立统一的过程，互相演变的过程。 ...

简介： 最近我发现一些同学的分享越来越趋于“念稿”式。我一边看着分享的同学在下面念稿，另一边看着几十号人在上面看电脑看手机，我心里就特地焦急。巴不得我本人下来讲，也巴不得没收了大家的电脑手机。但这种粗犷的办法必定是不解决问题的，外围问题还是大家不长于分享。那么到底应该怎么分享呢？ 最近我发现一些同学的分享越来越趋于“念稿”式。我一边看着分享的同学在下面念稿，另一边看着几十号人在上面看电脑看手机，我心里就特地焦急。巴不得我本人下来讲，也巴不得没收了大家的电脑手机。但这种粗犷的办法必定是不解决问题的，外围问题还是大家不长于分享。 我自认为本人过往的分享都还是中等偏上的，因而总结一下，讲讲如何做场高质量分享，心愿可能给将来要做分享的同学提供一些帮忙。 一 为什么要分享每个人在分享前都应该先问本人这么一个问题，我为什么要分享？我感觉分享就一个最纯正的起因，就是“我有一些常识，是他人不晓得的，但对别人会有所帮忙，所以我想分享给大家”。 换言之，分享的本意就是总结并流传常识，分享的外围是利他。 而现实情况呢？ 做了一些技术产品，想推广给大家，所以要分享。为了体现本人有团队奉献，想要好绩效，所以要分享。就是想show一下本人，让他人感觉我厉害，所以要分享。是不是有些变味呢？其实我也并不否定这些起因，咱们如果能分享的好，这些也都是自然而然的后果。这就类比咱们退出蚂蚁最外围还是想要疾速成长，而好绩效是疾速成长的后果。但谁不想要好绩效呢？ 但咱们不能为了这些后果而疏忽了初心。分享的初心是心愿大家互相分享常识，相互成长。我感觉也只有真的能对他人有帮忙的分享能力称之为“高质量分享”。 所以，如果你在筹备分享，请你再质问一下本人，你到底是为什么要分享？只有本人初心摆正了，在做分享的筹备的时候，才会真正的去想：怎么能力把这个分享做好，怎么能力让分享生动有趣，怎么能力让分享干货满满，怎么能力更好传播本人的常识。否则，你认为本人分享了就是获得后果了，其实你什么也没失去，还节约了他人的工夫。 二 什么是好的内容好，置信看到此处的同学都是违心利他的同学了。那新的问题又来了，我须要分享什么呢？什么样的内容能力撑持所谓的高质量分享，我了解是如下三种。 1 高度总结的常识有些常识也不是多难把握，而是把握的过程可能须要破费大量的工夫去到处收集信息。过程中可能又会衍生出很多问题，须要本人破案一样的去钻研。比方很早时我写的一篇《你的Tree-Shaking并没什么用》[1]。为了钻研 tree-shaking 为什么实在场景下优化无限，钻研了 babel、uglyfy、webpack、rollup，甚至去翻一堆 issue，最终花了我数蠢才窥见原由。 其他人如果也想理解这外面的起因，也须要破费数天的话，未免太折腾了。因而我把钻研的过程总结成了文章并发表，同时在团队内做了一次分享。一方面流传了常识，另一方面如果他人真的想再认真钻研，至多能够节约一些工夫。 相似的还有一些新技术推出时，业界文档较少，大家学习老本较高，本人系统性学习当前做一些总结并在团队内做系统性的分享。比方React16刚推出时，我师兄芃程在团队内分享了16的新个性： 2 能够借鉴的教训还有一些偏经验性的内容。可能是非技术性的教训，比方成长教训、人生感悟或集体思考。最典型如降职总结、治理教训分享等等。比方咱们部门曾邀请过的一些分享： 兼续同学的《聊一聊平台技术前端如何成长》依鹭同学的《业务中台 - 合作伙伴提效》我感觉他们的分享都十分的好。比方兼续提的“微习惯”，依鹭提的“不要用战术上的怠惰覆盖策略上的懈怠”等等都给我留下了十分深的印象。 也有可能是技术上的教训，比方某类技术产品的建设教训、推导的过程等。比方2020年前端D2大会上的： 辰啸的《前端故障演练的摸索与实际》当轩的《跨端的另一种思路》霸剑的《SSR 在双十一会场的落地实战》外围就是：把本人的长期教训做一些零碎总结，以本人的故事或技术专项作为案例撑持，摆事实讲道理，给其余有类似诉求的人一些“长者”教训。 3 艰涩难懂的技术还有一些是十分难了解的常识，这种往往是非本人业余畛域的常识、或上手老本特地高的技术点、亦或是某些浅近的源码解析之类。如果咱们的分享能把这些艰涩难懂的技术讲的十分深入浅出，易于了解与排汇，那也是十分优质的分享。比方部门邀请过的邦祝老师的《Challenges for On-device System Design and Innovative Algorithms》（连题目都看不懂了）。还记得过后邦祝老师讲卷积神经网络时，板书做的很好，挺容易让大家了解。 不过这类分享在蚂蚁我见的比拟少，也很少看见讲的十分很好的。不过网上有一些，比方：李永乐老师的很多迷信、数学相干科普视频。 那是不是咱们分享的内容属于高度总结的常识、能够借鉴的教训、艰涩难懂的技术就代表着是一场好分享呢？必定不是的。内容虽有用，也要观众听。能被观众听进去的内容，能力称之好内容。所以如何把咱们的内容给分享好才是最要害的。 我认为，想分享好内容，首先是要组织好内容，而后是要找到好的形式去展现它，最初是有肯定的技巧去表白它。 三 如何去组织内容1 结构性很多人都听过《金字塔原理》，这是一本解说写作逻辑与思维逻辑的读物。其实我也没看过，但我晓得它的最中心思想，就是“总-分-总”。总分总置信大家都晓得，一个主观点，N个子观点，每个子观点可能还有子观点。讲每个观点都是论断后行，而后解说论证，而后总结阐明。用技术人更容易了解些的话，就是整顿成一颗树，而后做深度优先遍历。 当然《金字塔原理》里还有十分多有用的常识，还是举荐大家有空去读一读，必定会有更多的收货。 咱们明天先迈出第一步，就是总分总。换言之，内容的组织须要具备结构性。如果通篇内容，没有题目、没有分段、没有中心思想。是文章的话看着累，是演讲的话听着累。而结构化表白当前，有两大益处： 对于本人：更零碎、更体系的整顿了本人筹备分享的常识，对自我常识是更好的总结跟整顿。对于别人：人类对于有序事物的忘性必定是大于无序事物。结构化表白有利于观众接管信息并回顾信息。2 故事性除了结构性表白，我集体还很喜爱故事性的表白。就是想方法让本人的内容显得更加跌宕起伏或具备延续性。 跌宕起伏指的是一直地抛出问题，再解决问题。比方在我的《保险智能经营体系2.0的前端建设之路》。我先讲1.0的现状与问题，而后讲本人的策略与解法。做完当前，通过一些数据分析又发现了新的问题，而后又出了一些解法。这样一直的发现问题 -> 解决问题，让内容具备肯定跌宕起伏的故事感，能让读者继续保有新鲜感与浏览欲望。 延续性是指一直的由一个内容衍生出新的内容，最终答复最后的问题。比方我的《国家为什么老爱管咱们》（一篇介绍金融基础知识的文章），从金融引到货币，从货币讲到银行，再讲到影子银行，再讲到具备影子银行个性的互联网产品，最初答复国家为什么老爱管咱们。就像是在一条风景优美的公路兜风，两边的风光从树林突变到草原再突变到湖泊，过程连接顺畅，风光琳琅满目。最终证实了这是一条风景优美的公路。延续性的内容能够始终牵引着观众思路，放弃观众注意力。 其实我这边文章就尽量去恪守结构性跟故事性。主题是「如何做一篇高质量分享」，前面细分成几个观点，观点再细分子观点。这些观点又具备肯定延续性。先是定义什么是好的内容，有了好内容后讲怎么去组织、去展现、去表白。最初的最初再做一个总结。四 如何去展现内容如果是以文章模式的非现场分享，那能组织好内容，内容又是高质量的，置信文章肯定也是高质量的。但本文更多的还是想探讨周会、月会等现场分享时，该如何更好的展现咱们要分享的内容。 而对于这个问题，我只有一个外围观点：少字多图。 我当初发现很多人特地喜爱把文章间接拿来做现场分享，但这种状况的分享我没见过有成果特地好的。因为根本都是在念稿子。这就是我观点的最极其背面，简直全都是字。如果一篇现场分享稿也全都是字。那请问大家是听你谈话呢？还是看你文字呢？还是听你念字呢？这还不如把文档发给大家本人看呢。 我始终激励大家还是用PPT分享，因为PPT上不容易放太多字，只能放外围信息。因而用PPT会倒逼本人把要害信息摘取进去。因为字少了，信息少了，又会倒逼本人去更活泼的传播观点。 我以我的《国家为什么老爱管咱们》为例。我写完文章当前，又筹备在团队内做个分享。但文章字数有3万多字，如果我当稿子念，预计大家梦都做两回了。所以我把文字信息给形象，配上适合的图，把文章当做演讲稿，再多加一些即兴施展。比方其中的「什么是资产证券化」一节，该节纯文本字数有867字，我转成PPT后如下： 用几张图片加摘要文字，展现资产证券化的演化过程。而后画了专门的图来介绍资产证券化自身的运行机制。最初加粗个大字表白外围的观点。 对于有些并没有太多观点的章节，我的PPT更简略。比方其中的「你是否听过影子银行」这一节，次要是讲了两个小故事，并没太多观点。因而我的PPT就放了两张图，其余靠嘴巴讲讲即可。因为这种没要害信息的内容，观众没必要一边听我讲一大段故事，一边在PPT上看一堆文字。 当然，很多技术的分享，可能要演示一些代码，或者展现一些流程图、架构图，用语雀这样的文档工具可能会更不便编写跟展现。只有管制好排版，不要堆列演讲文字，对要害信息加大加粗，这也是能够的。语雀也提供了演示模式，但心愿大家能更好的利用这个演示模式。 总结一下，其实分享模式自身并不重要，重要的是别念稿。分享文档肯定是高度形象后的信息展现，其余过程的论述尽量靠本人的嘴巴配合图片去传播。记住外围要义：少字多图。 PS：有一种PPT分享模式，叫高桥流。每一个PPT上就几个大字，其余全靠嘴。罗永浩，还有咱们前端熟知的贺师俊都应用过该模式做过分享。我也已经尝试过：《Node HTTP/2 Server Push 从理解到放弃》[3]。 ...

9 月直播课领先看CODING DevOps 9 月直播课闪亮退场！本次线上直播课由 CODING 联结业余征询与培训公司 - 青蓝征询，于 9 月 22 日 - 24 日为同学们带来 CODING DevOps 深度解析系列直播课。 本次直播课蕴含 3 节课程，由 CODING 特邀讲师 —— ICAgile 认证麻利教练林伟丹、CPHT（靖本行策有限公司）创办人，软件工程布道师卢建成、EXIN 官网认证 DOP/DOF 讲师刘宁，三位大咖主讲。课程将通过 DevOps 的各面向来探讨常见的概念误区，联合实例分析部署价值流、研发价值流、治理价值流和用户价值流，探讨 DevOps 实际在技术与管理工作中的使用；并且从数字化转型的需要角度，探讨组织与 DevOps 的关系。课程内还蕴含讲师举荐书目，心愿能为对数字化转型和 DevOps 感兴趣的同学们提供一个将扭转引入组织的钥匙和终点。 那么一起来看看课程详情及报名形式，文末还有福利流动，千万别错过—— 开课时间9 月 22 日 - 24 日，每晚 19:00 - 20:00 课程安顿第一课：《助推 DevOps 的四层价值流实战》第二课：《DevOps 误区与组织筹备》第三课：《DevOps & ITIL —— 共存还是代替？》讲师介绍第一课：林伟丹 - ICAgile 认证麻利教练、Exin DevOps 资深受权讲师、中国 DevOps 社区外围组织者之一第二课：卢建成 - CPHT（靖本行策有限公司）创办人软件工程布道师第三课：刘宁 - EXIN 官网认证 DOP/DOF 讲师、高级 ITIL 讲师扫描海报二维码立刻报名 ...