今天，我看到了一个有意思的话题：用vim命令查看文件被甲方批评。
事情是这样的，有位网友在社交平台上吐槽了自己用vim命令查看文件的经历，结果被甲方狠狠批评了一顿。朋友说，他用vim查看了文件内容，甲方问：“你想改配置吗？”朋友回答：“不改，就看看。”结果甲方说：“那你应该用view命令打开它，而不是vim，你脑子不清醒，你要明白你在做什么，你的动机是什么。”
这个回答让朋友有点懵，毕竟用了十几年的vim，没想到还会因为这个被喷。其实，我也是个vim用户，还是个深度用户。90%以上的开发工作都在vim里完成，现阶段我用的是neovim加lunarvim的组合。要说甲方批评得有没有道理，我举两个例子说明一下最近发生的事儿。第一个例子，某人用vim打开了某个文件，结果忘了关。未知原因，导致CPU飙到100%，引发了一连串的告警。第二个例子，我编辑了.bashrc文件，不小心多按了一个p，结果粘贴了一行其他内容。虽然ssh正常使用，但sftp却因此无法使用。这两个例子都说明了一个问题：线上查看配置时，用view、cat、more、less这些命令要比vim来得安全。你以为别人是小题大做，指不定之前就有人因为vim造成了生产事故呢。有网友表示，vim看大文件确实有问题，这点没得争辩。我自己以前也用vim看大文件，结果导致内存报警。理论上确实是这样，view是vim的只读模式，防止了意外修改文件的风险。对于大文件而言，view更是一个安全的选择，避免了不必要的资源消耗。从技术和团队规范的角度来看，确实应该用view命令而不是vim命令来查看文件。以下是具体原因和改进建议：技术原因
- 只读模式：view命令是以只读模式打开文件的，不会意外进入编辑模式，因此更安全。
- 避免误解：使用vim打开文件，即使不修改，也可能让其他人误以为你在修改文件，这会引起不必要的担忧和误解。
- 文件锁定：某些系统或环境中，使用vim可能会对文件产生锁定，阻碍其他人对该文件的访问或修改。
团队规范
- 遵循规范：如果团队或项目有明确规定，查看文件应使用view而不是vim，那么应当遵循这一规范。这有助于保持团队一致性和减少潜在问题。
- 减少风险：在多人协作环境中，使用只读命令可以减少意外修改文件的风险，保障文件的完整性。
改进建议
- 熟悉工具：尽管习惯使用vim，建议花些时间熟悉view命令及其相关操作，确保能够灵活使用。
- 自动化脚本：如果频繁需要查看文件，可以编写一个脚本，在需要只读查看时自动调用view，这样可以简化操作并减少错误。
- 沟通与反馈：如果认为某些规范不合理或不便，可以与团队进行沟通，提出改进建议，同时尊重和遵循团队决定。
# 个人看法
我认为在工作中选择合适的工具不仅是对自己工作的负责，更是对团队的负责。以下是我对如何应对这种情况的一些具体看法和建议：举个例子，我曾经在一次生产环境的故障排查中，用vim打开了一个配置文件。当时只是想快速查看一下配置内容，结果手一抖，不小心多按了几个键，差点修改了文件。虽然立即撤销了操作，但仍然惊出一身冷汗。从那以后，我严格遵循只读查看文件的规范，使用view、cat、more和less这些命令，确保不会因为一时疏忽导致意外修改文件。在团队协作中，制定明确的工具使用规范是非常重要的。例如，我们团队现在明确规定，任何线上环境的配置文件查看都必须使用view命令，禁止使用vim。这个规定不仅仅是为了避免误操作，更是为了减少误解和沟通成本。如果团队中的某些规范确实不够合理，或者在实际操作中存在不便，可以通过沟通和反馈来改进。例如，我们团队曾经在工具使用上有一些争议，有人觉得view命令不方便，想用vim。经过讨论，我们决定在使用view的基础上，编写一些辅助脚本，简化操作。比如，可以用一个简单的脚本，根据文件类型自动选择合适的查看命令，这样既保证了安全性，又提高了效率。无论是使用vim还是view，养成良好的操作习惯都是关键。比如，在查看文件之前，先确认自己是否有修改的需求；在使用vim时，尽量避免不必要的键盘操作；在使用view时，熟悉基本的导航命令，确保能够快速找到所需信息。这些习惯的培养，都是为了在日常工作中减少错误，提高工作效率。总之，我们在工作中要一定要严谨，特别是在处理生产环境的配置文件时，要选择更为安全的命令。虚心接受批评，反思并改进自己的工作方式，这才是一个成熟的职业人的表现。最后，我们整理各类常用的编程软件及相关使用手册，放在了网站上，感兴趣的同学可以去看一下：https://www.j301.cn/dev.html那么，你平时打开大文件用vim还是用view？欢迎评论区留言讨论。发送关键字「 java 」，领取Java架构师资料合集热门推荐