因試用期遭勸退，一男子為發泄情緒刪光自己在職期間所寫系統代碼被判刑十個月，如何看待這一審判結果?
通過刪庫來發泄情緒的程序員是最蠢的。
聰明的程序員會寫一堆只有自己看得懂的屎山，并且伴隨著偶發且不可復現的重大bug。
一旦離職，屎山將變得不可維護。
然后你不但不需要自己刪庫，老板還需要花額外的錢請其他程序員來刪掉你的代碼。
屎山包括但不限于以下行為：
使用大量while語句和條件判斷，并在之間加塞大量自定義函數和實例化以及遞歸結構。并把函數暴露在其他人可以靈活修改的位置，只要一個參數變化就會導致函數返回出錯，卡死在while循環。而debug通常需要幾千個循環之后才能發現，極大的延緩了bug被修復的時間。
函數套函數形成千層夾心，讓思路亂做一團，很難理順思考。
繼承套繼承，亂用面相對象，當接盤俠看懂了這個類，卻發現這個子類繼承了多個父類，還有接口沖突。而當他們想看看父類的時候，卻看到這幾個父類又繼承了幾個父類。
DFS搜索了一遍父類，想找到某個方法和屬性。方法父類和祖父類都被架空了，于是找到了曾祖父類，結果發現這個方法包了一個buildin type的buildin 方法，且只有一行return。屬性父類和祖父類都沒有定義，結果找到了曾曾曾祖父類，終于發現了，這個屬性的值是null。
靈活修改內置函數，類，屬性，原本想用內置功能，卻發現要用了一個帶bug的自定義內容，后續的代碼還有大量功能是基于這個披著內置函數的名字的自定義bug運行的。
隨意起名，并和全局變量保持一致，不經意間就修改了全局變量。
catch所有的exception，讓bug被巧妙隱藏。
使用復雜多線程多進程服務，并伴隨著隨機函數和等待時間，讓bug很難出現。
大量使用外部api請求，并寫死提取方法，一旦對方api修改，立刻出bug。
在數據庫交互函數上靈活實現，讓使用者可以傳入任何值，修改數據庫的任何內容，甚至只要傳錯一個參數就可以刪掉數據。
一定不要寫，單元測試，也不要寫document，把你的所有的時間用在老板能看得到的功能實現上，而且一定要用最復雜，最fancy的實現方式。面對老板不切實際的需求來者不拒，只要讓老板在看到功能時候保持運行狀態即可。
實現的論文一定要用最冷門的巨巨技術，冷門意味著沒幾個人會甚至連業內人員都沒學過，巨巨意味著難難到只有苦心鉆研黑科技的你才能把抄來的代碼勉強跑起來。
一定要拉上業界最頂級的框架，絕不按照項目自定義內容，如果一個頂級框架不能完成就再加塞一個頂級框架，每個框架只用一點點內容，以此來顯示你超強的學習能力和業務素質。這樣如果有人要接手，他們需要把這些框架全部學一遍。
并且經常使用那些不穩定但勉強能用的新版功能，無視大量warning，如果有就隱藏掉。舊版功能通常難以被新版支持，所以這些框架的版本在你引入項目的瞬間就被定死了。
然后為了保險起見你不要升級框架，一定要用最老的框架，這樣一個畢業生誤以為學會了框架內容結果卻發現自己學的框架太新了，還得把舊版本的內容學一遍。
經常使用開源bug書寫程序，這樣一旦開源庫修復bug，你的代碼就需要重寫。
如果寫http請求，請一定把最危險的功能設置成get方法，這樣只要在聊天時對方點誤點了連接，瀏覽器就會自動把危險的請求傳給后端，然后造成大量業務崩潰。但這不是你的錯，是他們不應該在聊天和郵件里亂點鏈接！
一旦你離職，你所寫的所有代碼和同事的代碼都會隨著開源版本更新，新功能增加，外部api變化，新同事不小心傳錯參數，以及點錯超鏈接造成大業務壞死。
讓fancy的地方盡可能簡陋，讓簡陋的地方盡可能fancy。就能在滿足其要求的情況下，引入大量bug和feature的混合物，讓改動變得左右為難。
這就讓接手的程序員陷入如下困境：
刪除代碼重構，工作量太大
不刪代碼，看不懂源碼
清理bug，功能變得不可用
不清bug，之后會引發嚴重問題
維護代碼，只能用新bug掩蓋舊bug
不維護代碼，隨著技術升級，舊代碼會一點點變成bug
當你已經掌握這些技巧，并付諸實踐，想必公司一定得讓你晉升主管。
為了清理這些垃圾需要耗費成倍于你的人月方可完成刪除，然后為了實現你的功能他們又需要額外的人月
清理屎山可不止恢復數據那點錢。
