背景去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。没有计划的阅读，收效甚微。新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。这个“玩法”虽然常见且板正，但是有效。已读完书籍：《架构简洁之道》。当前阅读周书籍：《深入浅出的Node.js》。模块机制CommonJS 规范CommonJS 规范的提出，主要是为了弥补当前 J
背景去年下半年，我在微信书架里加入了许多技术书籍，各种类别的都有，断断续续的读了一部分。没有计划的阅读，收效甚微。新年伊始，我准备尝试一下其他方式，比如阅读周。每月抽出1~2个非连续周，完整阅读一本书籍。这个“玩法”虽然常见且板正，但是有效。已读完书籍：《架构简洁之道》。当前阅读周书籍：《深入浅出的Node.js》。Node 简介了解它：Node 是什么Node，一个强制不共享任何资源的单线程、单
背景前段时间我整理了一篇开发设计文档的经验——《磨刀不误砍柴工，分享编写前端技术设计文档的二三经验》，做为对于2023年的收尾。2024年1月，一年之初，正是立Flag的好时机。因为我今年有几本小说作品的计划，所以被分去了一部分写作精力。有限的精力，想要发挥更高的效率，还是需要一些策略，于是我想到了可以借鉴一下总结开发设计文档的经验。每月中的某一周阅读一本技术图书，然后再用一周时间产出技术收获。这
背景过去的一年，我完成了很多业务场景的开发。因为有编写开发设计文档的习惯，所以在年初做整理的时候，打开文档列表，能够很容易的找到过去的每一个设计方案。于是，借着休息日的时光，整理了部分功能，编写成完整的文章，分享出来。今天分享一篇关于通过功能描述与拆分进而捋清开发设计方案的业务场景实现方案。购买须知功能购买须知业务组件1、功能描述1.1 必需校验每次重新进入都需要进行购买须知1.2 购买须知状态的
背景即便是已经开发过数不清的业务功能，在遇到下面这种情况的时候，第一感觉还是“一个头两个大”。得想个办法先简化功能内容，再进行方案设计，方能实现务场景从繁琐到简单的蜕变。简单的思维转换越是繁琐的业务场景越需要梳理经络，经络捋顺清楚，开发方案也就八九不离十了。操作按钮展示规则通过需要判断的值的数组、逻辑运算符、关系运算符，最终确定是否展示布尔值。1、逻辑运算符将逻辑运算转换成数组对应的方法|| (或
项目管理协同经验之谈在分享经验之前，我们先来思考一个问题：如何能够花费较少的成本去实现既定目标？这个问题产生的主要原因为：在我们的项目管理中，人力资源是相对固定的。所以抛开人力成本，时间成本是影响既定目标的一个较大的因素。在项目启动到上线的周期中，时间占比较多的主要是项目前期准备时间、项目中期的需求同步时间、项目中后期的研发时间。使用第一性原理思维之前读到的一篇文章给了我很大的启发：可以借助第一性
背景在正式攻略“项目管理协同”这个副本之前，我问了自己几个问题（这也是我遇到首次接触的新事物，为了快速进入状态常用的方式之一）：什么是项目？什么是项目管理？什么是项目管理协同？项目管理协同的目的是什么？带着这些疑问，我请教了身边有项目管理经验的朋友，在她的推荐下，读了几本书：《微权力下的项目管理:如何在有责无权的状况下带领项目团队获得项目成功 (第2版)》（以下简称《微权力下的项目管理》）、《极简
前言在日常的开发中，我们时长会遇到以下两个问题：开发频繁被打断，怎么保障实现既定的开发目标？需求插队，打乱排期并导致研发堵塞？我尝试摸索解决问题的方案，经过不断的优化、完善，形成了下面的解决方案。“小步快跑”的任务池对于临时插入的需求，可能会导致研发过程减慢，对此的策略是：将需求放入任务池，并区分需求的类型，然后进入需求处理流程，得到最终结果之后，更新任务池最新状态。研发会自驱的拉动任务池的循环。
前言我从2021年开始编写前端开发设计文档至今，粗略数了数，已经有60+篇文档。这期间，从文档标题到文件分类都有了细微的变化。文档标题上：我和上线单的标题对齐了，如何可以区分版本的，我会加上当期版本。文件分类上：我区分了业务场景分类，方便快速找到某一期的需求。文档内容上：最开始主要包含三个方面：任务拆分、功能设计、开发排期。随着经验的积累以及对他人经验的学习，我在设计文档的内容上做了升级，下面会详
顺手就是一套 callback业务场景在最新一期的需求中，我需要在所有的购买入口，添加"阅读购买须知"的模块。"阅读购买须知"的模块主要包括两部分内容：购买须知按钮和提示文案。提交购买时，也需要增加对应的校验：是否已经进行了阅读操作。如果未操作，给出提示且不能进行下一步操作；如果已操作，可以继续下一步操作。UI 展示效果组件化设计按照代码复用的设计理念，我将"购买须知"模块进行了组件化设计。下单操
认识 Houdini：源自一场"邂逅"吃饭看书刷视频，修身养性三件套。遇到论坛就想逛一逛，遇到知识点就想用一用。这不，这天我正闲心，所以所以刷了刷 MDN 的网站。点到Web 开发者指南这页下，看到了一个有点陌生的词汇——CSS Houdini。我顺着自己的"脑机接口",翻了翻脑袋里的前端知识库，没什么印象。没印象没关系，可以现学。了解 Houdini：全方位扫描中Houdini 是一组底层 AP
前言之前对后台系统的数据权限进行了深入的探索，发现了存在的一些问题。本篇着重从表格数据权限聊起，讲一下表格数据权限的兜底策略实现方案。表格数据权限的兜底权限控制不了"手动挡"，但是前端可以。虽然有些后知后觉，但是我登时就想到了两种兜底方案。方案一：表格组件增加必须入参的校验该方案很适合，已经二次封装了表格组件。我们在引入了第三方UI库之后，会使用UI库提供的表格组件，节省开发成本。其实，还可以根据
为什么提边界？除了上面提到的，有些过度设计导致的不容易找到修改位置，代码阅读不便。还有一个同样重要的问题。那就是老代码改动不全或现有功能不兼容。如果没注意到这个问题，且提测的时候没有进行特别的说明，可能导致线上Bug的发生。复用设计，不同之处也很重要这个单拎出来写，是因为之前吃过亏。前面提到了功能设计可能会带来的三个问题，其中第一个问题，对于复杂的功能，一味的关注相同之处，去做逻辑复用，导致后续出
故事是这样开始的很久很久以前，我关注的一个游戏博主，发了一个游戏视频。然后我就见识到了什么叫，「游戏叫你一步噶，你绝对走不到第二步」。这个带那么点整蛊的性质的脑洞游戏，瞬间引起了我浓厚的兴趣。需要玩家克服大脑常规套路的惯性，那岂不是游戏处处是惊喜。不过，游戏的本质还是在于趣味性，玩家掌握了规律之后，还是可以通关的。等等，有没有无法通关的游戏？这不就来了么，被「愚弄」智商的愉乐游戏，不设计一个怪浪费
背景目前我们的多端项目中的小程序开发，每次都要手动在开发者工具中进行上传操作，并填写版本信息。我计划实现小程序端的自动化发布，正好川哥有一篇相关工具库的文章。文章中提到了两个第三方库，我都可以直接用。但是，终于要提到本篇的主题了。在自动化发布之后，开发者为 ci 机器人的名称，如下图：这样一来，没办法知道具体是哪位开发者提交的版本。于是，我接受建议，采用获取 Git 仓库里协作者用户名+拼接到项目
前言不知不觉中，源码的文章也写了几期了，每一期都能多少有些收获。原本，我在看 remote-git-tags 源码之前，计划带着 3W 的思维去看。但是，我有了一瞬间的停顿。这个库的源码不是很多，是不是可以改变个思维。当已知库的实际用途的情况下，是不是可以反向推导出实现方案。没准，过程中能时不时来个惊喜。功能测试先来看一下，remote-git-tags 具体是干什么的。1、先生成 package
常用图片资源类型我们项目里目前主要有三种图片资源类型第三方图片资源、本地SVG、本地base64这三种对应不同的使用场景：对于图片画质要求较高、图片内容较复杂的，一般都是将图片资源放到第三方图床上，页面展示通过加载远程地址的方式；小的 icon 图标，首选 SVG 格式，文件体积小，加载更快速。但是实现成本比较大，一般情况需要设计师的支持；base64，某些特殊功能实现下需要的格式，不常见 ，但是
前言await-to-js 的源码较少，代码较少的情况，可以尝试采用 3W 方法进行源码分析，帮助快速了解它的实际应用场景。阅读本文，会有以下收获：了解 await-to-js 库能解决什么问题。分析 await-to-js 库是如何解决问题。摸索 await-to-js 库的实际使用场景。Why：await-to-js 诞生的契机打开它的 github 地址，有很简单的一句介绍：Async aw
前言本篇主要分享如何实现一个弹窗展示形式的6位卡号输入功能。6位卡号输入前面是根据卡的不同状态的流程实现，接下来，讲讲卡号输入的交互实现。卡号输入 UIUI 的呈现，会影响前端的实现方式。这里 UI 设计成弹出层的方式，每个数字都是一个方框。开发前在开发前，我列了一些可能出现的问题。比如，不同手机的光标样式、输入时页面抖动、input无法只输入数字等。所以我在实现的时候，有针对性的规避前面罗列的问
前言前面提到了可以使用yocto-queue库代替Array操作数组，本篇则深入源码了解一下yocto-queue是如何实现替代数组的。yocto-queue源码分析源码中的代码量相对较少，读起来会比较轻松，看似可以琢磨的点少，其实不然。代码中包含知识点主要包括类的属性、链表与数组的对比、队列、自定义迭代器等，容我细讲。git 地址：yocto-queueNode 类node 类的作用是在新增操作
前言对于数组类型的数据处理，对 Array 方法的时间复杂度的问题，没有深入研究。最近有时间正好研究了一把，看有没有比较好的替代方式 。前端关于性能问题，一直十分关注。提升性能的方式有很多，有时候一个简单的数据操作，前端开发者们也会“货比三家”，尤其是对数据的处理，总是在对比性能，时间复杂度是衡量标准之一。后来发现了一个第三方库yocto-queue 库或许可以解决我的困惑，开研究一下吧。yoct
前言某天正在研读源码，突然发现一个有趣的代码段。这个代码段里包含一个运算，运算符是“**”。一般优先级相同的运算符做运算的时候，从左到右运算，不会添加额外的符号，比如小括号。通常是不同优先级的运算符做运算，才会为了保障运算结果的正确，添加小括号。所以这看似多余的代码，但是并不影响代码的正常运行，这是什么情况？让我们来一探究竟吧。** 运算符，相同运算符还要小括号？编程欢乐小剧场某：咦？一：干什么？
前言本文主要讲解 classnames 相关的知识点。对 classnames 源码，按照功能模块进行解读。尤其对于源码中关键代码从实现层面做了解读。 在总结过程中，对 CSS-in-JS 写法有了不同的想法，结合大佬的文章，将想法记录在了文末。classnames 的原理源码目录功能模块目录结构classnames ┣ ?benchmarks ┃ ┣ ?fixtures.js ┃ ┣ ?
前言通过axios 源码阅读，实现formDataToJSON 抽丝剥茧 formData 与 Object 的转换，接下来详细分享整个过程。formDataToJSON 抽丝剥茧 formData 与 Object 的转换FormData 对象FormData 对象用以将数据编译成键值对，以便用XMLHttpRequest来发送数据。FormData 对象主要用于发送表单数据，但亦可用于发送带键
前情提要目前的多端项目，在代码发布的时候，对于不同的端，需要进行不同的操作。尤其小程序端，每次都要在开发者工具中进行一次：上传->填写版本信息->提交审核(确定上线时)既然手动这么麻烦，能不能做成自动的？让开发节省重复操作时间，同时避免手动操作遗漏的可能性。我翻阅资料，发现已经有大佬实现了上面的功能，我只需要站在巨人的肩膀上，结合实际需要，做些细微的调整即可。功能计划目前想要的功能比较
前言第一遍看 axios 源码，更多的是带着日常开发的习惯，时不时产生出点联想。第二遍再看 axios 源码，目标明确，就是奔着函数来的。当有了明确清晰的目标，阅读速度上来了，思绪也转的飞快。而本篇，主要是对standardBrowserEnv 标准浏览器中对 cookie 的读写删操作的思考。standardBrowserEnv 标准浏览器中对 cookie 的读写删操作一般基础的工具函数都会放
前言我们日常开发使用的是React框架，主要采用JSX写法，而classnames与JSX十分般配，组合使用效果极佳，可以实现class的动态绑定。接下来，通过对 classnames 源码的阅读，来进一步了解classnames出现的契机及其用法。听说你叫 className讲 classnames 之前，科普一点关于它「兄弟」 className 的知识点。万物皆有源之 JSX众所周知，在 R
Copyright © 2005-2025 51CTO.COM 版权所有 京ICP证060544号
