之前写过一篇文章 我理想中的低代码开发工具的形态，已经吐槽了各种封装 xxxForm，xxxTable 的行为，这里就不啰嗦了。今天再来看看我的工具达到了什么程度。

多图预警。。。

以管理后台一个列表页为例

选择对应的模板

截图查询区域，使用 OCR 初始化查询表单的配置

截图表头，使用 OCR 初始化 table 的配置

使用 ChatGPT 翻译中文字段

生成代码

效果

目前我们没有写一行代码，就已经达到了如下的效果

下面是一部分生成的代码

import { reactive, ref } from 'vue'



import { IFetchTableListResult } from './api'



interface ITableListItem {

  /**

   * 决算单状态

   */

  settlementStatus: string

  /**

   * 主合同编号

   */

  mainContractNumber: string

  /**

   * 客户名称

   */

  customerName: string

  /**

   * 客户手机号

   */

  customerPhone: string

  /**

   * 房屋地址

   */

  houseAddress: string

  /**

   * 工程管理

   */

  projectManagement: string

  /**

   * 接口返回的数据，新增字段不需要改 ITableListItem 直接从这里取

   */

  apiResult: IFetchTableListResult['result']['records'][0]

}



interface IFormData {

  /**

   * 决算单状态

   */

  settlementStatus?: string

  /**

   * 主合同编号

   */

  mainContractNumber?: string

  /**

   * 客户名称

   */

  customerName?: string

  /**

   * 客户手机号

   */

  customerPhone?: string

  /**

   * 工程管理

   */

  projectManagement?: string

}



interface IOptionItem {

  label: string

  value: string

}



interface IOptions {

  settlementStatus: IOptionItem[]

}



const defaultOptions: IOptions = {

  settlementStatus: [],

}



export const defaultFormData: IFormData = {

  settlementStatus: undefined,

  mainContractNumber: undefined,

  customerName: undefined,

  customerPhone: undefined,

  projectManagement: undefined,

}



export const useModel = () => {

  const filterForm = reactive<IFormData>({ ...defaultFormData })



  const options = reactive<IOptions>({ ...defaultOptions })



  const tableList = ref<(ITableListItem & { _?: unknown })[]>([])



  const pagination = reactive<{

    page: number

    pageSize: number

    total: number

  }>({

    page: 1,

    pageSize: 10,

    total: 0,

  })



  const loading = reactive<{ list: boolean }>({

    list: false,

  })



  return {

    filterForm,

    options,

    tableList,

    pagination,

    loading,

  }

}



export type Model = ReturnType<typeof useModel>

这就是用模板生成的好处，有规范，随时可以改，而封装 xxxForm，xxxTable 就是一个黑盒。

原理

下面大致说一下原理

首先是写好一个个模版，vscode 插件读取指定目录下模版显示到界面上

每个模版下可能包含如下内容：

选择模版后，进入动态表单配置界面

动态表单是读取 config/schema.json 里的内容进行动态渲染的，目前支持 amis、form-render、formily

配置表单是为了生成 JSON 数据，然后根据 JSON 数据生成代码。所以最终还是无法避免的使用私有的 DSL ，但是生成后的代码是没有私有 DSL 的痕迹的。生成代码本质是 JSON + EJS 模版引擎编译 src 目录下的 ejs 文件。

为了加快表单的配置，可以自定义脚本进行操作

这部分内容是读取 config/preview.json 内容进行显示的

选择对应的脚本方法后，插件会动态加载 script/index.js 脚本，并执行里面对应的方法

以 initColumnsFromImage 方法为例，这个方法是读取剪贴板里的图片，然后使用百度 OCR 解析出文本，再使用文本初始化表单

initColumnsFromImage: async (lowcodeContext) => {

    context.lowcodeContext = lowcodeContext;

    const res = await main.handleInitColumnsFromImage();

    return res;

  },

export async function handleInitColumnsFromImage() {

  const { lowcodeContext } = context;

  if (!lowcodeContext?.clipboardImage) {

    window.showInformationMessage('剪贴板里没有截图');

    return lowcodeContext?.model;

  }

  const ocrRes = await generalBasic({ image: lowcodeContext!.clipboardImage! });

  env.clipboard.writeText(ocrRes.words_result.map((s) => s.words).join('\r\n'));

  window.showInformationMessage('内容已经复制到剪贴板');

  const columns = ocrRes.words_result.map((s) => ({

    slot: false,

    title: s.words,

    dataIndex: s.words,

    key: s.words,

  }));

  return { ...lowcodeContext.model, columns };

}

反正就是可以根据自己的需求定义各种各样的脚本。比如使用 ChatGPT 翻译 JSON 里的指定字段，可以看我的上一篇文章 TypeChat、JSONSchemaChat实战 - 让ChatGPT更听你的话

再比如要实现把中文翻译成英文，然后英文使用驼峰语法，这样就可以将中文转成英文代码变量，下面是实现的效果

选择对应的命令菜单后 vscode 插件会加载对应模版里的脚本，然后执行里面的 onSelect 方法。

main.ts 代码如下

import { env, window, Range } from 'vscode';

import { context } from './context';



export async function bootstrap() {

  const clipboardText = await env.clipboard.readText();

  const { selection, document } = window.activeTextEditor!;

  const selectText = document.getText(selection).trim();

  let content = await context.lowcodeContext!.createChatCompletion({

    messages: [

      {

        role: 'system',

        content: `你是一个翻译家，你的目标是把中文翻译成英文单词，请翻译时使用驼峰格式，小写字母开头，不要带翻译腔，而是要翻译得自然、流畅和地道，使用优美和高雅的表达方式。请翻译下面用户输入的内容`,

      },

      {

        role: 'user',

        content: selectText || clipboardText,

      },

    ],

  });

  content = content.charAt(0).toLowerCase() + content.slice(1);

  window.activeTextEditor?.edit((editBuilder) => {

    if (window.activeTextEditor?.selection.isEmpty) {

      editBuilder.insert(window.activeTextEditor.selection.start, content);

    } else {

      editBuilder.replace(

        new Range(

          window.activeTextEditor!.selection.start,

          window.activeTextEditor!.selection.end,

        ),

        content,

      );

    }

  });

}

使用了 ChatGPT。

再来看看，之前生成管理后台 CURD 页面的时候，连 mock 也一起生成了，主要逻辑放在了 complete 方法里，这是插件的一个生命周期函数。

因为 mock 服务在另一个项目里，所以需要跨目录去生成代码，这里我在 mock 服务里加了个接口返回 mock 项目所在的目录

.get(`/mockProjectPath`, async (ctx, next) => {

    ctx.body = {

      status: 200,

      msg: '',

      result: __dirname,

    };

  })

生成代码的时候请求这个接口，就知道往哪个目录生成代码了

