Posts

一个十年的 Vimmer 说在 AI 时代，Vim 的优势正在被 tab 替换掉，加上 Vim 创始人离世，对 Vim 的前景充满忧虑，考虑放弃 Vim 使用现代代码编辑器+鼠标。 我觉得选择没有对错，只有适合不适合，当下的他认为编辑器+鼠标更适合他，那这个选择对他来说就是最好的选择。 我接触 Vim 时间不长，借此机会，我想谈谈我为什么选择 Vim，我认为 Vim 的优势不在于它快，而是一整套不被打断的工作流。鼠标操作它简单高效，它降低了个人电脑的使用门槛，我觉得个人计算机的普及除了图形化界面，另一个重要的因素就是鼠标的加入。它一定程度上带来了技术平权，让计算机不至于仅仅是极客群体才能使用的工具。 程序员是一个比较特殊的群体，当他开始把头脑里设计好的方案实现时，会有很长的时间对着代码编辑器进行比较重度的输入。这期间可能会设计打开文件或者 git commit 正在实现方案中某个最小实现的 feature，此时就需要使用鼠标进行操作，一般我们在 coding 的时候，速度是相当快的，而鼠标操作相对于键盘输入是要慢一点的，我们不得不从高速输入的状态中减速，使用鼠标去完成对应的操作。 由于鼠标一般离键盘都会有一段距离，这取决于你键盘的配列，配列越大，手移动的距离就会越大。这种物理距离的存在，即便你能很高效的切换，也多少会显得有些手忙脚乱。 这种中断，对我来说不太好，为了避免这样的中断, 我开始关注 vim, 好在 lazyvim 很大程度上降低了入门门槛，在一个 YouTuber 视频的指引下，我开始进入了 lazyvim 的世界。 目前我使用下来整体感觉还是比较好的，没有什么特别明显的不适，加上 lazyvim 可以通过 Lua 编写脚本，这使 lazyvim 有了更高的可定制性，我用 Lua 写了一个代码片段的脚本，整体效果良好，同样的事情我曾经想在 VS Code 里也想做过，由于 VS Code 对代码片段限制有点大，导致我没有实现。 我也不确定 lazyvim 是不是上述状态切换的正确答案，但是它是我目前找到的比较好的答案，如果未来有其他更好的方案，我很乐意去尝试。 我看过一个 YouTuber 使用 Macbook 键盘+ touchpad 来操作，看上去感觉要比鼠标更好一些，因为它移动距离足够小，且 touchpad 的操作效率，某些场景下确实比纯键盘操作更高。 其实说到底无论什么编辑器，最终它都是一个工具，只要使用顺手就可以，无须过多纠结，当你需求产生了，你自己自然就会知道自己需要什么样的代码编辑器。

