大家好，我是校長。

前幾天，看到這么一個問題，感覺很有意思。

看到這個問題，讓我想起來了一個案例。

案例當中的做法不是刪除注釋，而是更改了所有項目的注釋。

案例故事是這樣的：

近日，一位叫托馬斯的讀者向大家分享了一則發(fā)生在 1970 年代的故事：一個前同事離職前一頓騷操作、導致他莫名被 “坑” 的故事。

在上個世紀 70 年代，各種繁雜的工具庫還未出現(xiàn)，程序員需要遵守的開發(fā)思路很簡單：優(yōu)化，提高資源利用率。當時的托馬斯還是一名初出茅廬的程序員，有幸被招聘進了一家咨詢公司，接手一位前同事的工作 —— 托馬斯對這位前同事的形容是：一個非常聰明也十分討厭的 “混蛋”（以下簡稱這位前同事為 “HD”）。

平心而論，在托馬斯看來 HD 被公司辭退其實有些 “冤”：

公司經(jīng)理們對項目難度缺乏正確認知，給 HD 設(shè)定了一個根本無法實現(xiàn)的最后期限。但 HD 還是堅持下來了，甚至為了完成項目代碼，他每周工作時長在 100 小時以上。然而，公司管理層因其產(chǎn)生的加班費感到不滿，并由此拒絕了 HD 的加班申請。結(jié)果可想而知：HD 與公司管理層產(chǎn)生了巨大分歧，大吵一架后，公司決定解雇 HD。

但問題在于，公司還給了 HD 一個月時間，要求他完成當前項目的代碼再走?？稍噯枺涸谶@種辭退理由下，HD 會心甘情愿、老老實實做完這一個月嗎？答案是否定的，HD 果然做了一些 “小動作”：他更改了代碼中的所有注釋。

乍聽之下這好像這不是什么大問題，可你要知道，這個舉動發(fā)生在 1970 年代：在那個年代，高級編程語言還未興起，

公司所有項目代碼均由匯編語言編寫，而不是沒有原因的 —— 在托馬斯看來，如果沒有深入研究過，匯編語言的晦澀難懂無異于機器語言。這也就是托馬斯認為 HD “非常聰明也十分討厭” 的原因：項目代碼本身沒問題，運行情況也良好，可對于下一個接手項目的人來說，早已與實際功能不符的代碼注釋就是 “地雷”。后來，這顆 “雷” 不幸地誤傷到了倒霉的托馬斯：“我接手了 HD 的項目，第一個任務是在 HD 的代碼中添加更多功能。

結(jié)果當然失敗了，因為我查看了代碼注釋。” 盡管將問題匯報至管理層，托馬斯卻并未獲得有效回應，而他擔心他也會被因此辭退，又接連進行了幾次檢查，最終得出結(jié)論：

代碼注釋果然是在胡說八道。可惜，就算明白了問題所在，當時整個公司也沒人能弄清楚代碼的哪些部分做了什么，所以最后只能刪除所有注釋，再將其黑盒化。

據(jù)托馬斯表示，一年之后他就離開了這個項目，但黑盒代碼此后還運行了五年，直到一家新的咨詢公司接管了它：“即使如今，這些代碼可能仍在某個地方運行，畢竟黑盒代碼像蟑螂一般頑強?！?/p>

到這里故事基本上結(jié)束了。

看到了嗎？這個故事是發(fā)生在 1970 年，當時對注釋動了手腳，是沒問題的，也不會被發(fā)現(xiàn)，即使被發(fā)現(xiàn)也沒用。

因為根據(jù)當時的條件，有兩個因素導致對代碼注釋動手腳是成立的：

1、沒有代碼管理工具；

2、當時的代碼是匯編，屬于低級編程語言，晦澀難懂。

沒有代碼管理工具，公司就無法證明同事 HD 對代碼動了手腳；低級編程語言晦澀難懂，對注釋動了手腳之后，很難理解，恢復并搞懂很難，所以，只能將其黑盒化了。

但是，現(xiàn)在則不同了，隨機技術(shù)的發(fā)展。對代碼注釋動手腳的兩個因素都被破除了。

1、我們現(xiàn)在擁有了代碼管理工具，你對注釋動了手腳，也可以會滾，而且很容易查到你是故意為之的，這時候，對注釋動手腳也屬于破壞代碼的一部分，雖然系統(tǒng)能夠正常運行，但是，還是破壞了代碼，公司要告你，也極有可能成立。

2、假設(shè)你對注釋動了手腳，刪除了注釋，甚至混淆了注釋，但是，現(xiàn)在大多數(shù)編程語言都是高級語言，搞懂比較容易，雖然可能會費點時間，但是，恢復起來并不是想象中的那么難。

綜合下來，我想說：程序員離職刪光代碼注釋是否違法，我不知道，但是，毫無意義，有點掩耳盜鈴的意思。