用c语言做网站文明网站建设情况报告

当前位置： 首页 > news >正文

用c语言做网站,文明网站建设情况报告,标书制作流程,单页网站技术目录 一、快速了解抽象思维 #xff08;一#xff09;抽象思维的本质理解 #xff08;二#xff09;系统架构中的重要性 #xff08;三#xff09;软件开发中抽象的基本过程思考 意识和手段 抽象的方式 抽象层次的权衡 二、业务中的应用实践 #xff08;一一抽象思维的本质理解 二系统架构中的重要性 三软件开发中抽象的基本过程思考 意识和手段 抽象的方式 抽象层次的权衡 二、业务中的应用实践 一业务背景和研发挑战 二营销系统目标架构 三实践解决方案 问题域的顶层抽象 子问题的抽象与解决 共性统一解决、差异开放扩展的展品子系统 基于模块化、模板化和函数化的互动子系统 产品功能标准化、安防体系化的优惠子系统 横纵向稳定性建设 参考文章链接 一、快速了解抽象思维 一抽象思维的本质理解 抽象思维是一种认知和思维方式通过在众多事物中提取共同的、本质性的特征舍弃非本质的特征形成概念、判断、推理等思维形式以反映事物的本质和规律。抽象是将复杂的现实世界简化为更易于理解和处理的概念或模型的过程。这种思维方式使人们能够通过一般性的规律和原则来理解和处理复杂的现实情境。 在抽象思维中人们通过对感性材料的加工制作去粗取精、去伪存真从具体事物中提炼出普遍性的特征。这有助于人们更有效地组织和理解信息提高认知效率并使得复杂的问题变得更加可管理。抽象是认知过程中的一种重要手段常常涉及到将具体事物归纳为更一般的概念从而使得我们能够处理更广泛和复杂的信息。 比如当我们面对如地球上大约150万种不同的动物这样庞大而复杂的现实情境时要一一认知和理解每一种动物几乎是不可能的任务。这是因为每种动物都有其独特的特征、行为和生态系统涉及的信息量巨大且复杂。 动物学家们采用了抽象思维的方法将这些多样性的动物进行分类。他们从所有动物中提取了一个共同的、本质性的特征即是否有脊椎。这一抽象分类首先将动物分为两大类脊椎动物和无脊椎动物。这是一个对复杂事物进行简化的抽象过程。 然后对脊椎动物这一类别进行进一步的抽象和细分将其分为鱼类、爬行类、两栖类、鸟类以及哺乳类等亚类。这一层次的抽象进一步简化了分类使我们能够更轻松地理解动物的整体组织结构而不必深入研究每个具体的物种。 通过这种抽象分类我们可以以更高效的方式了解动物界的多样性而不必被每个具体动物的细节所淹没。这个过程不仅提高了对动物的认知效率还为进一步的研究和了解提供了有序的框架。这个例子突显了抽象思维在处理庞大而复杂的信息时的重要性通过将信息层次化和分类我们能够更好地理解和应对复杂的现实世界。 二系统架构中的重要性 “编程中最重要的三件事是抽象抽象抽象”。抽象是计算机科学中许多工作的中心它包括为系统定义正确的接口以及为系统实现设计合适的架构。 在计算机科学中抽象是指高级的模型是和低级的实体相对的。 例如在面向对象编程中“鸟”是抽象模型具有羽毛、没有牙齿、会下蛋等共性特征“大雁”、“鸭子”和“企鹅”是具象实体它们继承了“鸟”的共同特征同时具备个性差异比如“大雁”会飞“鸭子”和“企鹅”不会飞。 从系统实现角度看经过这样的模型设计之后“大雁”在代码实现上就无需从头开始对每一项属性和功能进行编程而是在继承抽象类“鸟”的共性基础上专注于“飞”等差异逻辑的实现。因此在计算机科学中抽象通常意味着化繁为简并将共性与差异分离使得一大堆底层代码变得可移植和可复用从而可以更加高效地实现和演进软件系统。 从系统使用角度看通过抽象化的模型设计“大雁”、“鸭子”和“企鹅”的功能被拆解提炼为“下蛋”、“飞”等极简的接口或者方法使得使用方可以在不了解它们如何提供功能的情况下使用它们极大地简化了复杂性。 通过上述案例我们可以认识到抽象思维能够帮助我们极大地提升解决问题的效率具体而言它可以帮助我们 化繁为简 抽象思维通过将问题分解、分类、拆分帮助将复杂的问题简化为更易于处理的部分。这个过程就好比在森林中迷失了方向抽象思维就是通过识别并跟踪主要特征从整体中剥离出关键元素使得问题的复杂性降低进而更容易找到解决方案。由表及里 抽象思维有助于我们看到问题的本质而不仅仅是表面现象。在面对一个问题时很多时候我们首先看到的是外部的表象而抽象思维则能够帮助我们深入探究问题的核心原因和关键驱动因素。这种方法类似于医生对病人的诊断不仅仅看症状还要找到病因。举一反三 抽象思维帮助我们将具体问题升华为一般性的原则或模型。这就像是学习数学通过理解一个问题的解法我们可以推广到解决类似类型的问题。这种抽象过程使得我们能够以更高效的方式处理问题而不是每次都从零开始思考。 综合来看抽象能力是一种关键的底层思维能力它并不仅仅局限于计算机科学和软件开发领域而是贯穿于我们解决各种问题的过程中。通过抽象我们能够更清晰地定义问题、更深入地理解问题的本质从而更有效地找到解决方案。这种思维方式不仅在解决具体问题时有用还有助于我们更全面地理解世界提升对复杂现象的认知水平。 三软件开发中抽象的基本过程思考 抽象在软件开发中是一个基本而重要的过程其核心目标是提取事物的共性以便通过纵向和横向分层将复杂问题分解成可管理的小问题实现通用能力的重复利用从而降低系统构建的复杂度。 意识和手段 抽象过程首先需要一种正确的意识即在问题分析中要超越表面站在更高的层次来看待问题。这意味着不仅仅要看到问题的具体细节还要理解问题的本质和共性从而进行有效的抽象。 在软件开发中抽象有两种基本方法即自下而上和自顶而下。通过业务建模等手段可以自下而上地从具体业务中提炼出模型和数据结构。而通过软件系统设计等手段可以自顶而下地从整体出发逐步定义系统的结构和模块划分。 抽象的方式 自下而上 这是一种从局部到整体的抽象方式即从小到大通过业务建模等手段自底向上地归纳和演绎。这种方法关注局部细节逐步构建出系统的整体模型、模块和服务。例如在面向对象的开发中从业务实体中提取出类和对象逐步建立起系统的整体结构。自顶向下 这是一种从整体到局部的抽象方式即从大到小通过软件系统设计等手段自顶向下地拆解和切分。这种方法注重整体架构和系统的高层次设计通过逐步拆解和细化最终形成系统的模块、服务和组件。例如在软件系统设计中从整体业务需求出发逐步分解成各个子系统和模块。 抽象层次的权衡 在软件系统设计中抽象层次的选择至关重要。权衡抽象层次是指根据业务场景的需要在抽象设计过程中选择合理的层次。过高的抽象层次可能导致过度泛化而过低的抽象层次则可能导致失去通用性。例如在接口设计中选择参数类型时需要权衡通用性和类型约束力以避免潜在的类型转换异常问题。 总体而言抽象是软件开发中的基本思维和方法之一通过合适的抽象我们能够更有效地解决问题提高系统的设计质量和可维护性。 二、业务中的应用实践 查看高超的文章《抽象思维及其在点评广告营销系统中的实践》见下文链接可以学习看下美团的应用实践 一业务背景和研发挑战 广告营销系统是大众点评平台的关键支撑其主要业务目标旨在为平台创造可观的商业收入。通过在美团/点评App上提供广泛而多元的广告营销方案系统致力于为境内外品牌客户打造全面有效的广告解决方案。这一业务模式的核心是在移动应用平台上为品牌客户提供一揽子的广告服务其中包括但不限于品牌传播、获客引流和销量提升等多方面的关键业务。 在整体上广告营销系统通过其在大众点评平台上的精准定位和服务为品牌客户提供了一个强大而综合的广告推广平台。通过实现品牌建设、客户引流和销售增长等关键业务目标系统为大众点评平台的商业收入创造打下了坚实的基础。业务整体的发展如下 在业务稳定期研发团队的工作方式发生了变化从以往的需求驱动型逐渐过渡到技术驱动型。技术驱动要求研发同学具备高度主动性和独立思考能力需要他们主动思考并定义当前影响业务发展的问题并制定相应的技术规划来解决。在定义问题时采用抽象思维对问题进行简化由表及里有助于提高解决问题的效率。为支持业务实现目标研发团队需要解决以下问题和挑战 需求频率高且多变 广告营销业务面向外部客户需求不确定性大且节奏多变。如何在不增加研发资源的情况下确保按期交付成为首要挑战。 客户需求方案多样 面对来自各行各业的品牌客户需求方案多样化。建设可复用的解决方案成为降低高投入成本的挑战。 系统规模快速增长 随着业务发展系统规模不断增大对技术运营的要求也随之增加。如何控制系统复杂度保障系统稳定运行成为底线挑战。
这些挑战要求研发团队在技术驱动下更加注重主动思考问题采用抽象思维简化复杂性以提高解决问题的效率。 二营销系统目标架构 三实践解决方案 在解决研发挑战时引入了马斯克所提倡的第一性原理即回归事物最基本的条件通过拆分为各要素进行解构分析找到实现目标最优路径的方法。 对于前述的三个研发挑战实质上都涉及到软件系统的复杂性这种复杂性导致了低效率、低质量和高成本。软件复杂性主要由不确定性、无序性、规模和认知成本构成 其中认知成本和不确定性依赖于对业务问题的定义与解构无序性则取决于解决方案的有效性可以通过标准化和结构化来保持系统有序规模是客观存在的可以通过分而治之和提高解决方案的复用性来解决。 因此首先从业务出发尝试在业务中找到简化问题的可能性接着通过有效的业务建模进一步简化问题的复杂度最后选择合适的架构来表达业务模型。在业务发展过程中我们需要循环上述流程不断适应变化。这种方法有助于降低软件复杂性提高系统的效率和质量。 问题域的顶层抽象 在构建理想的营销系统之前我们首先需要深入了解营销业务的本质。通过从本质出发我们能够更容易地找到解决问题的杠杆点。营销业务的最终目标是服务消费者因此从消费者的角度出发我们通常需要回答三个关键问题“这里有什么”what、“我为什么要参与”why、“我怎么参与”how。 这三个问题的答案直接对应了营销系统能力的三个核心要素即展品、优惠和互动。这构成了我们对营销系统的顶层抽象。简要解释如下 展品What 涉及了消费者关心的产品或服务即营销活动中的展示物品。消费者需要清楚了解在这个营销平台上有哪些产品或服务可供选择。 优惠Why 针对“我为什么要参与”这个问题优惠是一个重要的激励因素。消费者希望知道为什么参与这个营销活动会对他们有利可能涉及到价格优惠、特别优惠或其他吸引人的福利。 互动How 涉及到参与的具体方式和交互过程。这包括消费者如何参与到营销活动中如何获得优惠以及他们与平台之间的互动方式。
通过理解这三个核心要素我们可以更系统地设计和构建营销系统确保它能够满足消费者的基本需求提供有吸引力的产品或服务激发他们的参与兴趣并提供简便而愉快的互动体验。这样的系统能够更好地服务于业务的本质提升用户参与度和满意度。 在完成对营销能力的顶层抽象之后要解决的核心问题逐渐明了系统的全景图也逐渐清晰。接着就是从业务发展趋势出发逆向思考技术侧现状与理想目标之间的差距进而寻找应对策略最后基于对营销能力的抽象拆解出具体的关键任务 展品子系统收敛营销需求中展品领域的解决方案以更方便地获取展品更高效地处理展品更灵活地展示展品。 互动子系统构建支持可插拔、可编排、可配置的互动组件库以降低互动需求的研发交付时长并提升互动模块的可靠性。 优惠子系统建设一站式电子奖券系统通过配置化支持各类奖券的制作并提供标准化的发券、用券能力以及体系化的优惠权益安全防控能力。
此外在技术运营方面要以不发生严重级事故为目标完善系统的稳定性保障措施降低系统发生事故的概率并提升团队人员应对风险的能力。 子问题的抽象与解决 共性统一解决、差异开放扩展的展品子系统 展品是抽象出的概念实际对应展示营销中的营销标也就是营销活动中展示的商户、外卖、团购、评价等。在过去的技术实现上针对展品领域的需求做了部分代码级复用但还需要经历完整的需求分析、方案设计、系统实现和测试上线过程。 为了降低展品领域的开发和维护成本期望用一套系统解决展品领域的绝大部分需求。但是实际需求总是存在与设想形态偏离的情况例如A活动期望通过九宫格的方式展示商品而B活动希望用单排列表的方式展示。 因此需要通过抽象建模分离需求中的共性和差异部分 针对共性部分可以建设面向流程、面向服务和面向功能的统一能力来解决对于差异部分比如数据结构的差异、展品字段的差异或者展示样式的差异可以开放扩展点以提升系统应对变化的能力。 确定了解决思路接下来就是业务建模也就是用合理的技术语言将业务问题精确地翻译成技术问题然后再寻找解决问题的方法。 从具体案例出发结合分层原则将展品子系统分为如下图所示的三层 中间的一层定义了展品的身份包括它是哪个业务线的以及它是通过自建存储还是对接外部服务来实现数据管理的为如何支持展品的统一管理打下基础最上面一层聚合了展品的共性部分包括展示规则、排序规则和展示时间等为提升展品系统的复用性奠定基础最下面一层是展品模型的具体定义包括展品类型、展品属性等并提供扩展能力。 从抽象模型出发结合统一流程进行领域拆分、功能细化可以得出展品子系统的全景图 首先在流程的统一上遵循求同存异的原则实现展品处理流程的最大化统一。其次在领域服务的拆分上以展品模型为基础对标业务流程遵循职责内聚的原则将系统分为供给域、加工域和查询域分别对应展品数据的接入、处理和输出能力。最后在展品系统功能的统一上通过无需开发代码的配置化解决80%的共性开放扩展点应对20%的差异。 基于模块化、模板化和函数化的互动子系统 互动营销主要强调的是用户和客户之间的互动从而培养用户对客户品牌的认知和购买欲常见的互动形式有做任务领奖励、社交互动、知识问答等。互动在技术上意味着有较多的写操作相比只读场景的展示营销有着更高的系统复杂度因此也更容易出bug。过去针对互动营销需求在技术建设上主要是通过沉淀独立的组件例如点赞、收藏、留资、抽奖等来提高研发效率的但是一个互动需求还是需要在互动逻辑编排上投入较多的开发、测试和维护成本。 这次优化的目标是实现系统性的研发质效提升互动需求的零开发支持率提升至90%以上反映提测质量的千行代码bug率能够控制在0.5%以内。 为实现这个目标采用抽象分治法。首先对过去交付的需求案例进行总结分析将互动营销玩法进行抽象分类任务类互动玩法占比65%左右社交类玩法占比30%其他的一些定制小游戏等玩法占比5%。其中任务类和社交类玩法的确定性较高可以在组件化的基础上采用模块化、模板化等手段来进一步提升系统的复用程度而对于变化较多的其他类玩法可以通过函数化来降低定制需求的开发、部署和运维成本。这样一来我们在面对互动营销需求时可以在开发、测试和运维方面得到质的提升。此外可以通过提升存量代码的单元测试覆盖率减少代码变更的频率来提升代码质量。 模块化是以业务逻辑为单元的抽象它是对以代码单元为主的组件化的进一步抽象使得每个模块都包含着执行预期功能的一个唯一方面aspect所必需的所有东西例如任务模块是基于任务组件、推送组件、签到组件等构建的提供了创建任务、分发任务、展示任务列表和状态流转通知等一个任务产品模块应该具备的所有功能。 换言之模块化可以用来分割组织和打包软件每个模块完成一个特定的、标准化的子功能并且它的功能是可扩展的将这些模块按某种方法组装起来成为一个整体可以完成整个系统所要求的功能某个模块在不被需要的时候也可以独立拆卸。因此基于模块化构建的互动子系统在复用性、易测性每个模块可以独立测试和可靠性每个模块可以独立部署运行时互不影响上可以得到进一步的提升。 模板化是基于范式的抽象方法它的主要思想是定义一个操作的一系列步骤对于某些暂时不确定的步骤就留给子类去实现这样不同的子类就可以组成不同的步骤。因此模板方法的核心在于定义一个“骨架”。在互动营销需求中经常遇到这类需求 “当用户关注了xx官方号后们就给他发张优惠券” 这种需求经过抽象可以提炼出一种范式叫IFTTT是“If This Then That”的缩写。简而言之IFTTT就是基于条件触发的任务是这类需求的模板“骨架”即“若xx发生yy行为就执行zz动作”。其中每一个可以发生行为的场景叫做一个Channel触发的条件叫Trigger之后执行的任务叫Action这一整套流程就叫Recipe。 基于IFTTT的基本理念可以实现“由简单组成的复杂”即由众多简单的IFTTT流程相互衔接组成跨组件、跨模块的复杂流程。相比于面向过程的传统开发方式基于范式的模板化开发模式可以减少简单重复的代码开发、缩减系统规模从而极大地提升开发效率降低运维成本。 在模块化、模板化的技术建设中不可避免还会遇到一些超出预期的需求。 针对这类需要定制化开发的需求过去有两种方案 一是“All In One”也就是将这类需求的实现收敛在一个单体服务中这样可以不用从0到1搭建服务一些非功能性需求的代码也可以复用开发效率较高但是因为单体服务在运行期未隔离、服务体积也会不断增长所以存在稳定性差和可维护性差的问题二是“微服务”架构也就是为每个需求搭建一套独立的服务这样可以解决稳定性的问题但是存在开发成本高、机器资源利用率低的问题。 这两种方案各有利弊如果将它们的优势叠加就能完美地解决定制化开发需求的效率问题。当认识到问题的本质后就比较容易找到解决方案这里引入了函数化的解决方案也就是业内新的一代开发模式FaaS函数即服务Function as a Service。 基于FaaS这里采用了我司的Nest平台可以在开发期仅关心占比20%的业务逻辑由框架解决占比80%的非功能性需求而在运维期业务开发可以实现秒级发布也无需关注机器层面的容量评估、扩缩容、容灾、升级、下线等日常运维事务可以节省大量的机器资源成本和技术运营人力成本从而达到提效、提质和降本的目的。 产品功能标准化、安防体系化的优惠子系统 优惠是做好营销必不可少的元素它可以激励用户更好地参与到营销活动中。 过去在优惠需求领域遇到的主要问题包括两个 一是交付效率低因为优惠产品形式多样而且经常需要与客户系统对接不确定性较高二是安全风险高因为优惠模块一旦出问题就意味着直接的经济损失。 针对这些问题纵观优惠产品生命周期从优惠券的制作、发放和核销这三个主要环节入手分析相关的研发挑战和安全风险进而提出实现标准化的优惠产品解决方案和体系化的风险管控体系的目标以及相应的设计思路。 为了建设平台化的优惠系统提供标准化的产品功能需要从用户视角抽象推导标准的奖券模型。这里采用分析归纳法并用“5W1H”提问法来验证模型的完整性“用户who为了获得某种优惠why在什么时间when来到什么地方where满足什么条件how的情况下通过核验兑付权益what”从而推导出奖券的基本六要素 奖券权益抽象权益维度表示奖券所有者能够享受的权益。兑付时段抽象时间维度表示奖券所有者可以兑付权益的有效时段。适用商户抽象空间维度表示奖券所有者可以兑付权益的地方。使用规则抽象规则维度表示使用权益需要满足的条件。凭证标识抽象标识维度表示奖券的唯一标识用于权益在使用时的确权。核验模式抽象核验方法维度表示使用何种方式核销权益。 通过抽象提炼出奖券的基本要素后接下来就是从平台视角泛化设计奖券的模型为设计可扩展的优惠系统架构奠定基础。 首先是对奖券模型进行分层我们从“什么券”、“怎么发”和“怎么用”三个问题出发将奖券模型分为三层其次针对奖券的基本六要素设计抽象接口以支持扩展例如兑付时段可以是动态时段也可以是固定时段最后从平台视角出发扩充系统功能包括业务标识、管理模式、库存、发放规则等以实现较为完整的优惠系统功能。 营销安全是优惠子系统面临的最主要的挑战为了防止规模性的资损事件发生需要构建体系化的安全保障方案。如图所示从制定优惠营销安全应对原则出发一方面是通过组织团队定期学习公司、行业的营销安全事故案例从而提高安全意识另一方面针对业务流程中的制券、发券和用券核心环节以及数据存储构建立体化的安全保障手段。从而构建在事前预备兜底方案事中及时感知并处理异常事后总结复盘不断改进的安全防御体系。 横纵向稳定性建设 展品子系统、互动子系统和优惠子系统可以独立存在但在大多数需求场景中它们需要通过组合、联动形成整体。因此从营销系统整体出发需要在横向和纵向上进行综合性的稳定性建设以保障营销活动稳定地运行。 首先在横向稳定性建设上的关注点是活动的资损和客诉这是直接反映技术交付质量的指标。为了控制好这两个指标制定了“防备下游、怀疑上游、做好自己”的稳定性建设策略。但是一年需要交付几百个营销活动怎么平衡稳定性建设成本与效率呢对过去的营销活动分析后发现活动流量和风险分布是符合2/8原则的80%的稳定性问题集中在20%的活动上。因此计划建立活动评级机制根据风险评估的活动定级S/A/B进行稳定性保障资源的分配从而最大化稳定性建设的收益与投入比。 在纵向稳定性建设上关注点是各个子系统、子功能的稳定性例如抽奖组件是否是高可用、高可靠的。然而和上面遇到了同样的挑战营销系统的功能模块有上百个如何平衡稳定性建设成本与效率呢我们从功能模块的变化频率和风险等级两个维度将所有营销功能组件分为四类进而按系统模块的风险等级和易变性拆分出系统模块的稳定性保障优先级再针对性地做好系统在运行时的解耦和分层分级运维。 参考文章链接 抽象思维及其在点评广告营销系统中的实践 基本思维篇–抽象思维 - 知乎