到目前为止，我也买了不少机械键盘，有早年非常火的菲尔可的圣手二代，也有近几年挺火的 RAINY75 ，但我始终没有找到自己心仪的键盘。 但是在这么多年的摸索过程中，我对键盘需求却越来越明确，我对小键盘依赖不大，键盘上方的数字键就已经很好的满足了我的需求，其次是我希望键盘满足我需求的情况下要尽可能的小（太大的键盘会给我一种笨重感），现阶段 75% 配列的键盘对我来说是非常合适的。 我希望它要是矮轴，能够让我在长时间打字的时候减少因为键程过长而带来手部的不适。矮轴对于高速的打字来讲也要比高轴更加的流畅，如果你对我说的这种感觉不太清楚可以找个笔记本的键盘和高轴键盘用你最快的速度打出同样的字（笔记本键盘别太差），你就能感受出两者的不同。 NuPhy Air75 V2 出现在我的视野中, 我看到它的第一眼我觉得，它是我想要的键盘了。 它尺寸小，重量轻，能够很好的满足便携性需求，外观设计也非常的不错，让你在第一眼看上去就有一种非常惊艳的感觉。稻盛和夫的书里面有这样一段关于产品的描述 要打造出划破手的产品 好的产品应该像一把精心打磨的刀，刀刃如此锋利，以至于轻轻触碰就能感受到其品质——这代表对细节和完美的极致追求。 当我看到 NuPhy Air75 V2 书中的描述仿佛在此刻具象化了，它的整体设计，让我看到了背后团队的努力和认真。也让我对背后的团队产生了兴趣，后来我在他们官网找到了他们的一个 slogan NuPhy® Studio 是⼀群⽆聊的家伙创⽴的⼩公司，等到我们⽆法制造出有趣产品的那⼀天，这个⼯作室将不再存在。 我从 NuPhy Air75 V2 确实感受到了他们的热情，他们成功的通过产品表达了他们的理念。我认为倾尽热情做出一款让人认可的产品是一件非常幸福的事。 说回键盘本身，除了尺寸，重量和外观满足我的需求外，按键的使用感受也是非常出色的，我选的是青轴，它段落感清晰，回弹力度干脆，高速打字时不会有绊手的感觉，虽说是青轴，它的声音没有那么的大，快速打字的时候有点像鼠标点击的声音。它让你码字时感到非常舒适，买来后我使用了一月有余，这是一款我找不出缺点的产品。 关于矮轴的选轴建议，线性轴和段落轴看个人喜好选择即可，轴体的触发力度建议选大一些的，这样反馈会比较清晰，也能减少误触。 NuPhy Air75 V2 已经牢牢的把我圈粉了，不过在这里也给大家提醒一下，本文纯属主观的使用感受和体验，正所谓萝卜白菜各有所爱， NuPhy Air75 V2 能够很好的满足我的需求，但未必适合你。 如果你还没有找到一个适合自己的键盘，我建议你还是得首先明确自己的需求，知道了自己的需求，才能少走弯路，更快的找到适合自己的产品。 如果你对 NuPhy 也感兴趣，可以去关注一下他们家的产品。最好能够想办法试用一下，节省钱袋子😄。最后希望大家都能找到自己喜欢的键盘。

如果你用 GitLab 来做项目管理，我非常建议你了解一下 GitLab 的 CI/CD 的功能，它可以自动帮你完成项目的打包、部署、上线。 免去了上线过程中的复杂操作，对于标准化流程机器向来比人做的好。也能减少很多不必要的 Human Error 。 本文以 Python 项目部署为例，讲一下 CI/CD 中的一些部署思路，给你一个引子，引出你对 CI/CD 更多的探索。 概括来讲，CI/CD 包含两个关键步骤：配置和执行，只要你的项目根目录里有 .gitlab-ci.yml 配置文件，GitLab 就会读取，然后按照配置去执行计划。 配置： 是通过 GitLab CI 配置文件 (.gitlab-ci.yml )来告诉，执行者（Runner）要做哪些事情 执行： 执行的动作是由 Runner 来做的, Runner 是一个可执行程序，可以在任意一台服务器上。项目可以配置一个或多个 Runner。 关于配置 以下是 .gitlab-ci.yml 的一个模板，可以复制到你项目中改改就可以完成你项目的自动部署功能。 stages: # 定义步骤 - deploy deploy_test: # job 名称 image: instrumentisto/rsync-ssh:latest # 指定 docker 镜像 stage: deploy # 所属的步骤 script: # 执行的脚本 - mkdir -p ~/.ssh - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config - echo "$TEST_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # 将 GitLab 里设置的的私钥环境变量输出到 ～/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh -p 22 -i ~/.ssh/id_rsa root@"$TEST_SERVER" "cd $TEST_PROJECT_PATH && git pull && source .venv/bin/activate && pip install -r requirements.txt && python test.py " retry: 2 # 如果任务执行失败，会进行 2 次的重试 only: refs: - test # 仅当代码被推送到 test 分支时才会触发该步骤 deploy_prod: image: instrumentisto/rsync-ssh:latest # 指定镜像 stage: deploy script: - mkdir -p ~/.ssh - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config - echo "$PROD_SSH_PRIVATE_KEY" >> ~/.ssh/id_rsa # 将 GitLab 里设置的的私钥环境变量输出到 ～/.ssh/id_rsa - chmod 600 ~/.ssh/id_rsa - ssh -p 22 -i ~/.ssh/id_rsa root@"$PROD_SERVER" "cd $PROD_PROJECT_PATH && git pull && source .venv/bin/activate && pip install -r requirements.txt && supervisorctl restart server" retry: 2 only: refs: - master 配置文件包含 stages 和 Job 两个概念。stages 根据项目上线一共有多少个环节来定义，如你可以能有「构建」（build）->「测试」(test)->「部署」(deploy)。我这里为了演示方便只配置了一个 deploy, stage 名称可以随意取，但是尽可能的语义化一些，这样在仓库看日志会比较清晰。 ...

