​近日，在 V2EX 社区的“分享发现”板块，爆出了一则名为《虾米 mac 客户端发现个好玩的注释》帖子。该帖一出，迅速引发了强烈讨论，相信你已经有所耳闻。

本着“阐述事情经过，不看热闹不搞事”的原则，我们一起基于事实做出总结和思考。

1. 事情经过

事情起于 V2EX 上一则名为《虾米 mac 客户端发现个好玩的注释》的帖子，帖子原址为 www.v2ex.com/t/407653?p=1，截图如下：

看到这儿，肯定有人质疑了：居然能看到如此清晰的源代码？

先别着急，在这儿给大家简单科普下：

虾米 mac 客户端是基于 Electron 框架搭建的，由于没有对 release 代码做混淆和压缩保护，所以提取出来的跟源码没有区别。

具体的查看和分析流程，感兴趣的可以自行查阅，就不再贴出来了。总之就是在 Mac 客户端上，通过查看应用包内容，找到 app.asar 文件，然后使用文本查看软件打开，就可以看到。由于官方在第一时间删除了相关注释并发版，所以现在已经看不到了。当然，这不是重点。

2. 网友看法

事实在这儿摆着了，网友们也纷纷表达了作为局外人的看法。

来自业内的网友：

作为一名码农，深知代码、文档、注释这种东西不光你的同事领导会看，在你离职的几年后都有不认识的人会看到，深表惶恐，哪敢乱写？

这其实反应了现代软件工程的一个现状——阅读并理解别人的代码是如此麻烦，以至于从中型项目开始，系统的一个模块的代码往往只有写它的那个工程师认真看过，其他人处于人人手头一摊事的状态，也没法去认真审阅，中间自然存在巨大的个人‘发挥’空间。


这代码居然能过 review ？


也有透过现象看本质的：

在此次事件中, 也有人看出了编译型语言的“优越性“, 暴露了解释型语言的不足。编译型语言需要专门的解释器进行“翻译”，普通用户无法直接查阅代码的含义。

更有类似文科生的观点：

此次事件，表明了编译型语言的优越性，暴露了解释型语言的不足。充分说明了，现阶段程序开发的主要矛盾，是日益增长的开发需求同编译型语言开发速度低下之间的矛盾。



3. 后续进展

此次事件之后吗，虾米客户端连夜过审代码，删除虾米音乐客户端中的不当用语，修复了文件混淆失效的 BUG，并及时更新了版本。

而对于大家关心的谁来背锅的问题，最终在知乎有一位程序员站出来公开道歉了，由于匿了，所以是谁也不得而知，我们也没必要知道，截个图就过了吧。


4. 个人观点

人非圣贤，孰能无过。

作为程序员的我，可能天生老实，每每看到这类事情，总会想到这句圣贤之语。

但就事论事，我们可以不做吃瓜群众，看热闹不嫌事大，但我们至少应该有自己的观点。

往小了说，是程序员小哥对待工作不严谨，在代码中加入了不当的注释。PS：话说回来，那些从不加注释的同学才更可怕...

往大了说，就可以上升到个人品行问题，公司价值观问题。

总之，工作态度问题也好，个人品行和公司价值观也罢，事情已经过去了，相应的弥补措施和道歉已经落实，我们穷追已然没有任何意义。

回过头来，作为局外人，我们是否应该有一些借鉴和思考呢？否则我们和吃群众有何两异？

  • 正如《黑客与画家》一书中所说的，“程序写出来是给人看的，附带能在机器上运行”，所以，请认真对待你写的每一行代码，每一句注释。

  • 如果有可能，请推行或配合 Code Review，能在开发阶段发现许多不规范或者显而易见的问题。假若条件不允许，也请在提交前，自行 Review 所做的修改。

  • 认真对待发版，对自己的产品负责，正如对自己的孩子一样，悉心、谨慎。试想，如果虾米的程序员做好了这一点，就不会有着一系列事件，当然，事情发生了，再小的问题，哪怕只是无须有的注释，都会酿成大祸。

  • 最后，敬畏代码，敬畏用户，对一切人、事保始终持敬畏之心。