前言 在Vue项目开发过程中，状态管理是至关重要的环节。随着Pinia的推出，它凭借更简洁直观的API，逐渐成为Vuex的有力替代品。为了进一步简化本地存储的管理，pinia-plugin-persistedstate 插件应运而生，它能够帮助开发者轻松实现状态的持久化。 本文将详细介绍如何使用该插件，并解决在跨项目登录时由于数据格式不一致导致的问题。 安装插件 在项目的根目录下运行以下命令以安装插件： npm i pinia-plugin-persistedstate 随后，在main.ts文件中引入并配置插件： import { createPinia } from 'pinia' import piniaPluginPersistedstate from 'pinia-plugin-persistedstate' const pinia = createPinia() pinia.use(piniaPluginPersistedstate) 完成以上步骤后，Pinia便具备了持久化功能。 基本使用 假设我们需要管理用户信息userInfo，并将其持久化到本地存储中，那么就可以这样实现： import { defineStore } from 'pinia'; export const useUserInfoStore = defineStore('userInfo', { state: () => ({ userInfo: null as any }), persist: true, actions: { setUserInfo(info: any) { this.userInfo = info; } } }); 按照上述配置，用户信息将自动持久化到本地存储中。 仅持久化对象中的特定字段 在实际应用中，开发者可能会面临跨项目登录时出现的兼容性问题。具体场景为：用户在项目A完成登录操作后，随即打开项目B。由于Token的复用机制，项目B会自动完成登录流程。然而，在尝试获取用户信息userInfo时，由于不同项目对数据格式的定义存在差异，导致项目B无法准确获取用户的ID，进而无法基于此ID发起正确的网络请求。具体表现如下： 项目A的数据格式：{ name: 'xiaoming', nick_name: '小明', userID: '9527' } 项目B的数据格式：{ userInfo: { name: 'xiaoming', nick_name: '小明', userID: '9527' } } 由于插件默认将整个state对象存储起来，导致数据多了一层userInfo外壳，从而引发格式不一致的问题。 为了去掉userInfo这一层外壳，我们需要自定义序列化和反序列化逻辑。修改后的Store配置如下： import { defineStore } from 'pinia'; export const useUserInfoStore = defineStore('userInfo', { state: () => ({ userInfo: null as any }), persist: { key: 'userInfo', storage: localStorage, paths: ['userInfo'], // 明确声明要持久化的字段 serializer: { serialize: (state: any) => JSON.stringify(state.userInfo), deserialize: (str: string) => ({ userInfo: JSON.parse(str) }) } } as any, actions: { setUserInfo(info: any) { this.userInfo = info; } } }); 经过上述配置，用户信息的存储结构变为{ name: 'xiaoming', nick_name: '小明', userID: '9527' }，不再有额外的userInfo外壳，从而解决了跨项目登录时的格式不一致问题。 ...

前言 项目的任务质量如何保证？在我看来，主要取决于以下这几个环节：需求要明确、任务开发时间要合理评估、任务需提供测试用例、在项目进度会议上进行功能演示。产品质量是生产出来的，不是检验出来的，不可能全都依赖于验收环节，毕竟那时已经晚了。验收环节只是为任务的质量加了一层防护，应从源头开始，就要不断地关注和解决存在的问题。 需求要明确 需求要明确，这一点在前面几篇文章中都反复提到过，这里就不再赘述了。简而言之，就是产品的需求要具体到可量化的程度。比如我要买苹果，应该是我要买10斤XXX牌子的苹果。 任务开发时间合理评估 在评估任务开发时间的时候，要根据实际情况，不能过于宽松。比如一个设备列表的功能排个两三天就差不多了，硬是排了一周多，这显然是有问题的。但也不能太严格，比如就给一天的时间，这就存心为难他人了，大可不必，实事求是就好了。 有人觉得开发任务只要时间够长，那么交付的功能质量一定就更好，实际上并非如此。人性本就如此，很少有人会提前完成任务，大部分人都会压到最后一刻才说做完了，不过，这也没什么可指摘的，人之常情。 所以，任务开发所需的时间，通常以一个“跳一跳能够够得到”的要求去评估即可。 **我们不会要求一个只能跑10公里的人去跑马拉松，我们只会要求他不断地跑到10公里、11公里和9公里，而不是他每次都只跑了5公里。**道理是一样的，没有什么是十全十美的，只希望每个人都能在自身能力范围内做到最好，仅此而已。 任务需提供测试用例 我们开发人员在开发完成之后，就匆忙提交任务进度为100%，意味着任务已经完成了。但是在验收人去验收的时候，还是经常发现这样或那样的问题。 为了解决这个问题，就需要把全部的问题都放到明面上，而不是藏着掖着，让大家都能清楚地知道，哪些功能确实是真的验收了。 这就需要开发人员在开发完成这个功能之后，提供一个自测报告，也就是在AgileTC测试用例管理平台编写这个功能的测试用例（在《AgileTC测试用例管理平台的基本使用》这篇文章中有介绍过如何使用），把全部功能要测试的点依次列出。 这样验收人在验收功能时，就可以根据这个测试用例，把全部功能都过一遍，有规范有依据，不会像之前那样混乱，到底哪些功能是没问题的，哪些功能是有问题的，一目了然，沟通效率也会更高。 以微信读书PC端的功能为例，图一为微信读书PC端的页面，图二为根据功能编写的测试用例，如下所示： 什么时候编写测试用例 上面提到的是在任务开发完成之后再编写测试用例，但如果在需求阶段就编写测试用例会不会有什么问题呢？ 在需求阶段就编写测试用例，这种开发模式就是常说的TDD（测试驱动开发）模式。这个方式当然是可行的，但存在一个问题，就是最终交付的功能和最初的需求可能会有出入，导致之前编写的测试用例不能用了，需要重新编写。 首先，开发人员在需求阶段就编写测试用例，相当于在对需求进行分解，同时对需求也会更加了解，能和产品明确，达成共识，避免接下来出现返工的情况。 总体而言，测试用例等同于列出需求点，后续需求有变更，也不是全部测试用例都不能用了，很大概率只是个别测试用例进行微调而已。 所以，不管是在需求阶段还是开发完功能之后再编写，在我看来都可以的。 说到底，测试用例最终还是要围绕需求来编写，从需求中提炼出的测试要点才是真实有效的。所以，**对被测对象业务的熟悉程度，也决定了能否设计出高质量的测试用例。**毕竟，各功能点之间往往都是有关联的，会隐藏很多被我们忽略掉或者是想不到的测试用例。 在项目进度会议上进行功能演示 我们发现只有在项目进度会议上进行功能演示才会发现问题。开发人员通常口头上说“已经做完了”，这很有可能是片面的，并非开发人员存心欺瞒，只是每个人对需求的理解，有可能一开始就有差异，这种差异即便功能已经开发完成，还是可能会存在。 在项目进度会议上进行功能演示，整个项目团队的人员都可以看到，并且可以随时提出问题，虽然这样会增加会议的时间，但我相信这是值得的。 这其实也就是在敏捷开发模式中提到的Sprint Review环节，简单来说，就是解决颗粒度对齐的问题（笑），能让项目团队中的相关人员，包括但不限于产品、研发、测试和需求提出方等参与验收当前开发的功能，确认是否有需求理解偏差或潜在的需求调整，能够及时反馈和沟通，有助于项目下一步的功能优化和工作安排。

之前我们计划由项目负责人每周五进行任务验收，但在开展过程中，验收其他开发同事的任务时，经常出现缺胳膊少腿的情况：比如某个任务完成了，但文档没写，或者写了又没有提交更新；某个任务计划的结束时间都超过了，也没有及时变更，至于过期的原因也没有说明等等，执行起来很困难。现在在项目进度会议上把完成的任务进行验收，就需要周一的时候，项目负责人牵头更新任务的时间、功能和文档情况，否则周二在项目进度会议上，还是会出现各种各样的问题。但是周一的时候，项目负责人已经验收过任务，周二在项目进度会议上又要过一次，对于其他开发同事来说，就觉得被问了两次，显然这个方式可能没有从根本上解决问题。 之前项目负责人去验收，实际上是不知道任务进度情况的，只有问了项目开发的同事才知道负责的任务完成了没有，项目负责人完全不知道有多少任务需要验收，完全是随机的状态，相应的其他事情的计划就又要变更了。那我们何不反过来，使用观察者模式，等开发同事完成任务后，给项目负责人发一下邮件或者企业微信的消息，一来形成闭环，二来强化开发同事任务是需要验收的这个意识。项目负责人这个时候立马去验收也可以，但不推荐，因为挨个去验收，精力就会分散，建议把可验收的任务整理记到下周一当天工作计划里，统一验收。后续等我们在线项目管理系统上线，里面就提供一个功能：如果开发同事任务完成，需提交技术文档（如有需要），然后把任务状态变更为待验收，这个时候，系统就会给项目负责人发一条可验收的邮件，相信可以有效解决这个问题。

前言 召开项目进度会议的方式应依据部门的具体情况灵活安排。尽管一些部门的职能结构通常为项目总负责人、项目负责人，再到具体项目及其成员，但在实际召开项目进度会议时，通常有以下两种设计思路：一种是项目总负责人深度参与并引导会议；另一种则是授权项目负责人自行组织会议，而项目总负责人则另设专门的项目负责人会议。 项目负责人主导型会议 项目负责人主导项目进度会议的全过程。他们负责申请会议室、准备设备、在项目群中发布通知并召集相关人员参会，项目总负责人也会参与其中。会议中，无论是项目进度汇报、问题反馈、任务验收还是后续工作安排，均由项目负责人主导提出、讨论并解决问题，项目总负责人则主要扮演补充角色，例如指出潜在问题等。这种模式能够有效增强项目负责人的责任感，使其将项目视为自己的责任。换言之，项目负责人应明确，在项目事务中，他们行使的是权力而非义务。**权力是主动争取并愿意承担的事情，而义务则是他人强加的要求，二者意义截然不同。**许多项目负责人虽然参与了许多工作，但心态上仍与项目脱节，认为项目是上级安排的任务，只是机械地执行上级指令，而未意识到自己需要对项目的各个方面负责。 分层汇报机制会议 在这种会议模式下，项目负责人负责组织项目进度会议，而项目总负责人则主导召开项目负责人会议，用于听取各项目负责人的项目整体情况汇报。这种方式通常适用于规模较大的团队，且对项目负责人和项目总负责人的能力要求较高，实施起来并非易事。

前言 为何项目会频繁出现加班的情况呢？究其根源究竟在哪里呢？从项目管理的角度出发，我认为项目负责人可能在以下几个关键环节存在不足之处，从而引发了加班现象的产生。 需求不够清晰明确 项目需求是否已经足够明确呢？例如，当我要开发设备列表这一功能时，上级给出的需求仅仅是一句“实现对设备的管理”，而没有细化到该功能的具体要求，比如页面默认应显示10条数据、需支持分页功能且分页选项为10、20、30、50和100条，还要支持按设备名称和设备ID进行搜索，列表要展示的表头包括设备名称、设备ID、设备型号等。 在需求沟通阶段，若未能明确需求的范围，就会使要做的工作存在过多不确定因素。就好比我要提一个需求，即“用一张纸剪一个圆”，如果只是简单地告诉对方“我要剪一个圈”，而对方仅凭感觉去剪，剪好后我却觉得不满意，要求剪得小一点，但又没有明确具体要多小，对方只能凭借自己的感觉不断尝试，直至剪出令我满意的结果为止。在这个过程中，对方其实一直在进行返工，这无疑就变相导致了加班的情况出现。 正确的做法应当是，在告知对方要剪一个圆时，直接将圆画在纸上，待双方沟通确认之后，对方只需剪一次即可，从而避免出现反复返工的问题。 项目缺乏充分的预研工作 在项目的预研阶段，项目负责人需要在脑海中对项目从无到有的整个过程进行全面且深入的分析，将可能出现的问题逐一梳理，并且提供相应的解决方案，而不是仅仅依据需求阶段沟通好的需求，就仓促地开始着手实施。 需求阶段的工作做到位只是基础的第一步，接下来的第二步就是要以终为始，从最终结果开始倒推，思考可能会遇到哪些问题呢？这个功能采用何种技术来实现呢？这个饼图应该使用哪个插件来制作呢？这个3D动画效果是选用哪个第三方库来实现，还是自行开发呢？天气数据又该使用哪个平台呢？客户提出的这个需求是否真的能够实现呢？类似这样的一系列问题都需要项目负责人提前想清楚，并且做到心中有数，甚至对于一些功能难点，还需要制作一个Demo来进行验证。 倘若在这一阶段没有做到位，仅根据需求评估项目的开发计划，并且向客户承诺交付的时间，那么在项目推进过程中，一旦发现存在无法解决的问题，或者某个环节比预期花费了更多时间，为了应对这种阻碍项目推进的突发状况，项目负责人往往只能被迫安排加班，否则就无法按照预期完成项目。简而言之，就是前期预研工作没有做到位，从而意外地遇到了隐藏的暗礁。 临时插入需求导致的问题 其实关于项目推进过程中出现紧急需求插入的情况，已经在《10-项目需求变更时如何处理》这篇文章中有所提及，当遇到这种情况时，应该如何妥善解决呢？这里就不再重复阐述了，只是想说明一下为何这种情况下会出现加班的情况。原因就在于项目负责人没有充分按照《10-项目需求变更时如何处理》中提到的方案去操作，而是盲目地接下来，完全不进行沟通，只要上级提出任务，就理所当然地认为上级是知晓当前项目情况的，如果自己有不同意见，可能会给上级留下不好的印象，会被认为是身为项目负责人，稍微增加一点工作量就开始抱怨。于是，就硬着头皮接受了任务，但此时已经有正在进行的工作了，新增的任务必然需要额外的人力和时间去完成，那么在这种情况下，只能安排加班，否则还能怎么办呢？最终项目没有如期达成，被上级批评，而项目负责人自己却感到非常委屈，明明项目团队天天都在加班，只是差了一点点就完成了，却还要被批评，心里十分不爽。这就是典型的吃力不讨好，没有及时与上级进行沟通。很多人总是错误地认为上级是全能全知的，上级的决策一定都是正确的，既然上级安排了临时任务，那一定是有其原因的，也一定知道我正在忙很多事情。这种想法是不可取的。类似这种情况，由于项目需求变更、临时插入紧急任务，一定要及时向上级反馈，不能等到事情搞砸了，再去找各种理由，即便理由再充分，但项目没有按照预期交付，这个结果就是工作没有做好。 关于加班的合理时机 说实话，其实我是很反对加班的。虽然我加班还挺多的，但并不是因为我加班多才反对的，主要是加班要加得有意义，加班本身不应成为目的。然而，许多人却将加班视为勤奋的象征。例如，有人会说：“我一个月加班近50个小时，这难道还不算努力吗？”我见过太多人在正常工作时间内拖沓，却把事情留到加班时间去完成，这种行为毫无意义。 加班应该是应对突发情况的手段，而不是常态。比如，当服务器突然宕机，或者线上平台的关键功能无法使用，严重影响用户体验时，这种紧急情况需要立即解决，加班是必要的。这种加班才是有意义的，因为它解决了实际问题，避免了更大的损失。 许多硬性安排的加班往往只是形式主义，大多数人只是在“摸鱼”，不会关注“今天把事情做完”的重要性，不会追求提高工作效率，只是在凑时长而已。 甚至有些人认为“我做得越快，不就是做得越多吗？”这种想法有一定道理，但关键在于如何利用时间。如果你担心完成任务太快会被认为无所事事，那么可以利用剩余时间学习新技术、阅读专业文章，提升自己，这才是更有意义的做法。