一直以来，我都感觉传统编辑器鼠标和键盘的频繁切换的体验让我无法接受，它让编程这件事情拆分成了两个系统：输入和移动。我一直有将他们统一的冲动，但又受限于 vim 学习成本过高的固有认知一直没有行动。它像一根若有若无的刺一直刺痛着我，直到有一天我接触到了 lazyvim，我想也许是时候改变了。 lazyvim 可以极大程度降低了配置难度，可以在不进行任何配置的情况下拥有一个轻量级的代码编辑器。 我切换 Neovim 除了 lazyvim 降低了配置成本还有另一个原因：我认为自己还会有相当长的时间开发相关的活动，一个高度可定制的编辑器，可以让我随心所欲的打造一个称手的工具。 关于配置我使用的是 https://github.com/craftzdog/dotfiles-public 并在此基础上扩充了 PHP 开发相关的配置。在文章底部我会贴出自己的 dotfile 仓库，目前我的配置可以用于 VUE、PHP、GO 的开发，如果需要可以自取。 在开发之前我们还是需要对 Neovim 基础操作有一定的了解，这里介绍一下我的学习方式。 我是通过 https://lazyvim-ambitious-devs.phillips.codes/ 一书建立的最初的基本只是，后续又看了一些视频加深我对 Neovim 的理解。 在视频学习的过程中，可以很好的学习资深的 vimer 是如何进行 vim 操作的，拿来主义可以省去很多自己探索的精力。最开始只需要模仿就可以了，等你对 vim 使用熟练后你会有自己的想法，那时自然而然的会形成自己独有的操作方式。 视频的学习我参考了 craftzdog 比较多，在 B 站上也学习了其他人的一些操作技巧。 Neovim 的学习成本也没有想象中那个高，正常下来，一周你就可以比较得心应手的进行开 发了。 得益于 LSP 的技术，让 Neovim 对开发语言的支持和 Vs code 并没什么本质的差别。 Vs code 对语言的支持也是通过 LSP 来实现的。 Neovim 带来了什么？它确实能使我整个开发的工作流完全脱离了鼠标，所有开发的工作包括但不限于代码编写、函数跳转、以及 git 的提交等全部都可以脱离鼠标完成，双手不需要离开键盘区域就可以完成编程所需要的操作。 此外像文件操作：打开、删除、重命名等操作，Neovim 也可以很方便的操作。它确实让我更专注了，所有的操作都没有任何的打断，我不需要频繁的把手离开键盘做一些额外的鼠标操作。 上文说到，Neovim 可定制化程度更更高，理论上你能按照你的习惯去配置 Neovim 来使它与你配合的更默契。 Neovim 会不会对开发效率带来一定的提升？从我目前的使用程度来看，它并不能带来明显的开发效率的提升，Neovim 在一些操作上的确更有优势，但是也有一些操作没有 GUI 更加的高效。总的看来我觉得它的开发效率和 Vs code 差不多。 ...

