代码 程序员 项目 很多年前，当我还是一名计算机专业的大四学生时，整天上网浏览各类招聘信息，想找到一个合适的程序员实习岗位。除了实习岗位外，我偶尔也会点进一些“高级工程师”的招聘帖里。现在回想起那些帖子，抛开让人眼花缭乱的技术名词，我印象最深的就是常出现在第一行的岗位年限要求：“本职位要求 工作经验 5 年以上”。作为一只一天班都没上过的小菜鸟，这些年限要求在我眼里简直长到夸张。不过，望洋兴叹之余，我有时也会在心中暗暗憧憬一下：“五年工作经验的程序员，那该多厉害啊？写代码对于他们来说，是不是像吃饭一样简单？”时光荏苒，一晃十几年过去了。如今回头一望，自己也成了一名有着 14 年工作经验的光荣打工人。在软件开发行业摸爬滚打这些年后，我发现很多事情，与我在大四时所想象的大不相同，比方说：随着经验增长，编程并不会变简单太多，“像吃饭一样简单”只出现在梦里给许多“大项目”写代码不光没意思，还很危险，远不如在 LeetCode 上做一道算法题有趣只从技术角度思考问题，成不了好程序员，有些东西远比技术更重要细想起来，这类关于编程的感触还有许多。我整理了其中 8 条，写成了这篇文章。如果其中某些观点引起了你的共鸣，我会非常高兴。更多编程干货：学编程后，我做了这10个有毒的在线免费设计神器！（下）上篇的5个神器大受欢迎，人气极高。阅读文章 > 一、写代码很简单，但写好代码很难编程曾经是一项门槛很高的专业技能。从前，一个普通人想学编程，最常见的做法就是通过教材和书本学习。不过大部分编程专业书，十分艰深晦涩，对于初学者来说很不友好。因此不少人在尝到编程的乐趣前，就早早地半途而废。但如今，学编程正在变得越来越容易。学习不再像以前那样，只能硬啃书本，而是多了许多新途径。观看教学视频、参加 Codecademy[1] 的交互式课程，甚至直接在 CodeCombat[2] 通过玩游戏来学编程，每个人都能找到适合自己的学习方式。“妈，我真没在玩游戏，我在学编程呢！你看屏幕右边！”此外，编程语言也在变得越来越易用。经典的 C 和 Java 不再是大多数初学者的首选，许多更简单、更易上手的动态类型语言如今大受欢迎，与之相关的 IDE 等工具也变得越来越完善。这些因素进一步降低了编程的学习门槛。总而言之，编程早已褪去了它的神秘面纱，从只有少数人才能掌握的神秘技能，变成了一门人人皆可学习的普通手艺。但更低的学习门槛，更友好的编程语言，并不意味着人人都能写出一手好代码。如果你已经工作，参与过一些项目，那我很想问你一个问题：”你日常接触的这些项目的代码质量如何？是好代码多，还是烂代码多？”不知你会怎么回答，我先来说说我的答案。1. 好代码还是很少2010 年，我跳槽到了一家总部位于北京五道口的大型互联网公司。加入这家公司前，我只在十人规模的小公司待过，因此，我对新公司在各方面都有着很高的期待，尤其是软件质量方面。当时，我心里想的大概是这样：“这可是支撑了有着千万用户量的产品的大项目，代码质量跟之前那些比，肯定有质的飞跃吧！”等到在新公司工作了一周后，我才发现自己实在是错得离谱。所谓“大”项目的代码质量同我的预期相去甚远。打开 IDE，数百行的函数和神秘的数字字面量比比皆是，开发任何一个小需求都难如登天。后来，在待过更多公司，接触了更多软件项目后，我总结出一个道理：不论公司多大、项目多牛，在实际工作中遇见好代码，仍然是小概率事件。2. 好代码有哪些要素？话说回来，到底怎样的代码才算是好代码？在这方面，Martin Fowler 有一句话常被大家引用：“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”“任何傻瓜都能写出计算机能理解的代码。优秀程序员写人类能理解的代码。”我认为它可以作为评价好代码的原点：好代码一定是可读、易读，且容易理解的。写出好代码的第一原则，就是把人类读者放在第一位。除了可读性以外，评价代码好坏还有许多其他维度：贴合编程语言：是否使用了当前编程语言的推荐写法？语言特性和语法糖，使用程度是否恰到好处？易于修改：代码设计是否考虑了未来的需求变更，当变化发生时，代码是否容易随之修改？API 设计合理：API 设计是否合理，易于使用？好的 API 在简单场景下使用方便，在高级场景下又可以随需求扩展。性能够用：代码性能是否满足当前业务需求，同时为未来保留了一定提升空间？避免过度设计：代码是否存在过度设计、过早优化的毛病？…总而言之，对于任何层级的程序员来说，好代码都不是什么唾手可得的东西。要写出好代码，需要在许多维度上反复权衡、精心设计，最后再加以持续打磨。既然如此，假如想尽快掌握写代码这门手艺，有捷径吗？3. 写好代码的捷径在许多层面上，我认为编程和写作非常相似[3]。二者都是使用文本和符号来表达思想，只是方式略有不同。谈到写作，我想问一个关于作家的问题：“你听说过不读书的作家吗？你有没有听到过某位作家说，他从来不读其他人的作品，只读自己的东西？”。我猜答案应该是否定的吧。如果你去查阅相关资料，你会发现许多职业作家的日常生活，就是阅读和写作两件事在不断循环。他们每天会花大量时间阅读各类文字，然后再写作。同样是“文字工作者”，程序员们就很少重视阅读。但要想快速提升编程能力，阅读正是不可或缺的重要一环。除了日常工作接触到的项目以外，我们应该更多地阅读那些经典软件项目，从中学习 API 设计、模块架构和代码编写的技巧。不光代码和技术文档，最好再定期读一些计算机方面的专业书，保持阅读书籍的习惯。在这方面，我认为 Jeff Atwood 在 15 年前写的文章 "Programmers Don‘t Read Books -- But You Should（都说程序员不读书——但你应该读）"[4]，如今读来仍不过时。提升编程能力的捷径，就藏在“阅读 编程”这个无尽循环里。“一个好的程序员应该做什么？”二、编程的精髓是“创造”在程序员的日常工作中，有很多事情会让人充满成就感，甚至情不自禁地感叹“编程真美好”。比方说，修复了一个极难定位的 Bug，用新算法将代码性能提升了一倍，等等。但在所有的这类事情当中，没有任何一件，能和“亲手创造出一件东西”相比。当你在编程时，创造新事物的机会实际上随处可见。因为并非只有发布一个新软件，才称得上是“创造”。写一个可复用的工具函数、设计一套清晰的数据模型，全都可以归入“创造”的范畴。身为程序员，保持对“创造”的热情至关重要。因为它可以帮我们：更高效地学习：学习一门新技术，最高效的方式就是用它开发一个真实项目，在创造的过程中学习，效果最好。有机会邂逅了不起的东西： 许多改变世界的开源软件，最初都是作者纯粹出于兴趣所创造，比如 Linus Torvalds 和 Linux，Guido van Rossum 和 Python。1989 年的圣诞假期，荷兰人 Guido van Rossum 敲下了 Python 语言的最初几行代码，Python 最初仅被期望作为 ABC 语言的继承者，但后来“吞噬”了全世界虽然“创造”好处多多，程序员们也有大把机会去做，但许多人常常缺少一种身为“创造者”的觉悟。就像那个广为流传的小故事所说：一位哲学家询问正在砌砖的工人，有人清楚地知道自己是在建造一座大教堂，有人却认为自己只是在砌砖。很多程序员正是“只见砖块，不见教堂”。将自己定位成创造者后，看待事物的方式就会发生天翻地覆的变化。举个例子，同样是给 API 增加报错提示文字，创造者们就能跳出“快速完成需求就好”的思维陷阱，向前一步，追问自己一些更重要的问题：“我想为用户创造什么样的产品体验？怎样的报错文字，更能帮助我达成该目标？”就像任何一个有用的编程模式一样，“创造者思维”也能成为你的职业生涯的一道巨大推进力。因此，现在就试着问自己一个问题吧——“我的下一份创造会是什么？”三、打造高效试错的环境至关重要我曾参与开发过一个互联网产品，它设计精美，功能丰富，每天都有大量用户使用。但就是这么一个从市场角度看颇为成功的产品，工程质量却非常糟糕。如果你打开它的后端项目，把所有目录翻个底朝天，都找不到任何一行单元测试代码，其他自动化测试流程也是无从谈起。而业务逻辑偏偏又十分复杂，最后，项目代码间的意料耦合多如牛毛，开发一个新特性，很容易把旧功能给搞挂。“在忙啥呢？” “试着修复我之前修一个问题时搞出来的问题，那问题是我之前解决另一个问题搞出来的，而那个问题又是我……”因此，项目每次发布时，开发和产品同学全都得严阵以待，氛围十分紧张。整个发布过程也很刺激，紧急回滚时有发生。一个人在这样的环境中工作，技术成长抛开不谈，心理素质肯定能得到极大锻炼。编程原本是一件充满乐趣的工作，但为这样的项目编程，乐趣根本无从谈起。究竟是什么夺走了编程的乐趣？1. 理想的编程体验“刷题”LeetCode[5] 是一个著名的编程学习网站，上面提供了许多覆盖各个难度的编程题，大部分与算法相关。用户可以选择自己感兴趣的题目，直接在浏览器上编写代码（支持十几种编程语言）并执行。如果通过了全部的测试用例，则算作解答成功。在 LeetCode 上做题在 LeetCode 刷题很像在玩游戏，富有挑战性，同时也很有趣。整个做题过程，实际完美展现了一种理想化的编程体验：关注点分离：每道题目都是一个独立个体，同一时间内，开发者可以完全沉浸在一道题目中；快速获得精准反馈：开发者每次调整代码后，能通过自动化测试快速获得结果反馈；零成本试错：写出的代码语法有错误、逻辑有问题，没有任何不良后果，心理负担小。不过，屏幕前的你很可能觉得我在说些废话。“不然呢？解算法题、写小脚本，不就是这样的体验吗？有啥特别值得说的？”你很可能会继续补充道，“你知道我们公司的项目有多复杂吗？规模超大，模块巨多，你懂我意思吗？每天服务 万人，光数据库就好几套，消息队列都有三种，开发起来当然要麻烦一点咯！”确实，全世界的软件千差万别，开发起来不可能都像在 LeetCode 上刷题一样轻松愉快。但这并不意味着，我们不应该努力改善自己身处的编程环境，哪怕只有一点点。要通过改善环境来提升编程体验，可用的理念和工具包括：模块化思想：妥善设计项目中的每一个模块，降低耦合，提升正交性设计原则：微观层面上，应用那些经典的设计原则和模式，比如“SOLID”原则自动化测试：编写规范的单元测试，必要时使用 Mock 技术，用自动化测试覆盖业务关键路径缩短反馈回路：切换编译速度更快的工具，优化单测性能，竭尽全力缩短从“改完代码”到“获得反馈”的等待时间微服务架构：必要时，将大单体拆分为多个职责各异的微服务，分散复杂度……关注编程环境，刻意创造出允许高效试错的“代码乐园”，让工作像刷题一样轻松愉快。是经验丰富的程序员能为自身团队做出的最好贡献之一。四、避开代码完美主义陷阱在代码质量上精益求精是好事，但也要注意别掉进完美主义的陷阱。因为编程不是艺术创作，不鼓励人们无限度地追求极致。作家大可花上数年打磨一本传世之作，但程序员在代码上钻牛角尖就很有问题。世间没有完美的代码。大多数时候，你的代码只要能满足当前需求，又为未来扩展留了一些空间就够了。有那么几次，我在简历上看到候选人给自己打着“代码强迫症”标签。隔着屏幕，我虽能感受到 TA 对代码质量的那份重视，但在我心底，其实更期望 TA 早已将完美主义陷阱远远甩在了后头。五、技术很重要，但“人”也许更重要在软件开发领域，“单一职责原则”（全称为 Single responsibility principle，后简称为 SRP）是一条非常著名的设计原则。它的定义很简单，一句话就可以概括：“每个软件模块应该只有一个被修改的理由”。单一职责原则：能做到，并不意味着你就该这么做要掌握 SRP 原则，关键在于搞清楚“被修改的理由”为何物。很显然，程序是没有生命的，它自身不能也不需要主动去改变。任何修改程序的理由，都来自与之相关的人，人是导致修改的“罪魁祸首”。举个简单的例子。看看下面这两个类，其中哪一个违反了 SRP 原则？一个字典数据类，支持两类操作：存数据、取数据；一个员工资料类，支持两类操作：更新个人信息、渲染一张用户资料卡片图。在大多数人眼里，第一个例子没问题，但第二个例子却明显违反了 SRP 原则。要得出该结论，好像无需任何严格的分析和证明，运用一丁点直觉即可。但假如做一些正经分析，第二个例子的可疑之处，在于能为其轻松找出两个不同的修改理由：管理员认为资料中的“个人电话”字段不能有非法号码，需增加简单的校验逻辑某员工认为资料卡片图上的“名字”部分太小，希望加大字体”It is people who request changes. And you don’t want to confuse those people, or yourself, by mixing together the code that many different people care about for different reasons.” ——“The Single Responsibility Principle”“是人在要求软件变更。你绝不想把那些不同人出于不同原因所关心的代码混在一起，这样只会把他们和你自己搞糊涂。”——“单一职责原则”理解 SRP 原则的关键，在于先理解人以及人在软件开发中所扮演的角色。再举一个例子。微服务架构是近些年很火的一个技术话题。但许多人在讨论它时，往往只关注技术本身，却忽视了微服务架构与人之间的关系。将微服务架构风格与其他东西区分开的关键，在于将大单体拆分为独立的微服务后，不同模块间的边界可以变得更清晰。跟数百人的团队一同维护着一个大单体比起来，许多小组织各自维护着独立的微服务，明显拥有更高的运作效率。如果缺少了特定的组织规模（也就是“人”）作为前提，空谈微服务的各种技术优势和那些花活，纯属本末倒置。技术当然很重要。身为技术人员，那一张张瑰丽的架构图和独具匠心的代码细节，天然吸引着我们的注意力。但是，也请千万不要对软件开发里的另一个重要因素“人”视而不见。必要时，转换一下看事情的角度（从“技术”转向“人”），那样对你大有裨益。六、求知若渴是好事，但也要注意方法如今人人都在说“终身学习”，而程序员是一个尤其需要终身学习的职业。因为计算机技术的迭代更新非常快，某个三年前流行的框架或编程语言，很可能一个月前已经过时。一分钟之内会发生什么事情？Netflix 观看时间增长 70,000 小时；Snapchat 上有三百万视频被观看；Google 新增两百四十万次搜索；一个 JS 新框架被发明（这条不是真的 ）要在工作中表现得游刃有余，程序员们需要学习的东西非常多，涵盖各个层面。拿我比较熟悉的后端领域举例，一位合格的后端工程师至少需要掌握以下这些：一种或多种后端编程语言 / MySQL 等关系数据库 / Redis 等常见存储组件 / 设计模式 / 用户体验 / 软件工程 / 编译原理 / 操作系统 / 网络基础 / 分布式系统 / …虽然要学很多，但据我观察，大部分程序员其实都挺爱学习（至少不排斥），因此心态不是问题。不过有的时候，光有“求知若渴”的心态并不够，学习时，我们尤其需要关注“性价比”。1. 关注学习性价比下面这张图，展示了学习成效和投入之间的关系。学习成效与投入关系图，横轴为学习投入，纵轴为学习成效从图中可以看到，在学习的初级阶段，投入较少时，所获得成效增长飞快。但当成效超过某个阈值后，之后再想继续提升，所需要的学习投入就会呈指数级增长。正因如此，我建议你在学习任何一项新事物时，先在脑海中想清楚一个问题：“我应该在上图中的哪个位置停下来？”，而不是闷头猛学。知识的海洋浩瀚无边，有些东西需要我们成年累月的持续学习，不断精进。也有些东西，蜻蜓点水般学到一些皮毛已绰绰有余。准确判断并分配自己有限的学习精力，甚至比努力学习本身更重要。2. 挑选合适的学习资料有了学习目标后，下一步就是寻找合适的学习资料。在这方面，我想分享一次自己的失败经历。有段时间，我突然对产品交互设计产生了浓厚的兴趣，认为自己应该在这方面有所精进。于是，我精心挑选了一本领域内非常经典的专业书：《About Face 4: 交互设计精髓》[6]，将其买回家中，满怀信心地认为自己的交互设计能力可以迅速获得提升。但事与愿违，当我捧着那本经典著作时，发现自己连第一章都无法顺利读完——那句老话说的没错：“隔行如隔山”。从这次失败中，我总结出了一点经验。那就是学习某项新东西时，我们最好挑选那些更易读，更适合“门外汉”的学习资料，不要“眼睛大，嘴巴小”，只知道奔着最经典、最权威的资料而去。回顾之前的经历，我觉得以下几本书非常适合门外汉学习使用，性价比极高：《写给大家看的设计书》[7]：设计相关《点石成金》[8]：Web 用户体验相关《鸟哥的 Linux 私房菜》[9]：Linux 系统相关也许每个人的内心，都想成为一个博学的人，无所不知，无所不晓。但可供分配的时间的精力总是有限，我们不能，也不需要在所有领域都成为专家。七、越早开始写单元测试越好我非常非常喜欢单元测试，我认为写单测这件事，对我的编程生涯影响极大。夸张点说，如果以“开始写单元测试”作为分界线，把我的职业生涯分割成两段，后面那段远比前面那段精彩得多。写单测的好处很多，比如单测可以驱动你改善代码的设计、可以作为代码的一种文档，等等。此外，完善的单元测试还是构建前面提到的“高效犯错的环境”的关键。我已经写过几篇关于单测的文章，比如《有关单元测试的 5 个建议》[10]、《游戏“蔚蓝山”教我的编程道理》[11]。所以在这儿，我不打算再重复一遍。只说一句：如果到目前为止，你从未试过写单元测试，或从没重视过测试，我建议你从明天就开始写起来。一般情况下我不测试我的代码，但假如测的话，我在生产环境测八、程序员最大的敌人是什么？在大多数程序员段子里，产品经理经常作为反派角色出现。他们口中的项目需求总是变个不停，一天冒出一个新想法，搞得程序员苦不堪言。客户每天都在不停修改需求，所以，我们决定在下次发布前，把这些需求“冻结”起来在这些段子的烘托下，不断修改需求的产品经理，仿佛真成了程序员们最大的仇敌。似乎只要产品不乱改需求，大家的工作环境马上就会成为乌托邦。虽然偶尔吐槽一两句产品经理很有意思，但我还是想一本正经的说一句：产品经理不是敌人。因为从某种角度来说，软件生来就是准备被修改的（不然你猜，软件为什么叫“软”件？）。这样看来，开发软件和修建房子完全不同。因为没人会在建好一栋大楼后说：“让我们把它推倒重建一遍吧！一样的楼，但是用的钢筋和水泥比之前少 30%！”所以，产品经理以及不稳定的需求不是程序员的敌人。并且，能否写出易于修改、适配变化的代码，是区分普通程序员和优秀程序员的重要标准之一。那么，程序员们最大的敌人又是什么呢？1. 复杂度是最大的敌人就像《代码大全 2》中所说：软件开发的核心问题是管理复杂度。失控的复杂度就是程序员最大的敌人。来看看那些导致项目复杂度不断增长的要素：不断增加的新功能： 更多的功能等于更多的代码，更多的代码通常意味着更高的复杂度对高可用的需求： 为了实现高可用，消息队列等额外的技术组件和代码被引入对高性能的需求： 为了提升性能，缓存和相关模块代码被引入，部分模块被拆分后，换成高性能语言重写一再被推迟的重构：因项目排期过于紧张，迫在眉睫的重构被一再推迟，技术债越积越多忽视自动化测试： 没人写单元测试，也没人关心测试…终有一天，当项目的复杂度增长到一定程度后，空中会传来一声巨响。“咚！”，一个大家不愿改、不敢改的“大坑”凭空出现在了所有人的 IDE 中。猜猜看，究竟是谁挖下了这个坑？那些在降低复杂度上投入时间的团队，所负责的软件项目更容易成功2. 减缓复杂度增长的过程虽然复杂度总是会不可避免地持续增长，但有许多实践可以减缓该过程。如果每个人都能做到以下这些事，复杂度就有可能被长期控制在合理范围内：精通当前编程语言与工具，写整洁的代码使用合适的设计模式和编程模式对重复代码零容忍，抽象库和框架适当运用整洁架构、领域驱动设计思想编写详尽的文档和注释编写规范有效的单元测试分离那些变动的与不变的…要求看上去很多，但总结起来，核心其实就是一句话：写更好的代码。写在最后2020 年，我在小组内做了一个分享，当时的 PPT 标题是《编程十年后的十个感触》。将资料分享在公司内网后，有位同事看到，评论说光看 PPT 不过瘾，希望我能将其扩展成一篇文章，我回复说没问题。如今 3 年过去了，我总算是兑现了自己的承诺。当年准备分享材料时，我做完整个 PPT，最后一页实在不知道该放些啥。于是灵机一动，搞了个纯白色的背景，中间打了一行黑体大字：“十年很短，编程很难”。如今，第二个十年也已快行至中途，而这句话的后半部分好像对我仍然适用——长进不大，继续加油 。原文链接：https://www.piglei.com/articles/programming-is-still-hard-after-14-years/欢迎关注作者微信公众号：「piglei」本篇来源：优设网原文地址：https://www.uisdc.com/8-programming-experience
颜色 样式 代码 前言随着近几年 Figma 等一系列在线设计工具的崛起，相信设计师对设计系统的都有了更深的了解。其实设计系统的建设是一个非常庞大而复杂的工程。我们通过各种设计规范等对产研流程提效，但还是会经常遇到一些棘手的问题。1. 开发用的颜色/字体样式/投影等与设计稿存在差距；2. 颜色选择困难。不同设计师之间在用各种层级的文本颜色时，到底用 Gray1 还是用 Gray2，不知道该选哪一种；3. SaaS 类的产品需要根据客户的品牌色调整产品的主色，设计和开发都面临巨大的工作量；4. 设计稿的更新无法及时在开发者的代码中体现，一是因为开发首先需要拿到新的设计稿，再根据标注甚至肉眼判断区别后更新代码；另一方面，设计稿中看似简单的改动可能导致较大范围的代码改动，例如字体大小等；为了解决和优化上述的问题，Design Token 应运而生。它可以高效地解决产品设计和开发过程中的细节和风格一致性的问题，提高产研团队设计质量和协作效率。什么是 Design Token“Token”原本的意思是“令牌，指令”，与 Design 连在⼀起指“设计变量”。在工程逻辑中用于用户身份与服务器端进行验证，而在设计体系中，Design Token 则可以简单理解为封装的视觉样式参数。它通过规定样式参数，并通过一套符合设计师、工程师理解的统一的命名规则，为这些样式参数的定义名称。腾讯出品的 Design Token 应用指南：设计篇在线设计、研发协作工具和组件概念的普世化，让设计、研发效率大大提升；数字产品发展到今天，数字产品对迭代速度、个性化品质要求也越来越强。阅读文章 > 原子设计理论提出者 Brad Frost （布拉德 · 弗罗斯特）在《Atomic Design》中提到：原子设计理论从原子（Atoms）、分子（Molecules）、组织（Organisms）、模板（Templates）、页面（Pages）、标准流程（Patterns）再到更完善的设计体系（Design Systems），这一切都是为了产品设计、研发效率和一致性提供帮助。同时，它们也是传达设计原则、构成产品独特气质的基石。Design Token 就是原子级的最基础的构成要素。根据北美顶级 SaaS 企业的开源设计系统 Saleforce Lightning Design System 的解释，Design Token 是设计系统中的可视化原子，是设计属性的命名实体，使用它们代替具体编码值（如颜色的 16 进制、间距的像素值等），以便于维护一套可扩展且一致性的设计系统。可以说，Token 就是最底层的原子，本质上就是找到了组件、属性和代码之间的对应关系，统一了设计样式和前端语言，使组件和设计系统可以被快速管理。Design Token 的优势基于上述关于 Design Token 的基础解释，可以将 Design Token 的好处可总结为：设计语义-更易理解设计方案-更加一致主题皮肤-一键替换设计变更-高效维护设计成果-精准还原1. 设计语义-更易理解每一个组件的基础元素都可以用 Token 进行语义化的命名，帮助设计师和开发建立统一的描述语言。例如#91d5ff 这个色值按照传统的设计规范命名的方式，它可能叫 Blue-3。在实际应用的时候，设计师和开发并不能直接通过 Blue-3 来理解这个颜色到底是用在什么具体场景当中。而当我们通过 Token 语义的方式让它达到组件级别的精度时，它会叫：color-primary-brand-light-disable，不同的设计师和开发就能迅速的理解这个颜色应用在什么具体场景当中。2. 设计方案-更加一致当使用组件库实际运用到项目当中时，我们有时候会有不同设计师合作产出一个项目的情况。对于一些不熟悉设计规范或新加入的设计师来说，就会困惑，当使用二级文本色的时候，究竟是用 Gray2、还是 Gray3、Gray4。而这个时候，我们定义一个 Token 名称叫：color-text-secondary，这个 Token 嵌套的颜色是 ：Gray3，这样我们设计师在使用的时候，只需要选择 color-text-secondary 这个 Token 变量即可，能选择的颜色就是唯一的，这就能在一定程度上确保不同设计师在同一个场景当中的设计稿保持高度一致性。3. 主题皮肤-一键替换主题皮肤的替换可以用在两个维度，一是浅色模式和暗色模式的替换，二是不同品牌色之间的替换。我们可以将不同主题的同一个场景下的颜色使用同一个 Token 命名，例如变量名都叫：color-primary-brand-light-default，蓝色皮肤下对应的值为：#165DFF；红色皮肤对应的值为：#F53F3F。然后通过插件面板的一键操作即可完美切换。同时这种切换模式也可以带入 tokn.josn 代码（后面会具体讲如何输出 json 文件交付开发）中，与开发进行同步。4. 设计变更 高效维护还是上面的例子，当我们的二级文字颜色 color-text-secondary 需要进行变更，从 Gray-600 变为 Gray-500。如果没有“color-text-secondary”这个 Token，我们可能需要手动去选中所有用了 Gray-600 的二级文字的图层，一个一个地将它们改为 Gray-500，而当我们有了“color-text-secondary”这么一个 Token 时，我们只需要将 color-text-secondary 的值一键从 Gray-600 变为 Gray-500 便可以完成产品全局的颜色变更。进而设计师可以将 token.json 代码（后面会具体讲如何输出 json 文件交付开发）同步更新给开发 ，开发直接一键替换，线上的界面就能半自动地迅速应用到变更后的色值。5. 设计成果-精准还原设计稿能否被开发精准还原，这几乎是每一个设计师在实际项目中会遇到的问题。我们在进行设计验收的时候，即便花了很多时间进行走查，在表格上列举了很多细节问题，但最终的还原效果并不能得到保障。甚至在一些时候会感觉做验收比重新做一遍设计稿还要费劲「emo」，有的时候甚至会直接按 F12 在网页上改代码给开发提示「狗头」。例如，在常规不使用 Token 的情况下，开发同学使用的是硬代码的模式，代码编辑器无法判断这个颜色是否正确，如果开发不小心输错了一位数，就很可能导致线上运行时候的不一致。而使用了 Token 之后，开发只需要输入这个场景的 Token 名称的前缀，代码编辑器便会自动化地提示有哪几个颜色供选择就可以了，如果不正确，代码编辑器还会给出报错提示，开发同学可以在写代码的过程中完成基础的检验工作，这样一来，设计师的成果便能够一定程度上的精准还原，设计师验收的工作量也会小很多。在设计系统中应用 Design Token上面讲了这么多理论，接下来开始实战，准备好～1. 提炼 Token 组成元素Design Token 是构成设计语言的基本构建块，是设计系统中最核心、最基础的影响视觉风格的元素。根据 Figma Tokens 插件默认提供的面板中，可以将分别以下组成元素：Color 颜色、Shadow 投影、Typography 字体样式、Size 尺寸、Space 间距、Border Radius 描边圆角、Border Width 描边宽度、Opacity 透明度等2. 定义 Token 命名规则关于 Token 的命名规则，不同的团队有不同的定义方式，但其本质都是为了提高产品的一致性和工作效率。因此在对 Token 命名规则进行分类整理时，设计需要与开发同事达成一致，以确保能够更好地落地。在制定自己产品的 Token 命名规则前，带大家看一下大厂的 Design Token 都是怎么命名的腾讯文档 Token 变量表：https://mp.weixin.qq.com/s/sRRPlsxaUZj7220PLoFiRw腾讯 TDesign 开源设计系统 Token：https://github.com/Tencent/tdesign-common/blob/develop/style/web/theme/_light.less:root,:root[theme-mode="light"] {// 文字 & 图标 颜色--td-font-white-1: rgba(255, 255, 255, 100%);--td-font-white-2: rgba(255, 255, 255, 55%);--td-font-white-3: rgba(255, 255, 255, 35%);--td-font-white-4: rgba(255, 255, 255, 22%);--td-font-gray-1: rgba(0, 0, 0, 90%);--td-font-gray-2: rgba(0, 0, 0, 60%);--td-font-gray-3: rgba(0, 0, 0, 40%);--td-font-gray-4: rgba(0, 0, 0, 26%);// 基础颜色--td-brand-color: var(--td-brand-color-8); // 色彩-品牌-可操作--td-warning-color: var(--td-warning-color-5); // 色彩-功能-警告--td-error-color: var(--td-error-color-6); // 色彩-功能-失败--td-success-color: var(--td-success-color-5); // 色彩-功能-成功// 基础颜色的扩展 用于 hover / 聚焦 / 禁用 / 点击 等状态--td-brand-color-hover: var(--td-brand-color-7); // hover 态--td-brand-color-focus: var(--td-brand-color-2); // focus 态，包括鼠标和键盘--td-brand-color-active: var(--td-brand-color-9); // 点击态--td-brand-color-disabled: var(--td-brand-color-3); // 禁用态--td-brand-color-light: var(--td-brand-color-1); // 浅色的选中态// 警告色扩展--td-warning-color-hover: var(--td-warning-color-4);--td-warning-color-focus: var(--td-warning-color-2);--td-warning-color-active: var(--td-warning-color-6);--td-warning-color-disabled: var(--td-warning-color-3);--td-warning-color-light: var(--td-warning-color-1);// 失败/错误色扩展--td-error-color-hover: var(--td-error-color-5);--td-error-color-focus: var(--td-error-color-2);--td-error-color-active: var(--td-error-color-7);--td-error-color-disabled: var(--td-error-color-3);--td-error-color-light: var(--td-error-color-1);// 成功色扩展--td-success-color-hover: var(--td-success-color-4);--td-success-color-focus: var(--td-success-color-2);--td-success-color-active: var(--td-success-color-6);--td-success-color-disabled: var(--td-success-color-3);--td-success-color-light: var(--td-success-color-1);// 遮罩--td-mask-active: rgba(0, 0, 0, 60%); // 遮罩-弹出--td-mask-disabled: rgba(255, 255, 255, 60%); // 遮罩-禁用// 文本颜色--td-text-color-primary: var(--td-font-gray-1); // 色彩-文字-主要--td-text-color-secondary: var(--td-font-gray-2); // 色彩-文字-次要--td-text-color-placeholder: var(--td-font-gray-3); // 色彩-文字-占位符/说明--td-text-color-disabled: var(--td-font-gray-4); // 色彩-文字-禁用--td-text-color-anti: #fff; // 色彩-文字-反色--td-text-color-brand: var(--td-brand-color-8); // 色彩-文字-品牌--td-text-color-link: var(--td-brand-color-8); // 色彩-文字-链接// 分割线--td-border-level-1-color: var(--td-gray-color-3);--td-component-stroke: var(--td-gray-color-3);// 边框--td-border-level-2-color: var(--td-gray-color-4);--td-component-border: var(--td-gray-color-4);// 内投影 用于弹窗类组件（气泡确认框 / 全局提示 / 消息通知）的内描边--td-shadow-inset-top: inset 0 .5px 0 #dcdcdc;--td-shadow-inset-right: inset .5px 0 0 #dcdcdc;--td-shadow-inset-bottom: inset 0 -.5px 0 #dcdcdc;--td-shadow-inset-left: inset -.5px 0 0 #dcdcdc;// table 特定阴影--td-table-shadow-color: rgba(0, 0, 0, 8%);// 滚动条颜色--td-scrollbar-color: rgba(0, 0, 0, 10%);}Element-Plus：https://element-plus.org/zh-CN/--el-bg-color: #ffffff;--el-bg-color-page: #ffffff;--el-bg-color-overlay: #ffffff;--el-text-color-primary: #303133;--el-text-color-regular: #606266;--el-text-color-secondary: #909399;--el-text-color-placeholder: #a8abb2;--el-text-color-disabled: #c0c4cc;--el-border-color: #dcdfe6;--el-border-color-light: #e4e7ed;--el-border-color-lighter: #ebeef5;--el-border-color-extra-light: #f2f6fc;--el-border-color-dark: #d4d7de;--el-border-color-darker: #cdd0d6;Ant Design：https://ant.design/components/overview-cn/html {--ant-primary-color: #1890ff;--ant-primary-color-hover: #40a9ff;--ant-primary-color-active: #096dd9;--ant-primary-color-outline: rgba(24, 144, 255, .2);--ant-primary-1: #e6f7ff;--ant-primary-2: #bae7ff;--ant-primary-3: #91d5ff;--ant-primary-4: #69c0ff;--ant-primary-5: #40a9ff;--ant-primary-6: #1890ff;--ant-primary-7: #096dd9;--ant-primary-color-deprecated-pure: ;--ant-primary-color-deprecated-l-35: #cbe6ff;--ant-primary-color-deprecated-l-20: #7ec1ff;--ant-primary-color-deprecated-t-20: #46a6ff;--ant-primary-color-deprecated-t-50: #8cc8ff;--ant-primary-color-deprecated-f-12: rgba(24, 144, 255, .12);--ant-primary-color-active-deprecated-f-30: rgba(230, 247, 255, .3);--ant-primary-color-active-deprecated-d-02: #dcf4ff;以上截取的部分 Token 基本是在 Github 上开源社区能找到相关的代码。如果我们想要找一个非开源的设计系统的 Token 怎么找呢？这里以飞书为例，个人觉得飞书整体的配色非常舒适，想要研究一下其中的 Token 是怎么制定的。首先打开飞书网页，按 F12，选中任意元素，便可在“样式”中找到飞书产品所有的 Token 是如何命名，以及可以分析研究其中的色彩运用规律。飞书 Token：www.feishu.cn--bg-base: var(--N100);--bg-base-raw: var(--N100-raw);--bg-body: var(--N00);--bg-body-raw: var(--N00-raw);--bg-body-overlay: var(--N50);--bg-body-overlay-raw: var(--N50-raw);--bg-content-base: #f8f9fa;--bg-content-base-raw: 248,249,250;--bg-filler: var(--N200);--bg-filler-raw: var(--N200-raw);--bg-float: var(--N00);--bg-float-raw: var(--N00-raw);--bg-float-base: var(--N100);--bg-float-base-raw: var(--N100-raw);--bg-float-overlay: var(--N50);--bg-float-overlay-raw: var(--N50-raw);--bg-float-push: rgba(var(--N00-raw),0.8);--bg-mask: rgba(0,0,0,0.4);--bg-mask-raw: 0,0,0;Token 命名规则总结通过上面的大厂 Token 参考我们可以分析出一些普适性的规则：1. 单词之间用“-”分隔；2. Token 前缀可自定义添加自己产品的简称，例如：“–el-xx”、“–ant-xx”、“–td-xx”；3. Token 可以套 Token，例如：–td-brand-color-hover: var(–td-brand-color-7)；3. 整理 Design Token 资产表分析完各个大厂的 Token 规则之后，接下来正式开始对自己产品的 Design Token 开始建设，首先便是整理一份 Design Token 资产表，可以用文档、表格等形式整理。这里以 TDesign 为例，需要包含 3 列：Token、Value、Describe。这份 Token 资产表整理好之后，可以在设计团队内部进行评审，通过之后再与开发进行对齐。来源： https://tdesign.tencent.com/design/color通过工具创建 Token 并联动设计文件以上主要讲的是在思维层面 Design Token 是怎么推导的，接下来重点讲一下怎么借助一些实用的工具将 Design Token 实现自动/半自动化的落地。这里主要推荐的工具是 Figma Tokens 插件，它是一款基于 Figma 的插件，相对于 Figma 右侧面板原生自带的样式外，能够实现多层级的 Token 管理，同时插件内容能够与 Figma 设计文件实现实时联动。1. 安装并运行插件插件安装地址：https://www.figma.com/community/plugin/843461159747178978/Figma-Tokens安装完成后，在 Figma 文件中打开 Figma Tokens 插件面板，并点击“Get started”，开始创建。2. 创建 Token 变量在 Color 分类处点击“+”号，将之前整理的 Design Token 资产表里的内容一个一个录入进插件当中。如何实现 Token “套娃”呢？例如我们需要创建一个“–td-brand-color”，值为“–td-brand-color-8”，只需要在 Color 值的输入框输入“{–td-brand-color-8}”或“$–td-brand-color-8”，这里通过和开发沟通，推荐使用“{ }”大括号的形式进行赋值。全部 Token 创建完成之后，点击“Create Styles”便可将插件中的样式生成到 Figma 右侧的样式面板中。同时，插件中的修改也能够与样式进行实时同步。3. 通过 JSON 代码快捷导入 Token上面的方法是需要根据 Token 对照表，通过手动的方式一个一个录入 Token，如果团队的设计师有一点代码功底，或者前端同学能够提前介入进来，直接根据 Token 对照表写一份 JSON 文件，那么也可以直接通过复制 JSON 文件里面对应到代码粘贴到 Figma Tokens 的插件当中，能够直接读取代码生成 Token 样式，并联动 Figma 文件。4. 导入 Figma 文件中已有的样式除了使用 Figma Tokens 插件一个一个创建样式以外，插件还支持从我们的 Figma 文件中已经有样式导入，我们也可以点击“Import”，再勾选“Color”、“Text”、“Shadows”一键导入文件中的样式并生成 Token。向研发交付 Design Token1. 输出 Token.json 代码文件点击顶部“JSON”，再点击“Export”，即可将插件面板的创建的 Token 导出为一个 token.json 文件，将 json 文件交付给开发，开发便可使用。若开发不知道如何使用，可以分享这个 Figma Tokens 作者发布在 Github 上的代码稍加学习，便知道如何使用了。github 地址： https://github.com/six7/figma-tokens-example-tailwindcss2. 如何更新 Token当之前定义好的 Design Token 需要增删改时，插件官方推荐的更新同步方式主要有 JSON、 http://JSONBin.io 、URL、GitHub 等几种方式，具体可查阅官方文档： https://docs.tokens.studio/sync/sync 。由于后面集中同步方式涉及到一些小门槛，这里简单介绍第一种最为通俗的更新方式就是直接通过更新 JSON 文件，可以在企业 IM 中和研发创建一个共享空间，每次 Token 有更新只需要将导出的 JSON 文件替换原有的文件即可，开发再应用新的 JSON 文件，便可实现高效便捷的更新 Token。使用 Design Token 在产品中一键换肤在一些 To B SaaS 产品当中，产品的主色可能会跟随客户公司的品牌色进行调整。使用 Design Token 便能够便捷高效地实现一键换肤。1. 首先我们会定义一个“global”基础主题，在这里将所有后面不同皮肤的颜色都写入进来；2. 在“blue”和“red”主题皮肤下，品牌色命名都为：“tr-color-primary-brand-light-default”，但是他们两个皮肤的值不同，一个是 global 中的“{–color-blue-light-6}”，一个是 global 中的“{–color-red-light-6}”；3. 在蓝色皮肤下将“blue”勾选，切换至红色皮肤，只需要勾选“red”，即可实现文件内的所有变量全局替换，同时 Figma 右侧的样式也能实时联动。结语近几年，越来越多的团队开始搭建自己公司产品的设计系统 Design System 赋能到具体产品中落地。我所在的团队也在建设一套适用于自己公司业务的设计系统，在推动设计系统落地时，便运用了 Design Token 进行落地，极大提高了公司设计和研发团队的协作效率。Design Token 给 Design System 带来了新的方式和新的可能，未来希望能够不断扩大 Design Token 的应用价值，赋能到更多的业务和产品当中，让设计系统的应用变得更便捷、更高效。我是设计师波波 Bobby He，深耕 B 端体验设计，持续学习输出中，欢迎关注私信与我交流～参考文章https://mp.weixin.qq.com/s/9LJT89vqjdVwsafDckh6Pwhttps://blog.prototypr.io/design-tokens-with-figma-aef25c42430fhttps://didoo.medium.com/how-to-manage-your-design-tokens-with-style-dictionary-98c795b938aahttps://uxdesign.cc/design-tokens-cheatsheet-927fc1404099https://docs.tokens.studio大厂出品！腾讯开源企业级设计体系 TDesignTDesign 是来自腾讯内部近 300 名设计师与开发者共同打造，经由 500+ 项目使用、验证和锤炼过的企业级设计体系， 秉承包容、多元、进化、连接的价值观，TDesign 期望与用户、行业及合作伙伴等一起打造具有竞争力的产品体验。阅读文章 > 本篇来源：优设网原文地址：https://www.uisdc.com/design-token-2
风火轮 代码 团队 58 风火轮，从今天起正式免费对外开放啦～请先记住这个网址： https://fhl.58.com。它将带你进入一个神奇的世界什么是风火轮？风火轮是 58UXD 联合前端技术委员会打造的一站式设计、产品、研发协作平台。它包含 Sketch 插件和协作平台两部分。可实时协同设计规范、承载多种类型设计资产、sketch 设计稿在线可视化、自动标注及前端代码的自动解析和生成，是一款产研协同的提效工具。风火轮经过 58 集团产研团队一年的沉淀和打磨，今天正式对外开放。这款由 58 产研团队共同创造的产研提效工具，可以帮助更多的中小型企业及个人设计师和开发者提效，体现让“生活简单美好”的企业价值观。风火轮都有什么能力？58 集团设计师 Sketch 的使用率高达 90%，因此我们选择了 Sketch 作为我们整体链路的基础。设计师使用「风火轮」插件上传设计稿到协作平台，平台通过 Picasso 这款自研的解析工具进行智能解析，不仅仅输出了设计标注，还同时生成了终端代码，高度还原设计稿的同时，满足各种场景需求。那么我们具体了解下插件和平台都是什么？1. 插件Sketch 插件：通过 Sketch 插件进入设计师的工作流程，聚合设计资产，解决设计规范落地、设计资产可视化承载，提升设计规范和设计资产的使用率，增强资源共享避免重复设计。目前为止 sketch 插件可以承载 icon 库、组件库、场景库、插画库、基础运营库资源。大家可以通过我们的制作要求，上传自己的规范。可帮助设计团队提升设计师的工作效率，也避免了大多数的重复设计，同时我们会将部分 58 集团设计资产进行开源。组件资源-icon/色彩/组件/场景/插画主要承载集团全部的设计规范和设计资产，供全体设计师共享使用。自有组件库快速生成可自己制作组件 Library，导入风火轮 Sketch 插件。导入的组件 Library 需遵循《本地 Library 资源制作规范》。上传设计稿可通过风火轮 Sketch 插件上传设计稿到风火轮协作平台，实现标注和代码解析，可直接链接分享给产品和开发同学。2. 协作平台通过风火轮协作平台进行团队管理，团队资产、项目管理，实现设计稿在线标注解析，供研发同学在线查看研发。同时还生成各种前端代码，供前端同学复制使用，缩短研发同学的工作路径，提升工作效率的同时顺应市场潮流，实现从设计到代码的愿景。团队与项目风火轮协作平台的团队项目，采用团队—（文件夹）—项目—分组—画板的层级进行设计稿的管理。项目是从属于团队的。想使用项目相关功能，需要先创建/加入一个团队。为便于管理，一个团队下可建立多个项目。项目文件管理项目可存在于任何一级文件夹下。团队成员均可进行项目管理。项目文件中承载了项目中的全部内容（设计稿、切图、源文件、代码等）。多方协作-编辑器编辑器页面可进行设计稿画板标注/代码信息查看、设计图/切图下载。每个画板提供了标注模式和代码模式两种视图。在标注模式下，可以查看图层的尺寸、位置、字体、文本内容、样式等信息，可以复制并使用标注样式代码；如果是切图，则可以下载对应的不同尺寸、格式的图片。在代码模式下可查看平台解析当前画板，所生成的全部代码，可一键复制使用。代码生成在上传设计稿时选择生成代码，在协作过程中，平台会展示，整个设计项目的全部代码，供研发同学使用。我们目前生成的代码，高精度的还原了设计稿。风火轮在 58 集团的使用情况「风火轮」自从 2020 年 12 月 30 日上线以来，逐步覆盖了全公司所有的产研团队，包括安居客、驾校一点通、58 数科等公司，成为集团产研提效的协作平台，并且得到内部团队较高的评价。「风火轮」上线的一年时间里，我们快速响应迭代，通过多个版本的更新优化，使其达到了一个稳定且持续更新的状态。目前「风火轮」插件在公司内部承载了 8000 多个可复用的设计资产，解决了大多数重复设计、开发的状态，累计节省设计时长 30000+小时。通过自动化解析生成代码量超过 5000+，生成图片量 200W+，累计节省研发时长 6000+小时，提升整体协同效率 30%。风火轮开放情况网址： https://fhl.58.com ，这是我们风火轮协作平台的网址，大家可以下载插件进行使用。同时我们也开放了部分设计资产，为广大设计师提效。未来我们会开放更多的功能和资源来为大家服务，请大家多多关注。欢迎关注「58UXD」的微信公众号： 文件名 如何下载使用 文件大小 提取码 下载来源 风火轮 Sketch 插件打包521kb2333 点此复制 登录下载 本篇来源：优设网原文地址：https://www.uisdc.com/hot-wheel
产品 代码 视觉 前言：在 2020 年，疫情最为严峻的时候，B 端这一领域得到了前所未有的关注，而那时，身为 B 端用户体验设计师的我，也曾总结过，当时 B 端设计的诸多趋势，比如：多端需求：即桌面端、平板端、移动端的设计形式设计中台：拥有更为统一的设计平台，与这两年讨论较多的设计资产相同，都是起到快速协作的作用随着 2022 年的到来，B 端行业又会迎来哪些新的机会？今天我们就从整个的 B 端入手，回顾一下 2021 年的设计形式，展望一下 2022 年的设计趋势。当然趋势完全是我自己个人主观理解，仅供参考，如有异议，以你为准~完整的趋势，我们会分为视觉趋势与产品趋势：视觉趋势：主要围绕设计当中的细节展开，比如图标、色彩、字体、插画等产品趋势：主要是了解不同的 B 端产品当中究竟有哪些发展形式，对于设计师又会产生何种影响？视觉趋势1. 3D 设计风格虽然 3D 化的视觉风格早已到来，但是在 B 端市场上，3D 风格在此之前依旧表现的十分克制。随着 C4D、Blender 这些 3D 建模软件的不断普及，再加上互联网上关于 3D 建模教程的增多，你会发现 3D 风格的视觉表现，是一个 B 端视觉设计师的基本要求。而 3D 风格用在 B 端软件当中，会有两个使用场景：图标因为在 B 端产品当中，图标本身就是非常难以去表现，比如“物联网，大数据”，许多抽象词汇很难通过一个具象的事物进行表达，而在企业官网当中，在视觉表现上的要求又十分的高。因此你会发现，在视觉风格上的选择，往往只有 3D 图标 + 插画这一条路。并且 3D 图标的使用场景不会太过于局限，也可以用于产品的工作台、运营营销工具箱等页面，因此 3D 图标的出现，它的应用场景也会相比之前要更加的广阔。可视化大屏大屏设计也在不断的“内卷”，因为传统的 2D 可视化大屏所搭建出来的大屏已经满足不了企业的野心， 像 DataV 腾讯云图 ，大家都在朝着 3D 风格，炫酷的方向进行延展，因此也就会导致 3D 的视觉风格需求激增，而 3D 建模仿佛就是大势所趋。2. 新拟态虽然新拟态是在前两年的产物。这个设计风格背后，遭到了很多设计师的质疑与排挤。但是随着这个风格的不断成熟，感觉它在 B 端视觉领域（特指的是官网 ），是非常受欢迎的，因为整体的风格，与官网的设计形式趋同。同时作为 B 端产品的官网，其实是更需要新拟态这种风格。因为电脑场景下鼠标光标对页面进行 Hover 操作给出的真实反馈，而使用了新拟态的官网按钮，给你的反馈非常真实。这里安利一下腾讯云的首页官网，大家就会发现在设计风格上大量的采取了新拟态元素，并且配合 3D 风格的图标，以及毛玻璃材质的设计，让它的设计瞬间加分不少。3. 开源的设计系统在去年，设计系统迎来了一波发展的高峰期，随着字节、腾讯，三大设计系统（Arco Design、TDesign、Semi Design）的开源，其实是给我们很多 B 端设计初学者，有了更加完整仔细的 B 端入门教程。比如 Arco Design 的组件用法 https://arco.design/docs/spec/link清晰的讲解了每一个组件的使用方式，以及注意事项，仔细阅读这里面的内容，其实就是 B 端设计的入门学习。而未来，国内的环境，开源的系统也会越来越多，大家可以针对这几大类不同的设计系统进行对比，或许会有一番收获。产品趋势4. 超级 app这里的超级 app 可能和大家潜意识里的支付宝、微信这些软件不太一样在 B 端行业，随着疫情的不断扩散、再加上两年时间的发展，很多 B 端产品的功能架构都出现了一个现象，产品的功能开始变得非常拥挤。因为 B 端软件的核心价值其实就是靠着一个又一个功能去累积，也就意味着随着 B 端产品的发展，功能模块在不断的累积，导致在设计层面，这样的现象变得更加严峻。你会发现左侧的导航菜单已经完全没有办法装下这些导航内容，而这一现象也反映在很多产品当中，比如我了解的飞书管理后台、薪人薪事 等等诸多 B 端产品，它们在整个导航内容上，已经增加到一级导航 15+ 、二级导航 40+ ，这无疑会开始对设计师的能力造成巨大考验。面对这一情况，许多导航菜单都将会迎来前所未有的挑战，最近也在深入研究导航菜单过多时的解决办法，发现了一些新的导航菜单设计方法，有机会咱们重新梳理一下导航菜单的内容，将 B 端设计指南文章进行更新。6000 字干货！B端产品的导航菜单设计5步法导航菜单对于用户的使用来说尤为重要，本文是我从实际工作出发，结合自身产品和过去经验对于导航进行的一次全面总结。阅读文章 > 低代码定制化低代码一直是我关注的一个领域，先给不明白低代码的同学简单科普一下。低代码，一种快速开发应用的软件，将通用、可重复利用的代码形成组件化的模块，通过图形化的界面来拖拽组件并形成应用。低代码能够实现只写少量代码或不写代码，类似用“乐高积木”的方式来开发。在国外有很多著名的低代码成功案例。Outsystems（国外非常出名的低代码平台）帮助施耐德电气在 20 个月内推出了 60 款应用程序，开发过程加速了两倍；在 2012 年即将推出 Model S 之际，特斯拉放弃了 SAP 的 ERP 产品（可以思考一下为什么），改用低代码开发平台 Mendix，用 25 个人四个月时间自建 ERP 系统。去年，低代码平台，也有很多新产品面世，其中就包含：因此你会发现，其实低代码就是在解决一件事，围绕着某一个业务场景，通过平台的持续完善优化。让所有的功能都能围绕这个业务展开，其中包括：权限、时间轴、流程、表单、公式等等，能够解决很多特殊的业务场景。而低代码会涉及到设计思路上的转变，以及低代码编辑器的出现，如何去设计如此复杂的配置流程，如何让用户能够快速上手，如果你能够有比较完整的思路，这些都会成为我们设计的新机会。行业细分随着互联网市场的不断发展，用户会越来越关注产品在自己行业的应用，比如 CRM，其实只是一个笼统的称呼，现在 CRM 市场又会分为 SCRM、运营 CRM，等诸多产品。SaaS 类的平台也出现了负责从虚拟主机和数据库层面入手的 iPaaS 以及从应用和数据层面入手的 aPaaS。即使是大家经常使用的 钉钉、企微、飞书，它们也在各自的领域有所擅长。因为 B 端产品，在底层逻辑上是不能允许趋同的产品出现，如果你和别人的产品一样，其实是没有办法在目前的市场上立足。因此你会发现，虽然产品形式都会比较相同，但是 B 端市场十分广阔，大家都在去寻找自己产品的差异化。当然市场是瞬息万变的，这里也只是简单聊聊我自己的看法，希望对你有所帮助。5000 字干货！超全面的B端设计规范总结不知不觉已经深耕在 B 端这个领域 3 年有余，很多人接触过 B 端后会觉得乏味，因为 B 端的设计在视觉上并没有 C 端那么有冲击力，更多的是结合业务逻辑，设计出符合业务需求的交互，以及界面排版的合理性，达到产品的可用性、易用性、好用性。阅读文章 > 欢迎关注作者的微信公众号：CE青年交互设计本篇来源：优设网原文地址：https://www.uisdc.com/2022-b-end-design-trends
标签 代码 C++ css 中 nth-child、first-child、last-child 的使用（选中第一个，第几个，第几个到第几个，最后一个等）可以配合 li 标签使用，选择一列中的哪些标签。 1.first-child 选择列表中的第一个标签 2. last-child 选择列表中的最后一个标签li:first-child{color:red}li:last-child{color:pink} 3.nth-child(n)这里的n为数字，表示选择列表中的第n个标签例如选择第三个标签li:nth-child(3){color:pink}4.nth-child(2n) 选择列表中的偶数，选中 2、4、6…… 个标签。li:nth-child(2n){color:pink}li:nth-child(2n-1){color:pink}5.同理.nth-child(2n-1)就表示选中了奇数位标签6.选择从第4个到最后一个标签，这个4可以提换成你需要的数字li:nth-child(n+4){color:pink}7. 选择从第一个到第四个 这里的数字4也是可以根据你的需要替换的。li:nth-child(-n+4){color:pink}8.nth-last-child(3) 表示最后三个标签li:nth-last-child(3){color:pink}9.nth-last-child(3n) 表示3的倍数3.6.9……li:nth-last-child(3n){color:pink}10.nth-last-child(3n-1) 表示2.5.8…… 可以用这个设置等差数列的样式li:nth-last-child(3n-1){color:pink}希望有帮到你。
落霞与孤鹜
在路上
小编
