bigbigbo
bigbigbo
### Describe the bug 我尝试给内置的 `button-remove` tool 增加一个 `title` 提示，所以我使用到了 `args.markup`，并设置如下: ```js { markup: [ { tagName: 'title', textContent: '删除', }, { tagName: 'circle', attrs: { r: 7, fill: '#FF1D00',...
尝试了下类似配置貌似不行： ```json "editor.codeActionsOnSave": { "source.fixAll.mdlint": true }, "[markdown]": { "editor.formatOnSave": true, "editor.defaultFormatter": "ZhixiangZhang.mdlint" }, ``` 请问在哪里设置呢？
问题：在提取的过程中发现诸如"【】"，"中文逗号，"，" 接中文的"也一并被提取出来了，导致了一些问题。     期望：能否配置部分文本不进行提取？
### 问题描述 想通过缩放和平移居中显示画布内容，调用 `centerContent ` api 达不到期望的效果 ### 重现链接 https://codesandbox.io/s/wild-currying-3dpio1?file=/src/App.js ### 重现步骤 1. 通过 flex: 1 和 height: 100vh 设置画布大小 2. 设置 graph 的 autoResize 为 true 3. 从截图1可以看出demo中画布的大小是正确的，但实际居中效果不理想，截图2是在实际项目中的效果，更不理想 ...
又是一个炎热的夏日午后，我坐在电脑前，手指在键盘上飞舞，仿佛一位才子挥毫泼墨，却无法掩饰我内心的不安和激动。是的，这是我作为一名前端工程师，度过的一年的中间节点。 在这奇幻漂流的前端世界里，我用HTML、CSS和JavaScript编织了无数绚丽的梦境。有时，我像着迷于沙滩上的美丽贝壳一样，沉醉在编码的海洋中，忘却了时间和空间。而有时，我又如同在茫茫荒野中徒步，迷失于各种浏览器的兼容性问题，感叹人生的艰难险阻。 在这半年的奇幻漂流中，我参与了许多项目，与优秀的团队伙伴们一起，征战着前端的不归路。我们攻城拔寨，将设计师的幻想变成了网页的现实。在这过程中，我深刻领悟到团队的力量是无穷的，只要我们同心协力，就能创造出不可思议的事物。 当然，前端世界也并非一帆风顺。有时，我像一位调皮捣蛋的顽童，纠结于代码的细枝末节，陷入了所谓的“回调地狱”中，心生挫折。但是，正是这些坎坷，磨炼了我前进的步伐，让我更加勇敢面对未知的挑战。 技术世界犹如一座迷宫，越深入，越能感受到其中的奥妙。我从jQuery到Vue.js，再到React，一步步地探索前端框架的玄妙之处。在这个迷宫里，我时而觉得自己是个无知的新手，时而又有一种潇洒自如的豁达感。 然而，技术的迷幻并不是全部，团队合作也是前端世界的一大特色。我常常与小伙伴们一起开黑，啊不，是开会。我们讨论问题，争论观点，发出无数的哈哈和哇哦。虽然有时候火花四溅，但我发现，正是这样的碰撞，让我们在思想的交流中共同成长。 回望这半年的奇幻漂流，我为自己曾经的执着而喝彩，也为未来的前端之旅而充满期待。我将继续沉浸在代码的海洋中，追寻技术的风向，不断探索前端的边界。 愿这奇幻漂流的前端世界，继续给我带来无尽的惊喜与挑战。让我们一同驾驭键盘，航向未知的彼岸！ > 以上。第一次尝试借助 AI 写作完成了一次年中总结。
2022是壬寅年虎年，闽南地区宗教氛围比较浓厚，家里老人总说虎年有很多事情要避开，婚嫁、生育、事业皆有涉及。作为年青一代的我，虽没有光荣入党但也是个无神论者，也从来没有在意过这些，但说来也怪迷信，今年虽才过半年，但总是“累”在心头，不知是否是“负虎前行”。 之所以感到“累”，一来今年前端小组照旧是辞旧迎新，人员存在变动，补充上的人员又需要一定的过渡期，短期内人力出现不足的情况。二来今年工作任务比往年艰巨许多。 年初的运营中心项目，我承担了最核心的功能开发，业务复杂度高且相当一部分功能是先实现再设计，在实践中摸索合理的产品设计，因逆反了开发顺序，做起来难免返工。 运营中心刚提测不久，我又马上投入了知识中心的开发任务中，知识中心是我们部门产品中第一个以图编辑为核心需求的产品，我此前在这方面的经验也只能说是聊胜于无，显而易见，这也是个硬骨头。 紧接着的是评估中心，又是一个图编辑为核心功能的产品，今年的产品立项对我们前端组提出了不小的挑战。 和评估中心并行的是一业一证项目，一个持续了两个月的敏捷开发的项目，也是在部门工作以来加班最久的一个项目，可能疏于锻炼，那段时间还真是瘦了几斤。 虽然“累”，但没有被“累倒”。运营中心顺利提测并且整体产品的完成度比以往的产品高上不少，同时集团验收也不存在很多缺陷修复，这是以往所没有的。知识中心虽是硬骨头，但是最终还是啃下来了。评估中心前期拖延了一些进度，最后也在大家的努力下赶了上来。而一业一证项目，更是协同了几乎所有的前端开发人力，也第一次尝试远程同远在广州的同事合作开发项目。综上，“累”有所值。 在这半年的工作任务中，也总结了一些新的经验，在自己如何成为一名合格的管理者以及如何帮助小组成员成长的经验。 我目前的角色是管理者+执行者，大部分时间，执行者的时间多一些，重点核心需求、复杂需求，我仍是主力开发，对我来说虽也是一种锻炼，磨练自己技能，但另一方面，其他几位小组成员可能会更依赖于我去兜底，他们也缺少了越过高山，拨云见日的锻炼机会。如何在不拖延项目进度的情况下，又慢慢放手让小组成员承担一些复杂需求的挑战这成为了我的难题。评估中心直接放手导致项目进度拖延2个月，后面尝试着做了一些设计评审的工作，帮助小组成员抽丝剥茧，最后大家共同努力，把丢下来的进度补了回来。这样的方式他们也十分喜欢，未来可以尝试更多帮助他们成长的方式。 他们成长起来了，我能更专注前端基建方面以及管理的工作，专注如何提升同事们的前端开发效率以及让更多的同事能快捷的参与到前端开发，这是我接下来的一个工作思路和方向。
# [译]为什么我们要进行代码审查？ > 原文：https://sophiebits.com/2018/12/25/why-review-code.html > 备注：自个儿翻译的，翻译如有错误，欢迎指出~ 最近有个朋友问我，为什么 code review（代码审查） 很有必要并且很有价值？至少硅谷的大部分技术公司至少会有两个人会对每一处的修改进行审查。在我的上一份工作中，我们只在一段时间里对一小部分的代码进行审查，直到有一位来自 Google 的新员工加入了我们，他鼓励我们对所有的代码做审查。我们听从了他的建议，emmm，这真是一个 great 的决定。 如果代码走查的方式正确，它就不会成为你的一种负担。你和你的代码审查者之间不是对手的关系，你们之间应该是一起努力共同构建最棒的软件工程的关系。（最重要的是不要带有情绪去看待给你的反馈，即使你的代码需要更改，但那并不意味着你的代码很糟糕。获得反馈是正常的，它会帮助你成长！） 有些公司对每一段代码必须有多少人审查有着严格的规则，并且严格执行每一段代码都要有负责人。我觉得这没必要，我更喜欢一个简单的系统，唯一的规则就是每段代码都必须有人审查就够了。在实操过程中，我觉得你应该对你的代码进行说明并且抄送给审查者，虽然这并没有硬性规定。 以下几点是我认为为啥代码审查具有价值的几点原因： 1. **代码本身**。代码审查最直观的价值通常是“捕获错误”。或者是有更好的最佳实践或者是一些作者不知道的写法，审查人可以通过此帮助代码的人提高作者的 coding 能力。 2. **宏观层面的知识分享**。当你做代码审查时，你可以从代码本身学习一些新的技术，可能对你之后有帮助。反之亦然，如果有人建议你的代码有更好的写法，你也可以学习到新的知识。你在这过程中积累了知识，相信它会帮助你成为一名更好的工程师的。 3. **微观层面的知识分享**。通过增加熟悉代码的人减轻“面向工位编程”带来的问题（有的人的代码由于各种原因，只有他能维护）。 4. **确认方向**。代码审查会强迫你跟你的队友沟通你正在做的事，这不会让你在接下来的几天或者几周时间里走错方向。 > 译者注：这个方向更多的是你构造代码的整体思路。 5....