const mockProjectPathRes = await axios

      .get('http://localhost:3001/mockProjectPath', { timeout: 1000 })

      .catch(() => {

        window.showInformationMessage(

          '获取 mock 项目路径失败，跳过更新 mock 服务',

        );

      });

    if (mockProjectPathRes?.data.result) {

      const projectName = workspace.rootPath

        ?.replace(/\\/g, '/')

        .split('/')

        .pop();

      const mockRouteFile = path.join(

        mockProjectPathRes.data.result,

        `${projectName}.js`,

      );

      let mockFileContent = `

			import KoaRouter from 'koa-router';

			import proxy from '../middleware/Proxy';

			import { delay } from '../lib/util';



			const Mock = require('mockjs');



			const { Random } = Mock;



			const router = new KoaRouter();

			router{{mockScript}}

			module.exports = router;

			`;



      if (fs.existsSync(mockRouteFile)) {

        mockFileContent = fs.readFileSync(mockRouteFile).toString().toString();

        const index = mockFileContent.lastIndexOf(')') + 1;

        mockFileContent = `${mockFileContent.substring(

          0,

          index,

        )}{{mockScript}}\n${mockFileContent.substring(index)}`;

      }

      mockFileContent = mockFileContent.replace(/{{mockScript}}/g, mockScript);

      fs.writeFileSync(mockRouteFile, mockFileContent);

      try {

        execa.sync('node', [

          path.join(

            mockProjectPathRes.data.result

              .replace(/\\/g, '/')

              .replace('/src/routes', ''),

            '/node_modules/eslint/bin/eslint.js',

          ),

          mockRouteFile,

          '--resolve-plugins-relative-to',

          mockProjectPathRes.data.result

            .replace(/\\/g, '/')

            .replace('/src/routes', ''),

          '--fix',

        ]);

      } catch (err) {

        console.log(err);

      }

mock 项目也可以通过 vscode 插件快速创建和使用

上面展示的模版都放在了 github.com/lowcode-sca… 仓库里，照着 README 步骤做就可以使用了。

故事是这样的

领导：小李，你加的水印怎么还能被删掉的？这可是关乎公司信息安全的大事！这种疏忽怎么能不扣工资呢？

小李：领导，请您听我解释一下！我确实按照常规的方法加了水印，可是……

领导：（打断）但是什么？难道这就是你对公司资料的保护吗？

小李：我也不明白，按理说水印是无法删除的，我会再仔细检查一下……

领导：我不能容忍这样的失误。这种安全隐患严重影响了我们的机密性。

小李焦虑地试图解释，但领导的目光如同刀剑一般锐利。他决定，这次一定要找到解决方法，否则，这将是一场职场危机……

水印组件

小李想到antd中有现成的水印组件，便去研究了一下。即使删掉了水印div，水印依然存在，因为瞬间又生成了一个相同的水印div。他一瞬间想到了解决方案，并开始了重构水印组件。

原始代码

//app.vue

<template>

  <div>

    <Watermark text="前端百事通">

      <div class="content"></div>

    </Watermark>

  </div>

</template>



<script setup>

import Watermark from './components/Watermark.vue';

</script>





<style scoped>

.content{

  width: 400px;

  height: 400px;

  background-color: aquamarine;

}

</style>

//watermark.vue

<template>

  <div ref="watermarkRef" class="watermark-container">

    <slot>



    </slot>

  </div>



</template>



<script setup>

import { onMounted, ref } from 'vue';

const watermarkRef=ref(null)

const props = defineProps({

  text: {

    type: String,

    default: '前端百事通'

  },

  fontSize: {

    type: Number,

    default: 14

  },

  gap: {

    type: Number,

    default: 50

  },

  rotate: {

    type: Number,

    default: 45

  }

})

onMounted(() => {

  addWatermark()

})

const addWatermark = () => {

  const { rotate, gap, text, fontSize } = props

  const color = 'rgba(0, 0, 0, 0.3)'; // 可以从props中传入 

  const watermarkContainer = watermarkRef.value;



  const canvas = document.createElement('canvas');

  const context = canvas.getContext('2d');

  const font=fontSize+'px DejaVu Sans Mono'

  // 设置水印文字的宽度和高度  

  const metrics = context.measureText(text);

  const canvasWidth=metrics.width+gap

  canvas.width=canvasWidth

  canvas.height=canvasWidth

  // 绘制水印文字  

  context.translate(canvas.width/2,canvas.height/2)

  context.rotate((-1 * rotate * Math.PI / 180));

  context.fillStyle = color;

  context.font=font

  context.textAlign='center'

  context.textBaseline='middle'

  context.fillText(text,0,0)

  // 将canvas转为图片  

  const url = canvas.toDataURL('image/png');

  // 创建水印元素并添加到容器中  

  const watermarkLayer = document.createElement('div');

  watermarkLayer.style.position = 'absolute';

  watermarkLayer.style.top = '0';

  watermarkLayer.style.left = '0';

  watermarkLayer.style.width = '100%';

  watermarkLayer.style.height = '100%';

  watermarkLayer.style.pointerEvents = 'none';

  watermarkLayer.style.backgroundImage = `url(${url})`;

  watermarkLayer.style.backgroundRepeat = 'repeat';

  watermarkLayer.style.zIndex = '9999';

  watermarkContainer.appendChild(watermarkLayer);

}

</script>



<style>

.watermark-container {  

  position: relative;  

  width: 100%;  

  height: 100%;  

  overflow: auto;  

}  

</style>

防篡改思路

• 监听删除dom操作，在删除dom操作的瞬间重新生成一个相同的dom元素


• 监听修改dom样式操作


• 不能使用onMounted,改为watchEffect进行监听操作

使用MutationObserver监听整个区域

let ob

onMounted(() => {

  ob=new MutationObserver((records)=>{

    console.log(records)

  })

  ob.observe(watermarkRef.value,{

    childList:true,

    attributes:true,

    subtree:true

  })

})

onUnmounted(()=>{

  ob.disconnect()

})

在删除水印div之后，打印一下看看records是什么。

在修改div样式之后，打印一下records

很明显，如果是删除，我们就关注removedNodes字段，如果是修改，我们就关注attributeName字段。

onMounted(() => {

  ob=new MutationObserver((records)=>{

    for(let item of records){

      //监听删除

      for(let ele of item.removedNodes){

        if(ele===watermarkDiv){

          generateFlag.value=!generateFlag.value

          return

        }

      }

      //监听修改

      if(item.attributeName==='style'){

        generateFlag.value=!generateFlag.value

        return

      }

    }

  })

  ob.observe(watermarkRef.value,{

    childList:true,

    attributes:true,

    subtree:true

  })

})



watchEffect(() => {

  //generateFlag的用处是让watchEffect收集这个依赖 

  //通过改变generateFlag的值来重新调用生成水印的函数

  generateFlag.value

  if(watermarkRef.value){

    addWatermark()

  }

})

最终，小李向领导展示了新的水印组件，取得了领导的认可和赞许，保住了工资。

全剧终。
文章同步发表于前端百事通公众号，欢迎关注！

本人最早是2017年，开始在上市公司作为高级经理，管理大前端团队，包括安卓、iOS和前端工程师，但这么多年过去了，我的管理工作还有很多需要改进的地方。

不管我是继续创业，还是去上班，我都需要考虑前端团队管理的事情。所以，本文我将结合过去多年的前端管理实践和面试经历，分享我对前端管理的思考、前端管理的高频面试题和一些学习资料。

关于前端经理岗的思考

在我成为程序员之前，我是北京军区38集团军某部的指挥军官，在部队最多时管理过130多人，在聚焦谈前端经理岗之前，我先放大聊一下管理。

什么是管理

管理是一个多维度的过程，既有对项目的管理，也有对人员的管理，还有向上管理、同级管理、自我管理和向下管理。

对于前端经理岗的管理，需要以人员管理为主，但也要以项目管理为本，而前端架构岗，则以项目管理为主，但需兼顾人员管理。

狭义的管理是指一定组织中的管理者，通过计划、组织、领导、协调和控制等手段，对组织所拥有的资源进行有效的整合和利用，以达成组织既定目标的过程。

技术团队管理的方法论

技术团队的管理是指运用一系列的管理原则和实践，对技术人员进行组织、指导和协调，以实现团队目标的过程。

技术团队管理的关键在于平衡技术发展、团队建设和业务需求之间的关系，确保团队的高效运作和创新能力的持续发展。

通过询问国内几个主流的大模型和查阅相关的资料，我最推荐的是一个美团同事在团队管理方面的总结的方法论。

他不仅在IGT、腾讯和新美大工作期间，参加了各种培训和大佬分享，平时还阅读了二十多本团队管理有关的书籍，并且在美团也做了多年的技术团队管理。

他采用的是自底向上方式，先是将所有知识打碎，然后重新归类汇总。先列举出了六十多种实践或方法，然后将它们划分成不同模块，并且思考这些模块之间的关系，最终建立一个相对完整且自洽的体系。

他将团队管理的整个体系分为两个维度，十个模块。有了这个体系，我们就能够以更高的视角，来看待团队管理中的各种事务，并且有针对性地加以改善。

上面的图，只是列了一下技术管理相关工作大纲，但要开展好管理工作，推荐的还是 PDCA 管理，这是美国质量管理专家休哈特博士首先提出的，由戴明采纳、宣传，也被称为“戴明环”。

它是全面质量管理所应遵循的科学程序，不仅在质量管理体系中运用，也适用于一切循序渐进的管理工作。它通过循环不断地进行计划(plan)、执行(do)、检查(check)和处理(ack) ，以达到不断完善过程和提高结果的目标。

PDCA 的管理可以总结为四阶段及八步骤：

• P阶段--计划：即根据顾客的要求和组织的方针，为提供结果建立必要的目标和过程。
  
  
  
  • 步骤一：选择课题，分析现状，找出问题
  
  
  • 步骤二：设定目标，分析产生问题的原因
  
  
  • 步骤三：提出各种方案并确定最佳方案，区分主因和次因
  
  
  • 步骤四：根据已知的内外部信息，设计出具体的行动方法、方案
  
  
  
  


• D阶段--执行：即按照预定的计划、标准，努力实现预期目标的过程。
  
  
  
  • 步骤五：设计出具体的行动方法、方案，进行布局，采取有效的行动
  
  
  
  


• C阶段--检查：即确认实施方案是否达到了目标。
  
  
  
  • 步骤六：效果检查，检查验证、评估效果
  
  
  
  


• A阶段--处理
  
  
  
  • 步骤七：对已被证明的有成效的措施，要进行标准化，以便以后的执行和推广。
  
  
  • 步骤八：问题总结，处理遗留问题，为开展新一轮的PDCA循环提供依据。
  
  
  
  

我在 PDCA 上加了扩展，变成了 O + PDCA + R：其中 O 是机会，只有发现并抓住了机会，才能开展 PDCA 的管理过程；而 R 则是Review，需要结合周报、月报、季度和年终总结定期进行总结复盘。

我的管理复盘

先谈一下我对管理认知：管理可以理解为管人理事的缩写，其中管人，包括选用育留开；而理事，则包括对公司及部门的战略理解，所负责或参与项目的规划、实施和复盘，整体的质量、效率和体验的提升。

因为我是国防生，大学期间就开始接受部队系统的管理培训，所以看了很多管理相关的书籍，我的管理理念和风格依然受部队的管理很大。

很多人会误解部队的管理是简单粗暴的命令式管理，但我党我军管理的精髓是民主集中制，既有民主，又要确保集中，注重以身作则、平等待人和思想工作。

所以，我实际工作中，不管是直线管理团队，还是通过项目管理相关同事，都会坚持民主集中制的原则，倡导用规则管理团队，并鼓励大家从团队出发，完善或提出规则，让大家都能参与到管理中。

大家若能参与到团队管理规则的制定，并且管理者能否以身作则，奖惩公平，树立起规则的权威，这样的团队才比较容易做到上下同心，营造出平等、自驱、高效和快乐的团队氛围，团队业绩也会更好。

管理团队的前期，我一般会制定三个原则：

• 每周跑一个3公里(女生只需1.5公里)；


• 每周抄写10个英语词汇(每月安排一个同学提供)；


• 每周写一篇技术博客或学习笔记。

做不到的需要交10元团建费(一般由女同学负责管理)，在每周的技术分享会上用来买水果糕点吃。

制定第一个原则的考虑是，很多码农缺乏运动，身体亚健康的比例很高，另外对男女生的要求不同，也是让大家知道待人着想。而第二个原则呢，则是现在技术更新很快，很多新技术及遇到的问题，只有英文资料。最后呢，则是提升大家的写作基本功和让大家养成持续学习的习惯。

这三个原则执行起来后，我就会鼓励部分同学提出一些新的管理规则，然后在周会上提出，大家匿名表决，对于规则的完善建议也是如此，比如参加会议迟到也要交10元团建费或加一些奖励的规则。

回顾过去几年的管理工作，我觉得《高效能力的七个习惯》对我的启示很大，要想做好前端团队的管理，先从做好自我管理入手，然后主动做好向上管理，接着兼顾组织目标和团队个人目标做好向下管理，但也不要忘了关注协作方相关的管理工作。

一般一个月以后，团队能够按照规则良好管理起来后，我就会把重心过渡到核心项目的管理和架构上面，既会做前沿技术的调研，又会参与一些紧急项目的代码开发。

对我来说，我不愿成为一个官僚式的纯管理者，而是要主动拥抱前沿技术，具备大型复杂项目的管理和架构能力，这样在职场上才能保持持续的竞争力。

前端经理岗的高频面试题

这几年不管我是面试开发岗，还是前端经理岗或总监岗，有一些共同问题高频出现，但不同的岗位回答各有侧重，才能提升通过面试的概率。

本节我既会针对一些高频的共同问题，也会针对只有前端经理这个岗位才可能遇到的问题，分享一些我的思考。

请先做一下自我介绍？

不管是面试什么行业或什么岗位，也不管是第几轮面试，我们面试需要回答的第一个问题就是介绍自己。

很多人都会简单准备一个自我介绍，并且每次面试的介绍都一样。要想面试过程更顺利，我们最好根据面试公司的业务、岗位要求、面试官等情况，适当地调整自我介绍。

比如面试腾讯TEG 大模型的开发岗，我会这么介绍自己：我是XXX，从XX毕业已经12年了，最开始在外企以开发操作系统为主，16年开始转型做大前端开发和架构工作，技术栈以react 为主(因为JD说了项目用的是react)，19年开始自学深度学习，过去三年都在做模型应用开相关的工作，特别是在美团，从零实现了一个web推理引擎。

而面试另外一个上市公司的管理岗，我则会这么介绍自己：我是XXX，从XX毕业后，一直都从事管理相关的工作，最开始在外企做操作系统时，负责团队的新人培训和团建工作，2016年进入互联网行业后，在做好项目架构和管理的基础上，还经常需要做团队管理，最多时管理过35人的大前端团队，既有前端开发、也有安卓和iOS开发，因为在部队接受过系统的指挥军官培训，我的管理遵循毛主席提出的民主集中制原则，以团队共同制定的规则管理各项工作，团队良好运转后，我会把精力聚焦在项目架构优化和研发质量和效率的提升上。

如何克服管理遇到的挑战？

技术团队管理面临的挑战多种多样，包括但不限于沟通不畅、资源分配不合理、团队成员技能不匹配、项目延期等，在面试的过程中，我们挑选一两个例子进行展开即可。

最难凝聚的，是人心：信任和凝聚力是团队成功的基石。每个团队成员都有自己的思想和需求，如何将这些不同的个体凝聚成一个有战斗力的集体，是每位管理者必须面对的挑战。管理者需要倾听员工的声音，尊重他们的意见，关心他们的成长。只有当员工感到被尊重和重视时，他们才会真心投入到工作中，与团队共同进退。

最难驾驭的，是情绪：管理者不仅是团队的领航者，更是情绪的调控者。一个稳定、积极的情绪状态能够激发团队的士气，反之，则可能引发团队的动荡。情绪的传染力极强，管理者的每一次情绪失控都可能成为团队士气的“病毒”。

最难把握的，是人性：孔子说：“己所不欲，勿施于人。” 管理者应将心比心，尊重员工的个人价值和需求。同时，通过合理的激励机制，激发员工的积极性和创造力。人性是不变的，但人心是流动的。管理者需要通过不断观察和学习，把握员工的心理变化，适时调整管理策略。

最难管理的，是期望：员工和上级都对管理者有着不同的期望，这些期望往往难以完全满足。上级领导希望团队能够不断超越，达成更高的业绩目标，而员工则希望得到更多的关注和支持。管理者需要深入了解各方的期望，并制定合理的策略来满足他们。

最难摆正的，是心态：管理者需要摆正自己的心态，从“保姆”转变为“教练”。通过引导和激励，帮助团队成员提升自我管理的能力，而不是替他们解决所有问题。应给予团队成长的空间和时间，而不是急于求成。

最难排解的，是委屈：管理者需要有宽广的胸襟，能够承受来自各方的压力和误解。在管理的过程中，管理者常常处于上下夹击的境地，既要面对上级的高要求，又要应对下属的期望和不满。应有谦逊和自省的精神，面对挑战和压力时，能够坦然接受，积极寻求解决方案。

分享你工作中最大的成果？

技术管理的最大成果不仅体现在项目交付或技术创新上，更在于其对整个组织的长远影响。可以从以下角度挑一两个展开：

• 业务项目：带领团队按时、按预算、高质量完成了一个或多个关键项目，满足了业务需求和客户期望，并通过技术驱动，促进了公司业务增长，如增加了用户数量、提升了用户活跃度或实现了收入增长。


• 技术创新：推动了技术创新，如引入新的技术栈、开发新的产品功能或改进现有的技术方案，从而提升了产品的竞争力和市场份额。


• 流程优化：改进了开发和运维流程，如引入敏捷开发、持续集成/持续部署（CI/CD）等，提高了工作效率和产品质量，在面对突发事件或危机时，能够迅速做出反应，采取有效措施，最大限度地减少了损失，并从中恢复过来。


• 人才培养：建立了积极向上的团队文化，增强了团队的凝聚力和员工的归属感，通过培训和指导，成功地培养了技术和管理方面的后备人才，为公司未来的发展打下了坚实的基础。

如何去做好这个管理岗位？

朝哪个方向走，判断的核心是深刻理解市场、业务的趋势。这其中，要对技术的未来做判断，对产品的未来做判断，相对而言，大部分人都能看到技术的发展趋势，困难的是判断未来的产品形态。

要有效地管理前端团队，需要从团队组建与选拔、技能提升与培训、项目管理与协作、质量控制与测试以及团队氛围与文化等多个方面入手。

通过明确团队目标、合理分配任务、持续培训、建立有效的沟通机制和加强团队文化建设，可以提升团队的整体效率和协作能力。

回答这个问题时，最好以互动问答的方式进行，多向面试官了解相关的情况，然后针对岗位职责和存在问题，进行适当的展开。

你为何离职？之后有何规划

回答离职原因和后续规划的问题时，重要的是要保持诚实、积极，并展现出你对新机会的热情和期待。

离职原因

• 诚实但策略性：选择离职原因时，应避免负面评价前雇主，而是强调个人成长和职业发展的需求。


• 具体原因与改进：即使是因为薪资、工作环境或领导问题离职，也应表达出你从中学到了什么，以及你如何准备在新工作中避免类似问题。

后续规划

• 职业目标：清晰地表达你的职业目标，展示你对前端技术领域的热情和承诺。


• 技能提升：强调你计划如何继续提升自己的技能，包括学习新技术和参与项目实践 。


• 对新机会的期望：表达你对新公司的期望，包括你希望在新角色中实现的目标和对公司的贡献。

通过上述策略，你不仅可以有效地回答离职原因和后续规划的问题，还能够给面试官留下一个积极、有目标的印象。

相关的学习资料

主要推荐一些我阅读过的书籍或看过的视频。

书籍：

• 《高效能人士的七个习惯》


• 《卓有成效的管理者》


• 《领导梯队》


• 《重新定义团队：谷歌如何工作》


• 《OKR工作法》

视频：

• 从专业到管理：管理思维与管理能力的双重跃迁


• 中层管理三板斧

总结

人，是企业最宝贵的财富，甚至更胜于商业模式。管理能力的核心包含两方面，一是针对人，对人性的了解程度以及沟通能力。二是对事，是否有强大的统筹规划协调能力。

这是对于广义上管理能力的定义，对于技术团队，其本身有一些特殊性，所以在管理技术团队的时候，要充分考虑到这些特殊性。

管理是一件很复杂的事情，但是我认为管理技术团队相对并不复杂，可能是大多数技术人员都还是比较单纯吧。

技术团队的管理者，特别是中层管理者，其实就是个夹心层，经常受夹包气。其实你想想，作为一个承上启下的职位，压力同时来自于下面和上面，收夹包气也就正常了。

但是如果我们能够科学的规划任务，坚持以事驱动人，事前做计划，事中做追踪，事后做分析，调动团队积极性，我想再困难的任务也能够分解成一个一个不困难的小任务，分而破之。

对于团队内的一些声音和反馈的问题，能够耐心倾听、加以思考和用心解决，成员自然能够很好地完成管理者布置的任务。

关于面试相关话题，欢迎大家在评论区或加我微信交流：waxyysys82。

我和你一样都经历过 家里蹲 狗都嫌 的尴尬时期，每天早上起来拿着手机不断刷着招聘软件，

海投几百份还是杳无音讯，在BOSS直拒、前程堪忧、失联招聘、猎空之间反复横跳...

还经历了十分灰暗的阶段，焦虑导致出现躯体化反应（头痛、严重失眠、吃不下东西等）

整夜整夜睡不着，躺下脑子都是工作、面试、人生选择带来的压力

不想出门社交，害怕面试。

其实，我想跟你说：裸辞并不是终点。

1.裸辞/辞职并不是终点

当我扛着我的键盘收拾东西离开工位，第一次对辞职的 “人走茶凉” 有了实感，

下午六点跟对我很好的前辈们告了别，公司离地铁有点远，和往常不一样，天还没黑，有黄昏相伴

三号线还是这么挤 还有点闷。

算起来这是第二次辞职，但第一次辞职找了一个礼拜就顺利入职了
，这次好像有点久，今年大家都在说被裁员、大环境差，同学领证成家的也不少。

我意识到人与人的节奏不同，而我好像又一次走到了岔路口，上一次这么慌张还是在高考前

即便我从来没后悔过离职这个决定，但还是会因为面试带来的压力感到局促不安

每次离职就像是一场查漏补缺的大考，对勇气，对储蓄，对知识点的大考

唯有拆迁和认亲能打破这场突如其来的考验。。。啊不是。。。我想说：

唯有行动能打破僵局！！

行动！！！去吃个冰淇淋！！。。。果然有灵感了

短暂的欢愉后，是与台灯的昼夜相守，与简历的交织缠绵

（简历编。。不是。。写不出来呀！！！）

反复改了几版之后确实多了一些“打招呼”的机会，但是实际面试机会还是屈指可数呀，

切！又不是第一次没人要🤡，拒绝我的多的去了，得从巴黎排到广州...

继续努力，等待运气，厚积薄发

2.当知识脱离了考试，真理和美丽才慢慢浮现

2.1 心态调整（分享一下最近对我有帮助的书）

• 《见识》 - 吴军

这是第一年出来工作，遇上了很好的领导送我的书，每当迷茫的时候再拿出来翻翻有了不一样的感悟，很多我们看上去非做不可的事情，其实想通了并没有那么重要，无论在职场上还是在生活中，提高效率都需要从拒绝伪工作开始，有些苦是可以不用吃的，苦难并非造就人类。

幸福是目的，成功是手段

• 《意志力》 - 罗伊·鲍迈斯特

技术行业的人都知道学习是个漫长/终身的事情，跟考公考研短期爆发式集中不同，我们更需要坚持、长期一点点做下去，我认识到所有人的意志力都是有限的，使用就会消耗，压力也并非与动力画等号，人也跟机器一样需要“充电”和合理分配，每个人的节奏和身体承受能力也不同。

• 《被讨厌的勇气》 - 岸见一郎、古贺史健编著

在心情动荡的时期，这本书就像开了一盏加热灯一样在一旁无声陪伴，那会我就像婴儿一样无意识地紧紧抓着自己的头发，直到我睁开眼看见了、意识到了，放下禁锢着工作、生活、交友的课题的手，更能轻松地赶路了。

生活的方式千千万，人生的意义，由我自己决定

• 《法律常识全知道》 - 李桥

读书的时候没有一门跟社会接轨的课程，毕业了也一直专研技术，导致一毕业不知道劳动合同/租房有什么坑，把仲裁和维权看得过于艰难，法律条例密密麻麻 一时间不知从何下手，这本书就很适合我这种来一线城市打工没什么社会经验的小白，用简单的案例植入“NPC游戏”攻略，和《影响力》这本书加一起简直就是进城防骗指南哈哈哈

免费法律援助电话：12348

2.2 前端学习路线图：

各位摸鱼的小伙伴下次见，这篇便是我的2023年终总结：

裸辞不是终点，唯有行动才能打破僵局，当知识脱离了考试，真理和美丽才慢慢浮现。

参考资料：

前端学习路线

前言

很长一段时间没有总结一下过去几个月的状态了，今天思绪万千，脑海中浮现了很多经历和生活片段，我把它记录下来。顺便今天聊一聊认知突破，分享我在买房这段时间吃过的亏，也希望作为你的前车之鉴。

买房

21年底的时候，那时刚好毕业三年，也正是互联网公司996最流行的阶段，由于平时我不怎么花钱，也很少买衣服，上网买东西是个矛盾体，需要花很多时间对比，经常看了一件东西很久，最后又不买。加上比较高强度的工作状态，两点一线，可以说是没时间花钱，再加上自己把钱都拿去理财了，也赚了几万块，最后一共攒了几十万下来。我从小就立志要走出农村，而且认为以后有女朋友结婚也要房子，加上当时花比较多时间在理财上面，那时候其实行情已经不好了，工作上没什么突破，比较迷茫，于是想着干脆就把钱花出去了，自己也就有动力去搞各种路子尝试赚钱。在没有经过任何对比之后就在佛山买了一套房子，房价正是高峰的时候，于是我成功站岗！因为这个契机，躲过了持续了2年多的低迷股市，却没躲过低迷的房地产。

while(true) { 坑++ }

我买的是期房，当时不知道期房会有这么多坑，比如期间不确定开发商会不会破产，我这个开发商（龙光）就差点破产了，房产证无着落，相当于花了200w买了一个无证的房子，这辈子就算是搭进去了。

对于整个购房过程也是很懵逼，对流程完全不熟悉，当时去翻了政府规划文件，看那个地段后续有没有涨价空间，然后跟着亲戚介绍的销售转圈圈，当时说给我免3年物业费，合计也有几万块。在签合同之前销售都有说可以给到，但由于第一次没有录音，导致在签合同的时候销售反口，不承认，我们也没有证据，最后吃了哑巴亏。

开始的时候谈好了一个价格167w，然后销售私下打电话给我洗脑说我给点辛苦费1.5w，他可以向领导申请多几万块优惠。我知道这是他们的销售套路，但是架不住给我优惠5w啊，中间反复拉扯最后说给他8k，采用线下现金交易的方式。这一次我有录音了，因为私底下交易没有任何痕迹，也不合法，所以留了一手，也成为我后面维权时争取话语权的基础。

中介佣金是很乐观的，当时由于我亲戚推荐我去，销售承诺税前有4w，当时看中这个返佣也促使我火急火燎的交了定金。现在3年过去了，这个佣金依旧没有到账，我一度怀疑是中介搞ABC套路把我这个钱💰吃了，其他邻居的推荐佣金都到了账，加上现在地产商没钱了，同时跟那个亲戚有些过节，这个返佣更是遥遥无期。最后通过上面的录音获得了一丝话语权，知道了这个钱还在开发商手上，一直没有拨款下来到中介公司。下面是部分聊天记录：

不接受微信语音沟通，文字可以留给自己思考的时间，同时也更好收集证据。

然后去找相关人员把信息拉出来给我看，显示开发商未付款状态，这个状态维持2年了，目前看来只能再等下去。

签合同的时候，有个律师所说是协助我们签合同、备案、办房产证等各种边缘工作，糊里糊涂交了700元律师费，不交不行，甚至律师所连发票都没有给，而我都没有意识到这个最基本的法律法规问题。现在交房了可以办理房产证了，拿证下来也就80块登记费，居然收我700，其他业主有些是600多，400多，顿时觉得智商受到了侮辱，看了网上铁头各种打假的视频，我觉得自己也应该勇敢发声。现在也在收集商家各种违规证据，提交给相关部门解决。

后面市场监督管理局收到投诉，应该是有协商，意识到没有给我们发票，过来几天之后才把发票补过来，开票日期不是付款时候的2022年，而是2024年，明显属于偷税了。目前跟他要发票的应该只有我，估算2300多户业主都没有开发票的。

当时我首付需要50w，自己手上不够，我爸干建筑一辈子，辛苦供我们两个孩子上了大学，山上建了两层楼，手里没钱。我妈是一辈子没打过工，消极派，说出来没几句好话，家里不和睦的始作俑者，更不可能有钱支持。所以我还有20w是首付贷，也就是跟开发商借的，利率10%，这个利息很高了。销售当时说可以优惠到5%，但是优惠金额是补贴到总房价里面去，其实这也是他们的一种销售套路，这亏我也吃了，2年之后我连本带息还24w。当时认为自己应该一年左右能还完，但是实际远远高估自己的能力，买完房子接着我爸又生病在医院待了几个月，前后花了十几万，人生一下子跌入了谷底。

从头再来

后面2023一年，夫妻出去创业，很多人不赞同，期间遇到了不少小人诋毁我们两夫妻，当时我老婆还在怀孕，但我们最后都熬过来了，还生了一个儿子，6斤多。期间一年赚了十几万，但是开支也大，加上父母要养，我爸还要吃药，房子要供，最后还是选择了先稳定下来，我重新回到了职场，空窗一年后在这个环境下拿了一个还不错的offer，同时也想自己沉淀一下。

自从有了宝宝之后，生活似乎都往好的方面发展，出版社找我出书，为了契合自己的职业发展，我选择了写书《NestJS全栈开发秘籍》，从2023年11月份开始，迄今快半年了，在收尾阶段，希望尽快与各位读者们见面。同时，等了3年的房子也收房了，由于是高层，质量相对其他邻居好，没有出现成片天花掉下来或者漏水的情况。我们经常都说他是天使宝宝，是来报恩的。

由于我们公司技术部门是属于后勤支持性质的，技术变化不大，Vue2+微前端和React管理系统那一套，没有太多的新技术扩展，意味着不确定也大。业务发展不好考虑的是减少这些部门的开支，所以不出意外最近也迎来了降薪。这不是最可怕的，对于我们技术人来讲，最可怕的是我认为在业务中成长停滞了，或者没有业务来锻炼技术，所以在业余时间也选择了参与一些开源项目，如hello-alog开源算法书的代码贡献，并且这也是选择写书的原因。很简单地说，当下一个面试官问到我的时候，我不可能什么都讲不出来，最经典的问题就是：在这个公司期间你做过最有成就感的事情是什么？现在，我有了答案！

哲学

我的人生哲学是不断改变，拥抱不确定性！这么看来，我的确在这些年上了不少当，吃了不少亏，把自己搞的很累，甚至连累到家里人。但，用我老婆经常说的一句话：人生这么长，总是要经历点什么，再说现在也没有很差。的确，不断将自己处于变化之中，当不确定性降临到普罗大众时，我们唯一的优势，就是更加从容！

总结

人们还在行走，我们的故事还在继续~

重新思考前端开发以及自己未来的规划。先说结论，再展开。

亲身经历

公司在去年选择了一款 Plasmic 这个低码平台，希望未来由业务部的人来使用低码平台构建页面，由开发部的人负责研究平台的使用方法、解决复杂的问题。后来，公司有 100+ 个问卷需要制作，并且这个业务是在内网中，不方便使用第三方的表单服务。这 100 个问卷中，有几十个在另一个 Vue 系统中有实现过，还有一些可能需要新增。我推荐让开发部来写这部分代码，但领导还是决定让业务部门的人使用低码平台（基于 NextJS）来构建。理由是这些问卷在另一个 Vue 中有实现过（我实现的），照着页面抄就行了。

在业务部的人经过一个星期的折腾之后，做了几十个问卷，最终因为难以维护而停止。这几十个问卷每个都是单独的页面，每个页面都需要对接口，需要一个问题一个问题的拖拽然后配置。在检查的时候，出现了各种各样的问题，量表出现问题时，还得一个问题一个问题的排查，排查起来不如重做。更何况，业务部的人也不会排查页面，她们没有什么编程基础。

这个问题并不难解决，只是这个决策让人有点令人匪夷所思。我的解决步骤大致分为两个步骤：将 NextJS 中的 Form 的编辑变成声明式的、对 Vue 中的 Form 进行迁移。

将 Form 的编辑变成声明式的，也就是用 JSON 来配置。例如在 Vue 中可以使用 FormCreate、在 NextJS 中可以使用 nice-form-react。我其实并不喜欢拖拽式的低码，拖拽之后再通过点击来配置其实很费时间，在经过我的实践发现，这种声明式的配置配合 GPT 来使用非常妙，只需要把配置相关的要求告诉他，就可以让他完成大部分的工作。前两天发现有类似的文章：低代码与大语言模型的探索实践。把编写 Form 页面变成编写 JSON 文件，复杂度直线下降。业务部的人可以直接通过 ChatGPT 生成 JSON，我只需要给他们一个工具来校验和展示 JSON 所对应的量表即可。

将 Vue 中的 Form 转换到 Next 中，有些人可能会考虑思考 FormCreate 底层的逻辑，然后在 NextJS 中再实现一遍，这样就能无缝迁移。并不需要这么做，这么做工作量非常大，只需要看数据结构怎么转换即可。

总结：Vue 中的 FormCreate 经过了魔改，支持根据题目算分。在 NextJS 先实现类似的声明式构建的机制，然后再将数据库中的 JSON 配置进行转换。

最终，加上业务部的配合，使用 GPT 来生成 JSON 文件，两三天的时间就全部迁移完成。大胆预测一下，拖拽式低码平台后面会被懂 DSL 的平台所替代，利用语义化的 DSL 配合大语言模型，效率应该会非常高。

重新思考前端开发

Linux 的创始人 Torvalds 曾说过一句话：“烂程序员关心的是代码，好的程序员关心的是数据结构和它们之间的关系”。

上面的声明式的 Form 工具是我构建的，由业务部的人来使用，当他们有什么需求的时候，我能很容易知道现有的结构能否实现。将 React 想象成一个更复杂的声明式的 Form 工具，那么熟悉它底层原理的人应该也可以拓展它的边界。

于是我尝试着阅读了一些 React 相关的源码，根据《🚀 万字好文 —— 手把手教你实现史上功能最丰富的简易版 react》构建了一个 mini-react。理解了 React 本质上是 DSL + 高效更新树的算法。JSX 作为 DSL 来引入组件化和简化树形结构的编写，Fiber 树和 Diff 算法来高效的更新树。

沿着树形结构稍微发散一下，就知道为什么会有 React Native 了。在网页中使用 DOM 树，在安卓中使用 View，在 IOS 中使用 UIView，这些都可以被称为布局树。当然除了更新视图，还有很多需要兼容的问题，例如：

• 解决布局不一致：采用 Yoga 布局引擎。


• JS 和原生代码交互：跨语言通信都会利用 Bridge 这种机制。例如调用 rolldown 会使用 napi-rs 。

我还继续沿着树形结构去探索 React 的可能性，想到了 Svg、Canvas、Three.js 这几种技术。我并不是特别了解这几种技术，只是简单的 check 是否有人将 React 用于这些方向，最后发现 React Three Fiber 这个项目。Three.js 中需要渲染场景树，Fiber 树现有的逻辑为什么不能用，非常好奇作者是如何将 Fiber 应用于 Three.js、为什么需要再实现一个 Fiber。

学会用 React 写页面非常简单，从零基础开始学，最多几天就能写出基本的页面，最麻烦的可能就是调 CSS，但是这些问题的复杂度都并不高，多搜索多尝试多问 GPT，基本也花不了多长时间就能解决。

但如果我们遇到的需求是制作 Su7 在线预览、制作 Win98 在线版、制作 Figma（通过 Webasmbly 与浏览器 Canvas 交互，让用户在浏览器端体验到了 Native 软件能力），那我们应该怎么办？薪资水平上不去的原因有部分原因就是这个了吧。我想到的解决方案是：重视源码阅读、重视数据结构和算法、甚至重视底层的数学。虽然上大学的时候就一直听说这句话，但是一直感悟不深。

在我重视了源码阅读之后，开始尝试去阅读 React 源码，然后顺着树形数据结构更新这个核心概念，延展出了 React Three Fiber。假设将时间线往前移动几年，并且我的设计和开发能力足够，可能我就成为了 React Three Fiber 的 Creator。也就是说，我顺着这样的思路再往后学习，可能也会发现一些新的场景，然后做出一些还不错的工具。

在 React 源码中有很多对于树这种数据结构的操作，让我重拾了对数据结构和算法的乐趣。在了解到还有 React Three Fiber 之后，我意识到常见的 Web 页面只是 2D 上交互，未来可能还有很多 3D 交互（比如在 Vision Pro 上），我想自学一下计算机图形学（在这之前可能得补一下线性代数、物理的光学）。好像挺多人推荐 GAMES101: 现代计算机图形学入门 这门课的。

内容创作者

作为一个前端开发者，有时候会逛到一些特别好看官网，就会特别羡慕这些开发者那么强。如：ONEUPSTUDIO、GSAP。后面我发现，网站好看与否很大程度上取决于设计师，软件好不好用取决于产品，功能能否实现取决于程序员。

开发者的职责是用代码将他们的想法表达出来，或者制作更好的工具帮助他们去创作和表达。工具之间的区别在于表现力、使用场景和使用范围大小，并且这些工具通常都是声明式的。设计师能使用 Webflow 这样的软件开开发出好看的网页，但是前端开发不一定能做到。作为程序员，最好的做法是制作更好的工具，如果直接表达想法，就会写出维护性和拓展性很差的代码。就像我上面提到的 Form，我应该提供一些制作 Form 的工具，而不是一个页面一个页面的绘制。

我们常见的 CSS 就是表现力非常强大的工具集，里面包含了 Table、Flex、Grid 等等工具。在没有 Flex 的时候，我们可以用 table-cell 这种这种的办法来实现垂直居中，但是在很多场景下使用起来比较麻烦，这就是工具的表现力差。后来引入 Flex，可以轻松的实现垂直居中。

程序员也是一种内容创作者，我大致的划分了一下互联网上的内容创作者，大致有如下的观点（不一定准确）：

我在写 mini-react 的时候，相当于自己处于「框架/库」的内容创作者，我尝试直接在 codepen 中找一些有意思的作品，然后尽量去提供相关的机制（渲染、Diff、Hook）。作为「框架/库」的内容创作的的时候，可以很容易分析出整个软件的边界，我能知道 mini-react 能否做到某些功能。具体的页面绘制可以交给另一个层级的内容创作者，也可以尝试去复用他们的作品。

不同人有不同的喜好和擅长点。我很喜欢好看的软件，但我在绘画和艺术方面没有非常高的热情 Passion，往「数学/物理」这个方向去拓展应该会更适合我。有些人可能喜欢画画，会往「视频/图片/文字」这个方向，最终成为设计师。

过早优化是万恶之源

“过早优化是万恶之源”来源于 Donald Knuth 的《计算机编程艺术》一书，其原话是：

The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.

真正的问题在于程序员在错误的地方和错误的时间花费了太多时间去关注效率；过早优化是万恶之源（或至少是大多数问题的根源）。

在学习 mini-react 的时候，我想到了一些问题：

• React 中还有很多种 API 和配置，那我是不是要都实现一遍？


• React 有很多优化手段，我是否都要看看？

答案都是“不”。通过 React 能实现的网页，用 JQuery 也能实现。这些优化手段和 API 是通常都针对非常具体的场景，其通用性是比较低的。在掌握了整个 React 的核心原理之后，遇到这些场景再去学习会更好。它们大多也是基于核心原理去拓展的，理解起来并不会非常耗时间。比如 React Hooks 和 Fiber 树紧密关联。

半年计划

用以终为始的眼光来看，我十年之后还会在现在这家公司吗？答案是绝对不会。不在沉默中死亡，就在沉默中爆发。继续在公司苟着也只是将问题隐藏起来，所以还是决定了离职。

现在找工作难度越来越大，前端更是重灾区，一个岗位可能几十个人投。在这种环境下，调整好自己的心态比较关键。苦思冥想后，想到了一句可以让自己保持 Passion 的话：“找不到工作这段时间就是提升能力，找到工作就是幸运的”。

最近看到一篇博文非常喜欢，这里转载一下《前端开发的瓶颈与未来之路》 中的一段文字：

我在 2018 年有幸参加了 TypeScirpt 的推广大会，TypeScript 的作者 Anders Hejlsberg 亲自主讲。一位将近 60 岁的程序员在讲台上滔滔不绝的讲技术方案，TS 的设计理念。你真的很难想像这样一位处于「知天命」阶段的老头子（实际上很年轻）讲的东西。

QA 环节有个年轻小伙问到 Anders「在中国做程序员很累、很难应该怎么坚持下去（类似这样的描述，细节记不清楚了）」的问题。

Anders 几乎毫不犹豫的说出了「Passion」这个单词。我瞬间就被打动了。因为在此之前我对于「激情」这个词的认识还停留在成功人士的演讲说辞层面，当 Anders 亲口说出 Passion 一词的时候，让人感觉真的是一字千金。

这里还有一些我非常喜欢的文章，给大家推荐一下：

• 《怎样花两年时间去面试一个人》


• 《李辉 - 待业五年后的找工作经历》

致工作三年即将27岁的自己

这是一篇自己的碎碎念、即回顾自己以前的成长经历、也小小的持有一下对未来的期待。

我是一个双非本科从事于Java开发的一名普普通通的码农、不同于大多数人的27岁、大部分人在这个年龄都已经工作了4/5年、而我也恰恰刚刚满三年而已。

读书

小时候的记忆很模糊、很少关于有父母的记忆、从小的印象就是他们在很远的地方打工、那边还有一个从未谋面的哥哥、小时候的记忆更多是和爷爷奶奶在一起，爷爷在我记事起、他就很忙、很少在家里也或许是我不记事或者缺少了这部分的记忆。

在小时候的记忆里、住在茅草屋里面、那个时候家里还没有完全通电、印象里经常点煤油灯、这个时间段应该是02/03年的时候、记忆里这个时候家里养了一头牛、是一头老黄牛。家里在需要耕田播种的时候、不管风吹日晒、都能看见爷爷在田里一边驾驭着黄牛、嘴边一直在说什么、应该是教导牛牛该怎么走以便使的犁田犁的更好。记不清了、只知道每次遇到下雨的时候、爷爷披着蓑衣带着一个草帽、颇有一些武林大侠的气息。

那个时候家里有一条很凶很凶的狗、幺爷爷家里还是一条白猫、年龄比我那个时候都大。这条很凶的狗已经不记得长啥样了、甚至什么时候去世的都没有印象。

关于这条狗不多的记忆就是、它很凶、但凡看见我们在地坝(四川话：门前小院的意思、通常用于晒一些农作物的地方、或者夜晚乘凉的地方)里面打闹。它都会狂吠不止、这是对它的一个记忆。

还有一个记忆就是，记得是在某一个夏天、在屋后发现了一只野兔、这个时候不记得是不是爸妈在家了、全家都在追这个野兔、追了好久、这条狗也在追、有一个画面就是在我小时候的眼里那个农田的岸边很高、这个直接就从岸边往下面的田里跳下去、连续跳了好几个这样的梯田、那个姿势在我眼里好帅好帅、现在都记得很清楚。最后这个野兔是被抓住了、炸了酥肉、那个味道真的很香、现在都记忆深刻。毕竟小时候家里都是吃猪油、用很小很小的一块、煎出油炒菜。

幺爷爷在的猫是条白猫，印象里是一条抓老鼠的好手、但是不知道它什么死的、只记得大概有十三岁左右。

奶奶有风湿心脏病、那个时候总会吃一些药和一些偏方、记忆里有这么一幕、爷爷把刚出生的小狗狗杀掉、给奶奶治病、嘴馋的我也要吃、结果吃了一口就闷住了。

奶奶在我的记忆里有个画面就是我不想去读书、在上学的路上跑到了一个斜坡上、就如同那个时候黑白电视机上播放的游击战争片一样、以为自己躲在这里他们指定找不到、当然了最后肯定少不了一顿打。印象里只被奶奶打了这一次。

奶奶是在06年走的、不到六十岁。记忆特别深，当时哥哥从东北回老家也快一年了、那是在一个夜晚、哥哥先去睡了、我和其他堂哥堂姐在家里看电视、电视里播放的是洪金宝主演的、是一部战争片、大概就是他们去越南救什么人、有一个人在飞机上跳伞的时候说要倒数十个数、然后打开伞、结果这个嘴吃的人没数到就摔死了。里面有个画面用草杀人、后面还依葫芦画瓢学过这个东西。

奶奶走的时候、爷爷是第一个发现的、我记得爷爷发现之后、我去把哥哥喊醒了、然后我就一直在哭。虽然当时不知道死亡意味着什么、就是在哭、那个时候我上三年级了。奶奶走的那天的天气很好、我还记得我捡了一个螺母回家、后来我把这个螺母扔掉了、当时就想如果不捡这个螺母就好了、奶奶就不会走了。

第一次见哥哥的时候是在一个夏天、爸妈把他从东北送了回来、打算让他家里面读书、当然读书的地方现在已经垮掉了。那个时候家里的公路还是泥巴路、泥巴路大概还是前一年挖机采挖的、挖坏了几个秧田。他们在回来的前一年、写了一封信寄回来、内容是什么记不住了、只记得有一封信、分别向爷爷奶奶以及我都写了点东西。初次见面的时候很陌生、眼前这个和我差不多高有点黑的就是我哥、我的关注并没有在他的身上、更多的是他们提的袋子里面、因为有一袋子糖。

当然了小时候的记忆还有几个画面、就埋藏在心里吧、为什么说上面的狗狗很凶、因为他在我堂姐的脸上留下了印子、现在都能看见。

奶奶走掉之后、我和我哥就去了东北、因为家里没人会做饭了。就去东北读书、东北的记忆说不上多好、校园霸凌确实存在、我也是被霸凌的那一员、我不像我哥哥那样、他们总是有勇气、那个时候的我没有。

在东北这三年、父母总是在吵架打架、住在平房里面、附近都是和父母一样的体力劳动者、他们一闹附近的人都会知道。我们的右边住了一个也是一个外出务工者、他们的有个女儿、比我和我哥都大、长得很白。在我们的左边也是一户外地务工者、不过是东三省的、不是四川的、这家的女主人好像很贤惠很好看、长得也很白。

在这期间、四川发生了很大的一件事、汶川地震、当时我记得我和附近的小孩偷偷跑去上网、结果附近的网吧都没网、然后回家就看到电视上到处都在播放新闻、去上学的时候、学校组织了捐款、我捐了五块钱。

小学结束之后、过完了六年级的暑假我就被送回到了老家、走的时候是和爸爸在工地上的工友一路的、正好他要回家。他和我们是一个地方的，记得大概是午饭后、叫了一辆出租车、我就和这个工友上了车、爸爸的这个工友坐在了副驾、我坐在了后排、送行的人有几个、车窗升起、行驶了一段路后、眼泪就落下了、大概知道了以后又不会在爸妈身边了、也不知道为什么没有哭出声、就和电视里面一样。这就是小学的记忆。

大概走了三四天、回到家了、就开始上初中了。

报名的时候见到了很多小学同学、他们很容易就认出我来了、然而我并没有很快的认出他们、他们说我五官没什么变化、很好认。

初中是在一所民办初中读的、我们这边的公立学校很水、很乱、上课打牌抽烟都存在、老师也不会管。而且离我们也很远。民办学校离我家很近、这里的校长和附近的家长都很熟悉、自然而然的就去读了、自然而然的也会听到这样的交代、娃儿不听话不好好读书就整哦。初中的算是目前为止的小高光、因为那个时候自己还算聪明、成绩也还算可以、被当着升学的苗子重点关注。当然最后也还算争气、以A+1的成绩考进县一中、我们这一届也还算争气、有一个去了同济大学、算是历史最好的一届了，当然这个学校现在也垮了。

高中的时候流传出了一个梗、你的数学不会是体育老师教的吧、那个时候会自嘲、我初中的时候、不止是数学是体育老师教的、历史和物理也是体育老师教的、这个老师还没上过高中。

高中是lol很火的时候、那个时候脱离了棍棒教育的我、理所当然的沉迷了进去、高一上学期还好、棍棒教育的习惯还在、期末考试全年级2000多人我考了200名左右、班上第五名好像。

学习态度的变化不止是因为lol、还记得当时班上有个人说我很努力、所以成绩这样、当时不知道是脑子抽了还是咋了就认为别人在说我笨、然后就慢慢放弃了之前的学习方式、再加上联盟的影响、自然而然的成绩一落千丈、后来也就去复读了。

复读这一年没什么特别的记忆、涨了几十分、去了一所双非学校。还是没有做到高一班主任说的那样、你好好读上个一本不成问题。当时学校的升学率是前60名可以上川大的程度、200名左右上一个一本好像确实不是什么问题。但也确实没做到。

上了大学就和大部分人一样、加部门、当班干部、实际上就是混吃等死。不同的是大二那年、由于初中埋下的病因、做了双侧股骨头置换手术、这一下就把家里面掏空了、手术是在北京做的、花了20+、是在18年、三月一号做的左腿三月14号下午14:17做的右腿、刚检测出来的时候很崩溃、出了诊室就哭了、因为知道这么大笔钱家里出不起、当时借住在北京的姐姐家，在十五楼窗口处、恐惧战胜了勇气、没有跳下去。

查出来的时候就告知了父母、父母当时在深圳上班、我一个人去的北京找的姐姐、父亲先赶过来、看见父亲憔悴的面庞、自己也彻底取消了跳下去的想法、太憔悴了、没见过这个样子的父亲、也无法去想象如果跳了父亲会咋样、只知道那个时候父亲的头发白了很多、然后开始秃头了。

做手术的那几天恰逢过年期间、医院的人很多、见识了人生百态、有的人痛苦呻吟着想活下去，有的人沉默不语想离开人世，坐在轮椅上的时候、被推出去透透风、看见了一个和我一般大的人、少了一条腿，那个时候心里想着都是苦命人。不同于大一暑假工被晒的黢黑的我，在学校看到一个老外、老外的黑衬托出我的白，那个时候由于被晒的黢黑心情很糟糕，见到这个交换生之后得到了极大的安慰。

因为这个手术需要人照顾、学校是上下铺、因此休学一年、手术很顺利、在我们眼里是一个天大的事情、在医生眼里如果一个小手术一般、就和普通的感冒差不多。术后也会恢复的很好、有一段时间是长短腿、走路一瘸一拐的、过了两个多月吧就彻底正常了。到目前为止至少没什么问题。唱跳rap不打篮球。

后面的大学时光就很平平无奇、本以为就和之前的师兄师姐一样正常大学然后毕业、后面就遇到了口罩事件、在学校都没有好好学习、在家里怎么可能会好好学习、真的是在混吃等死、大学期间没有什么特别的记忆、唯一的印象就是大一老校区是一群室友、大二搬到新校区、又换了一批室友、寝室从原来和其他专业的混寝、变成了同专业的混寝、但是由于休学一年、复学的时候又被安排到新的寝室、又换了一批室友、读了一年这一批室友毕业了、我大四的时候又换了一批室友。也就是一年一批室友。也算是独一份了。不过后面的都没怎么联系了。

这就是整个读书生涯了。还有很多画面就埋藏在心底吧。

工作

毕业之后、第一年认识了一个老师、养鱼达人、第一次约她出来玩、就问我用什么去接他、给了刚毕业的我一个暴击。于是呼在工作上加把力，从刚毕业的几千块不到一年的时间就破万了。也就是在22年左右吧。这个时候总觉得自己谈恋爱应该有点底气了。可在24年又给了我一个暴击。也就是今年。

在整个22年里面、由于工作还行、有大量的自由时间、在b上学习了尚硅谷的mysql和jvm课程、在慕课网上学习Java高并发课程、还算充实、虽然工作上用到的不多。

在22年、养了一只猫取名壹贰、是只三花、很粘人，也很喜欢、但我把它放在老家了。我的头像就是它很可爱吧。

在23年里、由于之前的学习累积、总觉得要记录一下、避免用的时候又到处找、就开始了写博客这个过程、博客更新的速度很稳定、生活节奏也很稳定、每天下班之后、买菜回家做晚饭和第二天中午的午餐、厨艺和刀工得到了大涨，每天晚上还能学习两小时、从周末开始选题、工作日开始编码、验证写博客、一切都有条不紊的进行着，生活节奏很稳定、窗外的阳光也很温暖。

23年发生了一件事、就是爷爷走了、遗憾的是没有带个孙媳妇回去让他看一眼、爷爷是五月份走的、守灵的那个晚上、睡在爷爷旁边、没有丝毫的害怕、下葬的那一天、没有哭但全是遗憾。至此带我长大的两个人都离开了人世。

在23年11月份的时候、认识了一个菇凉、她的名字很好听、长得也很好看、她的生活多姿多彩、现在都觉得她活得很多姿多彩。就和大家想的那样、慢慢的喜欢上了这个人、好巧不巧的是她对我也有点点意思吧、然后就约着出来玩、一起看电影、一起跨年等等、初期总是美好的、回忆也是。她不会做饭、总是吃外卖、我会让她点菜然后我做好了带给她吃、无论什么时候会送她回家然后自己再回家、每次见面都会给她准备一点零食或者小惊喜、理所当然的我们在一起了、直到过完年之后的某一个周末、我朋友约我们出去玩、在晚上回来的时候、我朋友买了房子(和女朋友一起买的)、刚好又说到这个问题、我就说了一句以后我们也一起买、用公积金带款、然后就因为这个问题讨论了一周、直到最后的分手。

具体的细节问题就不说了。我工作三年攒了一些钱、家里修房子我出了一点钱。一时间我家肯定是拿不出来的、我想让他给我点时间、结果不愿意、她之前有过很长一段时间的恋情被分手、大概是害怕再浪费时间、也能理解。

刚分手那段时间、感觉像是丢了半条命。心态很崩溃、觉得自己很差劲、一眼望到了头、好像也成不了家。掘金的更新速度就能看出来影响，虽然在一起的时间不长、三月份分的手、到现在为止有些时候都会因为这件事emo。

分手之前很喜欢做饭、分手之后再也没做过饭、看着那些为了给她做菜买的调味品以及打包盒、总是别有一番滋味、有时候总觉得自己要是当时做的再好一点就好了。在这期间看了一些心理学相关的书、也学会了一些调整自己的方法。

分手这段时间里、激情消费买了辆车、自驾去了一趟若尔盖大草原、草原很好看、自此身上的积蓄被自己花得差不多了。不止如此、由于工作上没有任何发展、总是干一些和Java无关的事情、甚至打算让我做嵌入式开发和大模型这一类工作，职业发展也看到了头。

整理生活这段时间丢了很多东西、总感觉自己也把自己丢了、好在慢慢的把自己拼好重新捡起来了。

下一个月也就马上27岁了、看着身边同龄的人要么成家、要么即将成家、要么事业有成、自己还是孤家寡人，多多少少也很羡慕。

站在生活这条十字路口、迷茫、彷徨、不安、焦虑每隔一段时间都会出现在自己身边、好在自己的调整能力得到了极大的提升、看书总归是有用的。

古人云：三十而立、至少现在看来、在这有限的时间里很难立起来了、但总要去试试、说不定就成了呢。

未来会是什么样子的呢？不知道，能把自己的生活过好就已经很不错了。感知幸福是一种能力、感知焦虑也是。

对生活的感悟如同总有千言万语、却有一种如鲠在喉的感觉。不知道命运会给我带来什么样的生活？不管怎么样都坦然接受吧。期待吗？期待吧。

写到这里、感受万千、内心细腻的人总是容易伤春悲秋。

回顾过往、就如同这篇文字一样、普普通通平平无奇、都无法用鸡肋来形容。但相信生活不会辜负每一个好好生活的人、始终对未来抱有期待与憧憬。不管最终如何、终将相信我们都会过上自己想要的生活。

最后给自己定一个目标吧：

• 坚持写博客、写到35岁，我相信自己会一直从事计算机行业的！


• 健健康康的活到退休。

窗外的天空很蓝、阳光很温暖、最近的心情也很好、希望您也是。

谢谢您能看到这里，祝君心想事成、万事顺遂。

大家好，我是秦少卫，vue-fabric-editor 开源图片编辑项目的作者，很多开发者有问过我如何使用 fabric.js 实现商品定制的预览效果，今天跟大家分享一下实现思路。

预览图：

简单介绍大部分开发这类产品的开发者，都会提到一个关键词叫做 POD ，按需定制，会通过设计工具简单的对产品进行颜色、图片的修改后，直接下单，获得自己独一无二的商品。

POD是什么？

按需定制(Print On Demand，简称POD)，是一种订单履约方式，卖家提前设计好商品模板上架到销售平台，出单后，同步订到给供应商进行生产发货。

使用 fabric.js 实现商品定制预览，有 4 种实现方式

方式一：镂空 PNG 素材

这种方式最简单方便，只需要准备镂空的png素材，将图层放置在顶部不可操作即可，定制的图案在图层底部，进行拖拽修改即可，优点是简单方便，缺点是只能针对一个部位操作。

方式二：png阴影 + 色块 + 图案叠加

如果要进一步实现多个部位的定制设计，不同部位使用不同的定制图，第一种方案就无法满足了，那么可以采用透明阴影 + 色块叠加图案的方式来实现多个位置的定制。

例如这样的商品，上下需要 2 张不同的定制图案。

我们需要准备透明的阴影素材在最上方，下方添加色块区域并叠加图案：

最底部放上原始的图片即可。

方式三：SVG + 图案/颜色填充

fabric.js 支持导入 svg图片，如果是SVG形式的设计文件，只需要导入到编辑器中，对不同区域修改颜色或者叠加图案就可以。

方式四：平面图 + 3D 贴图

最后一种是平面图设计后，将平面图贴图到 3D 模型，为了效果更逼真，需要增加光源、法线等贴图，从实现上并不会太复杂，只是运营成本比较高，每一个 SKU 都需要做一个 3D模型。

参考 Demo:

codepen.io/ricardcreag…

结束

以上就是fabric.js 实现服装/商品定制预览效果的 4 种思路，如果你正在开发类似产品，也可以使用开源项目快速构建你的在线商品定制工具。

• 开源项目：github.com/ikuaitu/vue…


• 体验预览：http://www.kuaitu.cc/#/

截止至本月，我从前端研发转岗为产品经理已经一年左右了，这篇文章就讲讲我这一年中的一些经验和总结。希望能为同样身为前端也有想法转产品的你提供一点帮助。

为什么转产品

工作原因

我是22年毕业的，在刚刚毕业的那段时间，我还是对前端开发很有热情的，经常把工作中的一些内容给总结成文章在掘金发布，而且开发时我会比其他人更加注重整体的代码质量和实现的完整度，毕竟也要写文章嘛，输出倒逼输入。但是随着工作年限的增加（其实也没多少），我渐渐的感觉公司的业务没有什么挑战性了，而且最开始同事们还比较注重代码质量，但随着业务越来越复杂，排期越来越紧张，代码质量慢慢的就开始妥协了。

而且有一些功能实现方式比我想象的复杂很多，但是他们依然执着的要引用一些我不认可的框架或者库，代码这件事大家应该清楚，写的爽是很重要的，如果一个项目的实现都是我不喜欢的实现方式，为了一些虚无缥缈的性能优化把代码写的很复杂。

不知道大家有没有用过 SWR 这个请求库，我曾经写过一篇文章介绍这个工具 《都什么时代还在发传统请求？来看看 SWR 如何用 React Hook 实现优雅请求》，这是我很喜欢的一个请求库。它可以帮助我们在组件中获取请求数据时，不用在父组件获取后一个个通过 props 传递，而是直接在子组件中获取请求数据，并且不用重复请求。

但我有个同事认为直接使用 SWR 性能不好，因为每个组件都调用 hook 去请求，虽然 SWR key 是一样的，那肯定有个判重机制，这个判重机制对性能有影响。我当时就很无语，我说判重机制不就是用避免重复请求这件事情的嘛。更无语的是，他的解决方法时在父组件中使用 react context 创建上下文，通过 SWR 获取数据，将 SWR 中的数据传入 Context，然后在子组件中消费 Context。我当时就觉得这种写法就是恶心，脱裤子放屁行为，这么写何必用 SWR，直接用 Axios 请求后传子组件得了，为什么不直接在子组件里面调用 SWR 拿数据？

后面我与他掰扯，说我们按照 SWR 官方文档的方式来用就好了，无需多此一举，他的观点是 “SWR 又不是 React 官方的。他们的用法也不见得合适”，其他前端同事也没有很大异议，后续就是那段代码依然合并进去了，而且后续他都是这么写的。除此还有很多在 js 代码中使用单字母简写的变量，问就是跟xxx语言学的，我个人是觉得前端项目的变量名还是写全称，尽可能完整，让代码可读性更强，但我也懒得去争了，一旦大家的代码规范不同，那对我来说写代码就是很难受的一件事情了。关于这件事情我希望能在评论区看到大家的看法。

职业规划

其次是职业规划，这个倒不是说我最初就决定了想走产品这条路，而是我不太想一直走前端的路子了。我最初之所以选择前端开发的岗位，是由于我的大学专业是计算机相关，并且在我毕业前有过一段创业的经历，在那段经历中我担任的就是产品经理+前端开发的角色，因此找工作时也自然而然的投递前端相关的岗位。

但慢慢的，我在工作中感受不到前端技术很大的热情，脑袋里的灵感越来越少，工作上的代码写起来越来越乏味，而且社区里还是各种面试拷打，八股文，算法题最吃香。我是真的很讨厌八股文，我知道基础对于前端来说很重要，但还是讨厌，想到一旦要跳槽就要重拾八股文，我就觉得真的很无聊，所以我心理也埋下了要转产品的种子。

兴趣驱动

前面有讲到我在大学期间有创业过一阵子，当时我们一边做外包项目，一边做自己的一些校园产品，不论是网页还是移动端的产品，各个主流组件库都门清儿，而且也画过原型图，对一个产品从零到一的流程比较清晰，自己也对设计一个优秀的产品有执念，虽然至今还不算完成，但毕竟如果一件事情能让你有成就感，那么它就会推着你向前走。

怎么转的产品

在去年八月份，我们公司的产品要做一个大版本的迭代，很多功能都需要重新设计实现。在一个新产品诞生的初期，研发是依赖非常产品经理的产品文档，而产品经理则需要进行产品调研，概念设计等等流程才能写出一份产品方案，这就导致了产品有很大的产品方案设计的工作量，而研发只能先做一些基础框架搭建，写写技术方案，一旦这些简单工作做完就必须停下来等产品出文档，十几个研发两三天没活儿干，对于一个企业来说肯定是无法接受的。因此我们的领导就开始招聘产品经理，与此同时也在内部会议时主动问到有没有愿意尝试一下产品的工作。我本身就与公司里的产品比较熟悉，又有这么一个机会，于是我就毛遂自荐，并且当时在会上主动提出参与的也就我一个，于是就顺理成章的开始了研发向产品的转变。

遇到的问题

相信点进这篇文章的同学，有很多都是有过转岗为产品的想法的，那么我就说说从我自身出发，在从研发转为产品之后遇到了哪些问题是我没有意料到的。

专业知识

当研发时，每一次产品需求评审会上，我会去看这次新增了什么概念，思考这个需求如何实现，产品画的原型图交互流程有没有可以优化的地方，似乎自己对需求的理解能力还是很强的，也能够理解业务。

例如一个微信朋友圈的功能，产品经理提出放在发现页面，然后单击右上角加号可以选择照片发布，长按加号可以直接发布文字，那么我就会想长按这个操作是不是不够直观呢，会不会有用户很长时间了都没有发现这里是可以长按直接发布文字的？于是我就提出问题与产品探讨，长此以往，我会觉得我们的产品有时候考虑问题也不是特别全面嘛，给了我一种我上也行的错觉。

到了实际转变为产品经理后，你就会发现你要做的不只是思考朋友圈的发布是从个入口进去，而是老板给了你一个需求，是用户如何在微信中分享自己的动态。那这时候你就要想：

• “我是不是加一个类似 QQ 空间的功能？这个功能就叫动态？还是空间？还是叫微博？还是叫圈子？”


• “这个功能要放在我的页面还是聊天页面，还是说新增一个底部栏？”


• “这个功能和微博或 QQ 空间有什么本质上的不同？”

或者评审时有同事或领导问你“为什么要叫朋友圈？我觉得叫朋友圈我完全 get 不到是什么意思？”，你应该如何应对？

我在刚刚转产品的初期几乎每次评审都是心惊胆颤，因为我很难接住同事问的问题，而且我也不是一个性格刚猛的人，可以接受讨论但不太喜欢很激烈的争论。这个问题出在两个方面：

一是刚刚转产品，我对于过往的一些概念只是了解但没有深入了解。例如领导问道：“xxx功能为什么要这么设计？”，这个功能并不是一个新功能，而是一个存在已久的功能，但是设计上有些许不合理，但是你并不清楚这个功能具体的上下文，那么人家一问，我也只能支支吾吾。这样的经历在有过几次后就会给人一种你不够专业的感觉，你连系统里的功能设计都不清楚，你还配当产品经理？

二是对自己的职责定位及权限边界还不够清晰，以上面朋友圈的例子来说，我觉得我拍板不了朋友圈具体的名称，我得去找更有经验的同事一起讨论，虽然同事会给你提供意见参考，最终的决定还是得你来做。在方案评审时，发现领导对朋友圈这个概念设计有很多疑问，例如问你：“为什么不参考竞品？”，“这个入口放在发现页也太隐蔽了吧，我作为用户完全不会点进去？”

诸如此类的问题，刚开始我是完全接不住的，总是想着领导说的也有道理，那我就按照他的想法改吧。这样一来，领导提出的意见一旦比较尖锐，你就只能顺从，说明你没有自己的想法，没有自己的主见，即使有想法也不能坚持。尤其是你还没有足够的经验，更容易被人质疑。此时如果没有一颗大心脏，没有一个非常全面的调研和思考，就容易变得很不自信，从而丧失对产品这个岗位的工作热情。

刚刚转产品的那个月我非常煎熬，每次做方案和评审前都特别紧张，有时候睡觉前都在想要是每天同事问了这个问题要怎么回答？

与研发的对接的边界

在我还是前端的时候，我单纯的认为很多边界情况就是需要前端去考虑的，例如页面的加载状态是骨架屏还是加载动画，表单字段在输入时是失焦时触发表单验证还是点击提交按钮时触发表单验证，返回上一个页面是否需要保留页面状态，文本溢出时的省略效果如何。

但当我自己转为产品后，似乎这些情况还是得我来考虑，每天需要面对各种研发提出的各种组件边界情况如何处理，很多边界情况如果你的文档中没有写，那么研发可能就不考虑了，不做任何处理，直到问题被领导或用户发现了，这时候只要你文档中没有提，那多半就要背锅了。一个你自认为通用的空数据页，你这个页面画了图，那个页面没有画空页面的图，那么研发就可以理所当然的在这个页面没有数据时啥都不展示。

这个现象主要出现在产品初期。随着产品迭代到一定程度，产品团队和研发团队通常会达成共识。此时前端的组件已经覆盖了大多数边界场景，产品团队也了解研发团队可能在哪些地方容易疏忽，因此需要特别强调这些方面。

时间分配

前面讲到研发会时不时找你对各种事情，这就导致了你平时可能很少有大段的时间专注于做一件事，每天上午研发问几个小问题，下午问几个小问题，一天就这么过去了。相比于写代码，有时思路清晰的话就可以一整天都在写，遇到问题了再停下来查一查想一想，相对来说还是会有大片的时间去做事。

对于我个人来说，有时候一个需求给到我，我可能一时半会儿没有一个好的思路，这时候你即便怎么想，怎么查都很难有突破，但有时你睡个午觉，或者放空一下，就突然有解决方向了。这导致了我做为产品经理时比较少进入心流状态，我需要思考，需要头脑风暴，但有时候想不出来也不能僵在那儿，而一件事情悬而未决又让我很难受，就容易有焦虑的情绪。

职业规划的变化

虽然很多人说技术人员越老越不吃香，产品就不一样了，可以积累经验，未来的道路也更加广阔，有机会走的更远。话虽如此，但实际上对于前端开发来说，基本上工作的两三年就基本上对整体的前端技术栈有个深入使用的经验，无非就是 React 和 Vue 以及相关的生态，，再深入点就是一些特殊协议或者可视化方面的更深入的技术，在跳槽时，只要技术栈匹配基本都可以尝试。但是产品经理的话，通常都会要求有同个赛道的经验，例如做社交产品的公司，当然希望找有社交产品经验的产品经理，而产品的赛道可就多了

前端转产品的优势

前面提了这么多研发转产品可能遇到的问题，也不能光抽巴掌不喂糖，所以下面再讲下前端转产品的优势，这些点大家可能会更有共鸣一些。

技术背景

关于这一点，有很多网上的文章唱反调说你有研发背景，肯定满脑子技术思维，做产品的时候创新能力肯定不行，你被你技术背景束缚啦。

这一点从我个人出发，我只能说产品懂技术绝对是一个优势，无论是从功能设计，到与研发沟通，天然的少了一层隔阂，尤其我们公司的产品是基础软件，用户群体本身就是相对懂技术的人。刚刚转为产品经理时，产品相关专业能力虽然不足，考虑事情不周全，但是懂技术起码给你兜了底，你不会有过于天马行空的想法，研发在你面前不能也信口开河，大致的实现成本，排期时间你能够做到心里有数。

前端思维

前端思维和技术背景还是有些不同的，前端和后端对产品的理解方向有些不同，前端偏向交互，后端更偏向业务。因此这里我将技术背景和前端思维分开讲。

不同公司使用的原型工具可能不同，我们公司是直接由产品来出高保真原型，因此我们使用的工具是 Figma，
在我转岗产品一个月左右 《👨‍💻 Figma 协作设计工具：前端开发者视角快速上手指南》 我就写了一篇关于 Figma 的使用文章，我认为我的 Figma 上手速度是非常快的，这可能由两方面的因素。

• 一是我大学的时候就有自学平面设计，对于 PPT，PS 这类创意类工具的使用方式比较了解。


• 二就是前端思维了，因为做原型其实和用代码写页面的思路是一致的，你看到了一个页面，首先你会想这个页面会由哪些组件组成，这些组件是否已经实现过了？如果没有实现过是否可以抽离到组件库进行复用？

Figma 这个工具是我转产品后，公司才开始使用的，因此大家都不熟悉，那么交互设计的大头就落在我身上，我就拉着我们的 UI 同学一起搭建了一个组件库，这个组件库中包含了常用的所有表单组件，表格组件，还有一些页面组件，其中我根据过往的经验为组件配置了很多参数和插槽，保证插件的拓展性。

如果我没有前端相关的经验，我敢肯定从头要去了解这套组件体系，并熟练的去构建出一套兼容性好的组件库。是要花很多时间的。

后续我们还用上了 Figma 的分支管理功能，这一点和 Git 的分支管理也有些许类似，逻辑上的快速迁移学习为我上手相关工具增速了很多。

对未来的思考

虽然在当前公司已经当了一年的产品经理了，大部分的事情都可以轻松 cover，也算是处于舒适圈了，但是心里还是会焦虑，毕竟目前只是身处一个小公司，而且在产品方面的专业能力又难以评估，网上想要学习关于产品经理的相关专业知识几乎都是卖课的，而且我愈发觉得产品相关的知识不是看任何书籍或课程可以快速提升的，产品经理相关的能力以及可能碰到的问题都是要在解决实际需求的过程中去提升，而且专业的能力与产品的赛道息息相关，你在一个赛道的积累可能换个赛道就派不上用场了，因此还是得持续学习，让自己不论做什么行业都能保持竞争力。

代码的话现在偶尔写写自己感兴趣的小项目，只是没那么多了，公司内偶尔也需要我去支援研发。如果大家有有意思的小项目，小比赛欢迎拉我一起去折腾（不做外包）。

最近我的朋友，被某些知识付费坑得很惨。全程毫无干货可言。内容仅仅只适用于初级、或者说部分中级的程序员。为此，我的朋友交了大几千的学费，却收获甚微。

当然，你可能说，是你的朋友问题啊？你朋友烂泥扶不上墙，学习方法不对，别人都有很多成功的案例。什么offer收到手酸，外包入大厂。

我买这些课就是为了学习，入门一些语言。知识付费很合理呀！！

于是我跟我朋友在微信彻夜长谈，有了如下分析

先说结论

请擦亮你的慧眼，你的一分一毫来之不易。不到迫不得已，才当学费

为什么这么说？

首先，不管你是想就业，还是想学习一些新的技术，网上都有例子，github上也会有前沿的项目提供学习。

其次，你学费，一定要做到利益最大化。必须要有以下两点

• 能学到大部分人都学不到的技术亮点。记住，是大部分人，一定要做到差异化


• 能学到优秀的学习方法,push你前进。

开启慧眼

现在市面的学习机构，鱼龙混杂。，B站大学,某识xin球，某ke时jian 甚至，在某音上，都有那种连麦做模拟面试，然后引导你付费学习。

就业环境不好，买方市场竞争激烈，某些人就抓住你的焦虑心理，坑你一把。回想你的求学生涯，是否也有类似被坑经历？醒醒吧，少年。能救你的，只有你自己。

当然，小海也会有潜龙。不可否认，知识付费为我们提供了便利性。

• 原本散乱无章的知识点，人家给你整理好了，你尽管就是学习，实践


• 面对焦虑，你觉得很迷茫，需要一个人指点你前进


• 能认识更多同样诉求的人，为以后学习，就业，甚至做生意提供可能

但是，某些不法分子，就是抓住你的这个心理，疯狂ge你韭菜。什么10块钱知识手册，19.9面试题，100块钱的项目视频。天天一大早，就转发一些公众号到你群上，dddd。

这些内容，不是说没有用。我们讨论适合人群，这类东西不适合中高级程序员。

说那么多，你得学会判断这个人是不是大佬

你都可以简历包装，为什么‘大佬’就不会是被包装的

那就稍微整理一下，哪些是真大佬，伪大佬

真伪大佬

就学习人群做一个说明

• 在就业容易程度上，相对于初中高级别的程序员，应届生无论从考察的内容，招聘的人数。都会容易丢丢。


• 他说跟着他学，offer赢麻了。但是其中，找到工作的大多数都是应届生

就这些点，我们其实可以能判断个大概了。

记住，你想知识付费。一定要摸清他的底细，不能认为他说得都是对的。人家也是会包装的

你的hello world

或许每个程序员的第一行代码，都是

    print("hello world")

我想说的是，请你记住你的初心。

• 转行过来当程序员，就是为了狠狠赚他一笔


• 喜欢写代码，苦中作乐

情况每个人都不太一样，这里不细说。明白你是谁，你还是否有动力能坚持下去。明白这一点，远比你在迷茫的时候病急乱投医更为重要，请勿过度焦虑

为此，后面会说一下如何学习，以及找工作如何不被骗

力量大会

事关钱包的问题，我们都得谨慎谨慎。就业市场那恶劣，朋友找不到工作还被坑了一把。骗子实在可恶。请你先自身强大，先自己找出问题，不花冤枉钱，避免传销式编程

如有雷同，纯属巧合，没有针对任何人，也没有动某些人的饭碗。

前段时间，在小米14的发布会上，雷布斯公布了名为“Xiaomi Ultra Space存储扩容”的技术，号称可以在512G的手机中再搞出来16G，256G的手机中再搞出8G。对于普通用户来说，能多得一些存储空间，无异是个很好的福利，不过也有网友说这是以损害存储使用寿命为代价的，那么真相到底如何呢？这篇文章我就从技术角度来给大家详细分析下。

认识闪存

首先让我们来了解一些手机存储的基本知识。

手机存储使用的是闪存技术，其本质和U盘、固态硬盘都是一样的。

在闪存中读写的基本单位是页（Page），比页更大的概念是块（Block），一个块会包含很多页。

虽然读写的基本单位都是页，但是写实际操作的很可能是块，这是为什么呢？

这要从删除谈起，在闪存中删除数据时不会立即删除页上的数据，而只是给页打上一个空闲的标签。这是因为谁也不知道这个页什么时候会再写入数据，这样处理起来比较简单快速。

再看写操作，如果写入分配的页是因为删除而空闲的，数据并不能立即写入，根据闪存的特性，此时需要先把页上之前存储的数据擦除，然后才能写入；但是闪存中擦除操作的基本单位是块，此时就需要先把整个块中的有效数据读出来，然后再擦除块，最后再向块中写入修改后的整块数据；这整个操作称为“读-改-写”。当然如果写入分配的页是空白的，并不需要先进行擦除，此时直接写入就可以了。

预留空间

小米这次抠出来的存储空间来源于一个称为“预留空间”的区域，它的英文全称是Over Provisio，简称 OP。

那么“预留空间”是什么呢？我将通过5个方面来介绍它的用途，让大家近距离认识下。

提高写入速度

在上面介绍闪存的基本知识时，我们谈到闪存的写操作存在一种“读-改-写”的情况，因为额外的读和擦除操作，这种方法的耗时相比单纯的写入会增加不少，闪存使用的时间越长，空白的空间越少，这种操作越容易出现，闪存的读写性能下降的越快。

为了提升写入的性能，我们可以先将新数据写入到预留空间，此时上层系统就可以认为已经写入完成，然后我们在后台将预留空间中的新数据和原数据块中需要保留的数据合并到一个新的数据块中，这样就避免了频繁的读-修改-写操作，从而可以大大提高写入速度。

垃圾回收和整理

在上面介绍闪存的基本知识时，我们还谈到删除数据并不是立即清除空间，而是给数据页打一个标签，这样做的效率比较高。这样做就像我们标记了垃圾，但是并没有把它们运走，时间久了，这些垃圾会占用很多的空间。这些垃圾空间就像一个个的小碎片，所以有时也把这个问题称为碎片化问题。

虽然我们可以通过“读-改-写”操作来重新利用这些碎片空间，包括通过异步的“读-改-写”操作来提升上层应用的写入效率，但无疑还是存在写入的难度，实际写入之前还是要先进行擦除。

为了解决上述问题，聪明的设计师们又想到了新办方法：让存储器在后台自动检测、自动整理存储中的数据碎片，而不是等到写入数据时再进行整理。

考虑到闪存的读擦写特性，当需要移除数据块中部分碎片或者将不同数据碎片合并时，就得把需要保留的数据先放到一个临时空间中，以免数据出现丢失，待存储中的数据块准备好之后再重新写入，预留空间就可以用作这个临时空间。

磨损均衡

闪存中每个块的写入次数都是有限制的，超过这个限制，块就可能会变得不可靠，不能再被使用。这就是我们通常所说的闪存的磨损。

为了尽可能延长闪存的使用寿命，我们需要尽量均匀地使用所有的闪存块，确保每个块的使用频率大致相同。这就是磨损均衡的主要目标。

假设我们发现块A的使用频率过高，我们需要将它的数据移动到没怎么用过的块B去，以达到磨损均衡的目的。首先，我们需要读取块A中的数据，然后将这些数据暂时存储到预留空间。然后，我们擦除块A，将它标记为空闲。最后，我们从预留空间中取出数据，写入到块B。实际上，磨损均衡的策略比这更复杂，不仅仅是看使用频率，还需要考虑其他因素，比如块的寿命，数据的重要性等。

可以看到，预留空间在这个过程中起到了临时存储数据的作用。

不过你可能会问，为什么不直接将块A的数据复制到块B，而需要一个临时空间？

这是因为在实际操作中直接复制块A的数据到块B会带来一些问题和限制。

假如直接进行这种数据复制，那么在数据从块A复制到块B的过程中，块A和块B中都会存在一份相同的数据，如果有其他进程在这个过程中访问了这份数据，可能会产生数据一致性的问题。此外，如果移动过程中发生意外中断，如电源故障，可能会导致数据在块B中只复制了一部分，而块A中的数据还未被擦除，这样就可能导致数据丢失或者数据不一致的问题。

而如果我们使用预留空间，也就是引入一个第三方，就可以缓解这些问题。我们先将数据从块A复制到预留空间，然后擦除块A，最后再将预留空间中的数据写入到块B。在这个过程中，我们可以借助预留空间来实现一些原子性的机制，来保证数据不会丢失和数据的一致性。

错误校正

预留空间还可以用来存储错误校正码（ECC）。如果在读取数据时发现有错误，可以用错误校正码来修复这些错误，提高数据的可靠性。

很多同学可能也不了解这个错误校正码的来龙去脉，这里多说几句。

我们知道计算机中的数据最终都是二进制的0和1，0和1使用硬件比较好表达，比如我们使用高电压表示1，低电压表示0。但是硬件有时候会出错，本来写进去的是1，读出来的却是0。为了解决这个问题，设计师们就搞出来个错误校正码，这个校正码是使用某些算法基于要存储的数据算出来的，存储数据的时候把它一起保存起来。读取数据的时候再使用相同的算法进行计算，如果两个校正码对不上，就说明存储的数据出现错误了。然后ECC算法可以通过计算知道是哪一位出现了错误，改正它就可以恢复正确的数据了。

注意ECC能够修正的二进制位数有限，因为可以修复的位数越多，额外需要的存储空间也越大，具体能修复几位要考虑出现坏块的概率以及数据的重要性。

坏块管理

当闪存单元变为坏块时，预留空间可以提供新的闪存单元来替代坏块，此时读取对应数据时不再访问坏块，而是通过映射表转到预留空间中读取，从而保证数据的存储和读取不受影响，提高了固态硬盘的可靠性和耐用性。

综上所述，预留空间在提升固态硬盘性能，延长其使用寿命，提高数据的可靠性等方面发挥着重要的作用。

小米的优化

根据公开资料，小米将预留空间的占比从6.9%压缩到了约3%。

那么小米是怎么做到的呢？以下是官方说法：

小米在主机端也基于文件管理深度介入了 UFS 的资源管理，通过软件实现“数据非必要不写入（UFS）”，通过软件 + 固件实现“写入数据非必要不迁移”，减少写入量的同时也实现了更好的 wear-leveling 和 WAF

还有一张图：

优化解读

这里用了一些术语，文字也比较抽象，我这里解读下：

UFS（Universal Flash Storage）即通用闪存存储，可以理解为就是手机中的存储模块。

“数据非必要不写入（UFS）”也就是先把数据写入到缓冲区，然后等收到足够的数据之后（比如1页），再写入闪存单元，这样就可以减少闪存单元的擦写次数，自然就能延长闪存单元的使用寿命，推迟坏块的产生。这个缓冲区类似于计算机的内存，如果突然掉电可能会丢失一部分数据，但是对于手机来说，突然掉电这个情况发生的几率极低，所以小米在这里多缓存点数据对数据丢失的影响很小，不过还是需要注意缓冲空间有限，这个值也不能太大，具体多少小米应该经过大量测试之后做了评估。

“写入数据非必要不迁移” 没有细说怎么做的，大概率说的是优化磨损均衡、垃圾回收和整理策略，没事别瞎整理，整理的时候尽量少擦写，目的还是延长闪存单元的使用寿命。

“增加坏块预留” 小米可以根据用户的使用情况调整坏块预留区的大小，比如用户是个重度手机使用狂，他用1年相当于别人用4年，小米系统就会增加坏块预留区，以应对擦写次数增加带来的坏块几率增加。注意这个调整是在云端实现的，如果手机不联网，这个功能还用不上。

wear-leveling：就是上面提到的磨损均衡，小米优化了均衡算法，减少擦写。

WAF：写放大，Write Amplification Factor，缩写WAF。写放大就是上面提到的“读-改-写”操作引起的，因为擦除必须擦掉整个块的数据，所以上层系统只需要写一个页的情况下，底层存储可能要重写一个块，从页到块放大了写操作的数据量。因为闪存的寿命取决于擦除次数，所以写放大会影响到闪存的使用寿命。

概括来说就是，小米从存储的预留空间中抠出来一部分作为用户存储，不过预留空间的减小，意味着坏块管理、错误纠正等可以使用的空间变小，这些空间变小会减少存储的使用寿命，所以小米又通过各种算法延缓了手机存储的磨损速度，如此则对大家的使用没有什么影响，而用户又能多得一些存储空间。

小米的测试结果

对于大家担心小米手机存储的寿命问题，小米手机系统软件部总监张国全表示:“按照目前重度用户的模型来评估,在每天写入40GB数据的条件下, 256GB的扩容芯片依然可以保证超过10年, 512GB可以超过20年,请大家放心。”

同时一般固态硬盘往往都拥有5年的质保，而很多消费者往往会5年之内更换手机。因此按着这个寿命数据来看，普通消费者并不用太担心“扩容芯片”的寿命问题。所以如果你的手机用不了10年，可以不用担心这个问题。

当然更多的测试细节，小米并没有透漏，比如读写文件的大小等。不过按照小米的说法，存储的供应商也做了测试，没有什么问题。这个暂时只能相信小米是个负责任的企业，做好了完备的测试。

最后小米搞了这个技术，申请了专利，但是又把标准和技术方案贡献给了UFS协会，同时还要求存储芯片厂商设置了半年的保护期，也就是说技术可以分享给大家，但是请大家体谅下原创的辛苦，所以半年后其它手机厂商才能用上。

大家猜一下半年后其它手机厂商会跟进吗？

背景

转眼写代码有10多年了，林林总总花费了很多的钱，现在主要按照4大件来盘点下我都买了啥。

电脑

acer 4741g ¥4500+

这是我入门时的一款电脑，整体配置在当时还是属于中等的。



当时用的编辑器还是notepad++，在这个配置下，还是可以愉快的编码的。

mac air 2013 ¥8800+

当时被苹果的放进信封的广告创意所折服，这也是我的第一台apple，在之后就一直用苹果了。到手后的感觉是，薄，确实薄，大概只有我宏基的1/3-1/4厚。

当时apple的简洁，快速，很少的配置，让我在环境变量上苦苦挣扎的心酸得以释放。以后也不用比较各种笔记本参数了

mac book pro13 2015 ¥9000+

当时买这台的原因是因为air进水了，经常死机，修了2次后，又坏了。一怒之下，直接买了一台。

换了新的retina屏之后，色彩质量和效果都提升了不少，对比原来的air性能也是拉升了超级多。但是因为是16上半年买的，所以没体验到toch bar，到现在都没体验过。。。

这是我真正意义上的第一台十分满意的电脑，大概是当时的理想型了。

公司电脑

2016年下半年进了一家创业公司，公司配置了mac book pro，比我的配置还高，所以之后一直就是用公司的。

2021年换新公司，公司配了thinkpad，又一次开始用win。然后又被win各种打败，有时又有了换回mac的想法。

当前–mac book pro14 2021 ¥21999

主要入手的原因是公司的电脑我觉得太慢了。当时开发小程序，脚手架是公司自己的，每次打包都是全量的，没有缓存。所以每次打包短则7，8分钟，长则10多分钟。加上切分支/安装依赖（如果两个分支依赖版本不同，需要强制更新），导致我每天花费大量的时间等待上。

同事早于我入手了M1，反馈巨好，于是我也买了，想着配置拉的满点，但是还是高估了自己的钱包，低估了苹果的价格，只能退而求其次的选择了中档配置。

每次看着低低的负载，都是满满的安全感。



另外m1是支持stable diffusion的，所以偶尔我也会炼丹

显示器

dell U2424H ¥1384

其实在写代码之前也买过几台显示器，但是以程序员视角来说，第一台是这台。原因是当时公司也是这个型号，主要是能旋转，谁能拒绝一台自由旋转的显示器呢？

而且dell的质量和做工都不错，在当时是十分喜欢的。

小米 Redmi 27 ¥789.9

dell那台显示器是放在家里的，公司也需要显示器，而且自带设备每个月可以补贴100，所以就入手了这款，原因无他：便宜，也够大。

但是用久了，发现也有些问题。例如失真等，但是真的便宜，

厂家送寄，但因为合作内容没谈拢，本周寄回

键盘

当前-cherry G80-3000 ¥689

一把真正可以用到包浆的键盘，大多数看到这个键盘的感觉应该都是黄色，而不是原本的白色，不知道是不是材质的问题，极其容易变黄。同时由于键帽又不变黄，所以呈现了诡异的脏脏的颜色。

因为本身机械键盘的高度，所以建议加个手托比较好。各种轴也齐全，任君选择。

目前这个键盘在家里游戏了，毕竟是个全键盘

当前–京造C2 ¥253

选择这个键盘的原因嘛，同事有了，并且是一个带灯的键盘。手感比cherry硬一些，但还属于是能接受的程度，整体延迟比较低（也可能是因为有线的原因）。目前是在办公室使用的一款，当前这篇文章就是用这个敲出来的。

鼠标

总览

鼠标其实留在手边的不太多，大多数都是消耗品了，这么些年，各种有用过。大概用了不下10个鼠标，我只挑2个重点的说吧。

微软ie 3.0 ¥359

这是我用过最好的鼠标，没有之一。握感极佳，用久了也不累，比其他的鼠标都舒服万分。

当前–apple magic trapad ¥899

mac用户的最终归属就是板子，如果你刚开始用mac，那么建议直接用板子吧。支持原生手势操作，各种mac本身触控板的事情都完美适用，真正的跟你的电脑和为一体。

欢迎评论区留言你的设备

如上所述，我这年的大头是电脑，消耗品是鼠标、，那么你都花了多少钱呢？

前言

看到不少私信问我为啥没有更新了，我没有一一回复，实在是身体抱恙，心情沉重，加上应付于工作，周旋于家庭，自然挤压了自我空间。

今天思来想去，重新执键，决定久违地又一次写点分享，奉劝大家珍惜身体，愉悦生活。

愉悦二字说来容易，但各位都一样，奔波于现实，劳累于生活，岂是三言两语就能改变的。

病来如山倒

我又病了，有些意外和突然的，令我措手不及。

一天早上我起来，脖子有些酸，就伸手揉揉捏捏，忽然发现脖颈左侧有一个肿块，仔细拿捏，发现竟然是在里面，而且硬邦邦的，伴有轻微的疼痛感。

当时早上对着镜子拍下来的肿块，我还保留了照片。

立马便一身冷汗冒出，我从未经历过这样的事情，去年身体毕竟出过问题，两相叠加之下，内心更是难以描述。

因为是周一，怀着忐忑的心情去上班了，接下来一直都有些神经兮兮，觉得自己身体出了大问题。

之前我有文章讲过自己去年其实已经检查出血脂的问题，停更半年之久，调养了一番，才真正感觉到身体有所恢复，根据我发文的日期可见一二。

恢复更新的这段时间，报复式地写作和分享，一度不知不觉地排到榜单第二，今天登录看了一下，居然还在月榜前三没下来，也是意外。

话说回来，人一旦身体冒出点病痛，整个心情都显得低沉萎靡，很快就能在方方面面反应出来。

我是硬着头皮上班的，抽空网上查了下好让自己有个心理准备。

百度一搜便是绝症，这是很多年前就知道的，但病急乱投医果然是人之本性，我毅然决然还是搜了。

然后，各种甲状腺之类的就来了，再搜，淋巴瘤也来了，再搜，好家伙，直接恶性肿瘤十有八九了。

面对未知而产生的接近绝望的心情，想必不少人有类似经验。

比如我，下意识先想到的竟然不是我是不是要完蛋了，而是想到自己是家中独子，父母年迈身体有恙，妻子操劳，孩子尚小，家中主要经济来源也是我。

我一旦倒下，实在不敢想，往深了一想各种负面因子都蜂拥而来。

我不知道有多少人和我的性格相似，就是身体出了这种未知的问题，一面觉得应该去医院看看，一面又怕折腾来去最后拿到最不可接受的结果，可能不知道反而能活久一点，大概就是这种心情了。

是的，我大体是个胆子还算大的人，也猛然间抗拒去医院了。

不去医院的结果，就是你每天都在意这个肿块，每天都要摸摸它是不是变小了，是不是消失了，每天都小心呵护着它，甚至还想对它说说话倾诉一下，像是自己偷养的小情人一样。

只盼着某天睡觉醒来，用手一摸，哈哈没有了这样。

我就是差不多一个月都这样惶惶不可终日地度过，直到这周六才被妻子赶去医院做了检查。

透支和还债

30岁之前透支，30岁之后还债。

说来好笑，摸到肿块的第二天吧，还有朋友私信找我合作，换做平时，我肯定欣然接受，并开始设计文稿。

但身体有问题，一切都索然无味了，再次真切地体会到这种被现实打碎一切欲望的撕裂感。

为什么我30岁之后身体慢慢开始出现各种问题，这两年我有静下心来思考过。

到底还是30岁之前透支太多了，30岁之后你依然养成30岁之前的生活习惯，无异于自杀行为。

我把身体比作一根橡皮筋，它大概只能扯那么长，我长期将它扯那么那么长，我以为它没事，直到有一次我将它扯那么那么那么长，砰的一声它就断了。

我们都无法知道自己的这根橡皮筋到底能扯多长，只要它没断，我们都觉得它还能扯很长，代价就是，只需断一次，你再也无法重来了。

30岁之前，我努力学习各种知识，熬夜那是家常便饭，睡一觉便生龙活虎。

我就像以前上学的三好学生一样，在学校我扎扎实实，放学了我还进补习班，补习班回来了我还上网学知识。

回头想想，真特么离谱啊，我上学都没这样，走上社会了竟然付出了之前在学校几倍的努力。

早知如此，我好好上学读书最后进入一个更优质的圈子，不就少走很多弯路了吗，但是谁又会听当年的老师和父母一番肺腑之言呢。

埋怨过去没有什么意义，只能偶尔借着都市小说幻想一下带着记忆重生回校园的自己。

细数下来，我30岁之前熬过的夜比我加的班还多，我不是天天加班，但好像真的天天熬夜。

可我身体一点问题都没有，我觉得自己不是那种被命运抛弃的人，内心一直这么侥幸，你是不是也和我一样呢。

30岁之后，该来的还是来了，32岁那年，我有一次咳嗽入院，反复高烧，退了又发烧，医生一度以为是新冠，或结核，或白血病什么的，后来全部检查了都不是，发现就是普通的肺部感染。

每天两瓶抗病毒的点滴，大概半个月才逐渐恢复，人都瘦脱相了，这是我人生头一次住院，躺在病床上像废人一样。

等到33岁也就是去年，偶然头晕了一次，那种眩晕，天旋地转，犯恶心，怎么站怎么坐怎么躺都不行，真正要死的感觉。

后面我一度以为是年纪轻轻得了高血压，结果查了下是血脂的问题，还不算严重，但继续下去很可能会变成一些心脑血管疾病。

我难以置信，这可都是老年病啊，我一个30几岁的程序员说来就来了？

调养半年多，肉眼可见身体有好转，我又开始没忍住熬夜了，想做自己的课题，想分享更多的东西，这些都要花时间，而且包括一些其他领域的内容，想得太多，自然花的时间就多。

一不小心就连续熬了一个多月，平均每晚都是2点左右躺下，有时中午还不午休，刷手机找素材。

终于，脖子上起了肿块，让我整个人都蒙圈了，觉得一切努力都是在玩弄自己，忽然间什么都没意思了。

我尽量把这种感受描述出来，希望你们能看明白，真切体会一二。

为什么30岁之后我一熬夜就有问题出现，说白了，30岁之前透支了已经，一来是身体负荷达到临界，二来养成了多年的坏习惯，一时想改还改不过来。

30岁之前真别玩弄自己的身体了xdm，橡皮筋断了就真断了，接不上了，接上了也没以前的弹性了。

健康取决于自律和心情

对于程序员来说，健康取决于两点：自律和心情。

30岁之前，请学会自律，学习时间自律，生活作息自律，一日三餐自律，养成这样的习惯，30岁之后的你会受益匪浅。

自律真的很难，我就是一个很难做到的人，我有倔强地适应过，却又悲哀地失败了。

就像你是一个歇斯底里的人，忽然让你温文尔雅，你又能坚持多久呢。

我用很多鸡汤说服过自己，对于已经30几岁的我来说，也只能维持一段时间。

想看的多，想玩的多，想学的也多，时间是真不够啊，真想向天再借五百年。

我应该算是幸运的那一类，至少我这般透支身体，我还活着，也没用余生去直面绝望。

我用这两年的身体故障给自己上了重要的一课，人死如灯灭。

如果能重来，我一定会学习时间规划，我一定会把每天的时间安排的好好的。

我一定会保证一日三餐不落下，少吃外卖，多吃水果蔬菜。

我一定会保证每晚充足的睡眠，早睡早起，绝不熬夜。

我一定会每天下班和放假抽出一些时间运动和锻炼。

我不是说给自己听的，因为我已经透支了。

我是说给在看文章的你们听的，还年轻点的，还没透支的，请用我的现在当做你可能更坏的未来，早点醒悟，为时不晚。

自律很难，但不自律可能等死，这个选择一点也不难。

工作压力大，作为程序员是避免不了的，所以我以前有劝过大家，薪水的重要性只占一半，你应该追寻一份薪水尚可，但压力一定在承受范围内的工作，这是我认为在国内对于程序员来说相对友好的途径。

我进入IT行业目前为止的整个生涯中，学习阶段听到过传智播客张孝祥老师的猝死，工作阶段听说过附近的4396游戏公司里面30多岁程序员猝死，今年又听到了左耳朵耗子先生的离世。

我想着，那一天，离我和你还有多远。

心情真的很重要，至少能快速反应在身体上。

当我这周六被妻子劝说去检查的时候，我内心一直是紧张的，妻子没去，就在家陪着孩子，跟我说你自己去吧，如果有坏消息就别回复了，等回来再说，如果没什么事那就发个微信。

我想我理解她的意思了，点了点头就骑车去了医院。

医院真不是什么好地方，我就是给医院干活的，我全身上下都讨厌这里。

最煎熬的时间是做彩超前的一个多小时，因为人太多，我得排队，盯着大屏上的号序，我脑子里想了很多事情，甚至连最坏的打算都想好了。

人就很奇怪，越是接近黑暗，越是能回忆起非常多的往事，连高中打篮球挥洒汗水的模样和搞笑的投篮姿势都能想起来。

喊到我的时候，我心跳了一下，然后麻木地进去了，躺下的时候，医生拿着仪器对着我的脖子扫描，此时的我是近一个月以来第一次内心平静，当真好奇怪的感觉。

随着医生一句：没什么事，就一个淋巴结。

犹如审判一般，我感觉一下无罪释放了。

当时听到这句话简直犹如天籁，这会儿想起来还感觉毛孔都在欢快地愉悦。

我问她不是什么肿瘤或甲状腺吧，她说不是，就一个正常的淋巴结，可能是炎症导致了增生，这种一般3个多月至半年才会完全消掉。

这是当时拍的结果

拿给主任医师看了之后，对方也说一点事没有，只是告诫我别再熬夜了。

我不知道人生还会给我几次机会，但我从20几岁到30几岁，都没有重视过这个问题，也没有认真思考过。

直到最近，我才发现，活着真好。

当晚是睡得最踏实的一晚，一点梦都没做，中途也没醒，一觉到天亮。

更离谱的是，早上我摸了一下脖子，竟然真的小了点，这才短短一天，说了都没人信。

我头一次相信，心情真的会影响身体，你心情好了，身体的器官和血液仿佛都欢腾了起来。

如何保持一个好心情，原来这般重要，我拿自己的身体给大家做实验了，有用！

希望大家每天在自律的基础上保持好心情，不负年华，不负自己。

总结

xdm，好好活着，快乐活着。

早前搭过一个wiki (可点击wiki.dashen.tech 查看),用于"团队协作与知识分享".把游客账号给一位前同事,其告知登录出错.

用我记录的账号密码登录,同样报错; 打开数据库一看,疑惑全消.

To recover your lost Database and avoid leaking it: Send us 0.05 Bitcoin (BTC) to our Bitcoin address 3F4hqV3BRYf9JkPasL8yUPSQ5ks3FF3tS1 and contact us by Email with your Server IP or Domain name and a Proof of Payment. Your Database is downloaded and backed up on our servers. Backups that we have right now: mm_wiki, shuang. If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise.

(按照今日比特币价格,0.05比特币折合人民币4 248.05元..)

大多时候不使用该服务器上安装的mysql,因而账号和端口皆为默认,密码较简单且常见,为在任何地方navicat也可连接,去掉了ip限制...对方写一个脚本,扫描各段ip地址,用常见的几个账号和密码去"撞库",几千几万个里面,总有一两个能得手.

被窃取备份而后删除的两个库,一个是来搭建该wiki系统,另一个是用来亲测mysql主从同步,详见此篇,价值都不大

实践告诉我们，不要用默认账号，不要用简单密码，要做ip限制。…

• 登录服务器,登录到mysql:

mysql -u root -p

• 修改密码:

尝试使用如下语句来修改

set password for 用户名@yourhost = password('新密码');

结果报错;查询得知是最新版本更改了语法,需用

alter user 'root'@'localhost' identified by 'yourpassword';

成功~

但在navicat里,原连接依然有效,而输入最新的密码,反倒是失败

打码部分为本机ip

在服务器执行

-- 查询所有用户

select user from mysql.user;

再执行

select host,user,authentication_string from mysql.user;

user及其后的host组合在一起,才构成一个唯一标识;故而在user表中,可以存在同名的root

使用

alter user 'root'@'%' identified by 'xxxxxx';

注意主机此处应为%

再使用

select host,user,authentication_string from mysql.user;

发现 "root@%" 对应的authentication_string已发生改变;

在navicat中旧密码已失效,需用最新密码才可登录

参考:

mysql 5.7 修改用户密码

关于修改账号,可参考此

这不是第一次遭遇"比特币勒索",在四月份,收到了这么一封邮件:

后来证明这是唬人的假消息,但还是让我学小扎,把Mac的摄像头覆盖了起来..