在多年的开发经历中，我发现不重视编程规范是普遍存在的一个问题。很多开发人员对规范的态度都是很抵触的，认为规范的条条框框是枷锁，会降低开发效率。 不仅仅是普通员工，很多公司的管理人员对于规范的重视程度也是不够的，甚至就没有制定规范的想法。 为什么会出现这种现象呢，我想每个人都会有自己的角度，大多数原因可能是因为项目周期紧张，没有时间制定规范，或是单纯的认为规范会影响开发效率。 上面的原因是客观存在的，所以大家对于不制定规范也没有太大的心智负担。今天我想就这个现象谈谈我对规范的认识。 规范一般有两种，一种是项目规范一种是编程规范。 关于项目规范 我在刚开始入行的时候，公司虽然也没有自己的规范，但是带我的前辈，给了我一份谷歌的开发规范，让我学习，代码的书写格式是怎么样的，什么时候应该换行，应该怎么避免写嵌套 if… 这让我对代码规范有了一个最基本的认识。 代码需要书写的简洁，易读。代码规范有点像写文章时的字体工整程度，越遵守代码规范，字体就越工整。你可以想象就算同样的一篇文章，字体工整和字体潦草给阅读人的感受是完全不同的。 后来我在一家公司做管理，刚到公司时也没有自己的规范，每个人的代码风格，变量命名，项目组织的习惯各有不同，导致项目的风格多样，这给我们带来了一些问题。 维护成本高 当我们维护其他同事写的代码的话，需要从头开始阅读一遍代码，才能了解问题具体出在哪。如果我们有规范就不需要通读所有代码，仅需依据规范出问题代码的大体位置。 代码复用差 当我们有一些通用业务需要封装时，如果没有规范，就需要考虑所有的代码风格，甚至要做一些额外的兼容才能把组件封装完成，有了规范我们完全就可以避免这类问题。 项目对接慢 由于没有规范，每次公司来了新同事，我们并没有很完善的文档给到他。导致新同事上手项目比较困难，中间还要不断地去询问老同事，才能对代码有一个相对比较完善的理解。 这无疑增加了很多的摩擦成本，且团队越大，这种摩擦成本就会越高。就像我们都说中文，又各自有自己的方言，大家需要了解每个人的方言体系，才能更好的深入交流。 我们需要“普通话”这样一个统一的说话规范，来降低我们团队内部的摩擦成本。 建立规范 为了解决上述问题，我们结合自身团队的特点，参考了他人的规范制定出了我们自己规范的初版。 初版规范经过内部评审和修改后，我们形成了自己的规范文档。 后续我们在实践的过程中遇到了一些规范上的不足，也进一步对规范做了补充，使规范在原有的基础上不断的迭代和优化。 这样一套规范建立后，使我们每一步都是在之前的基础之上，而不是每一次都是从 0 开始。这让我们可以不断的阶梯向上。 如何让规范落地 规范的制定后就需要考虑规范落地问题，如何让团队更好的遵守规范。 首先需要让团队认识到规范对我们团队合作是有益的。做好心理建设，消除心理的抵制情绪。 把规范塑造成开发文档，让团队养成经常查阅的习惯，对规范有疑惑就去规范文档找答案。 利用工具降低规范的执行难度，像一些代码风格的问题可以通过 IDE 代码格式化解决，不用团队开发者额外注意。 使用静态代码分析工具检测代码是否符合规范，如果使用 CI/CD 可以把这一步集成到 CI/CD 中，让不符合规范的代码，无法提交到线上环境。 关于编程规范 编程规范包括：设计模式，设计原则，编程范式，最佳实践等等。这类规范一般是行业发展多年，一些经验丰富的前辈总结的一些开发工作的规范。 因为这类规范通常是前辈们在长期实践中总结出来的。遵守这类规范能让我们更容易开发出稳定的程序，少走弯路。 这类规范一般都具有普遍性，对语言没有任何的限制，因此一旦你熟练的掌握，你用任何语言开发的程序都会有更好的稳定性，更少 Bug 、更容易维护和扩展。 我发现有些同学会遇到一些奇奇怪怪的问题，或者一段时间后，程序出现了运行瓶颈。有不少是因为没有遵守某些编程规范引发的问题。 有时他们不遵守编程规范，并非不愿意，而是因为他们不了解某些规范。因此对于编程规范，要像探寻宝藏一般，时常去探索一下。不断地完善和补充自己对编程规范的理解。 总结 规范短期看可能会觉得有点浪费时间，影响开发效率，从长期看，却未必如此，那些减少的 Bug, 复用的代码，以及与同事之间协作效率的提升，足以弥补开发时的损耗。 牛顿说：我之所以比现别人看的远，是因为我站在巨人的肩上。 运用前人的智慧和经验，能让我们做事情更加的顺利。要站在前人的肩膀上，哪怕你觉得这个人不够高，也比自己站在平地上看的更远。