程序員之拍案驚奇：為什么我會一天到晚的想說FUCK！
經常有人找我給他們的軟件項目做修改或維護，我對這些項目毫不了解，而他們只告訴一些很少的項目相關信息。必然的，需要在項目中增加一些新的功能，但在動手之前，我通常需要耗費大量的功夫來大幅度的重構它們。
JavaScript (Photo credit: Johannes_wl)
大概一個月前，一個公司老板給我來信“嗨，我有一個軟件，需要做一些個性化的改動，有個大客戶愿意花一大筆錢來買它，正等著呢，可我現在都沒辦法讓它跑起來，最初的開發人員都找不到了。你能幫我搞定它嗎？”
最初的程序員的逃離已經是亮起了紅燈，但這個項目的技術架構正和我的胃口：node.js，mongodb，大量的事實數據流，以及UI上更新的速度要求。這個等待使用這個軟件的用戶的名字也讓我精神一振。
我干！能壞到哪去？
你會忍不住的想罵街
能壞到不能再壞。
項目的一部分是用Java寫成的。這很好，根據項目的現狀，選用靜態類型的語言是明智的選擇。
而其余部分是用Javascript寫的。Java和服務器端JavaScript和前端Javascript通信的機制是…..哇塞，這有個限制，參數名長度不能超過3個字符。
好吧，節省帶寬，不是嗎？我們現在說的這個項目具有巨大的數據流量，所以就盡量讓json對象保持最小體積吧。
這就是讓事情變得棘手的地方。
因為核心傳輸協議里只讓各種變量名長3個字符，所以數據庫設計也遵照這個原則。因為數據庫里的各種表名、字段名、視圖名等等都是這個模樣，你猜怎么著？沒錯！所有的程序代碼都沿襲了變量名不超過3個字符的特征。
這個風俗的滲透超出了變量名進而感染了數據。
為什么在應該寫成label地方偏要寫成lbl呢？以及諸如此類，等等等等…..在差不多兩個月的研究這個項目后，我仍然不知道大部分的變量名的真實含義。我只是把它們當作是拉丁語，用來描述一種模糊的概念。我開始對這個項目是如何運轉的有了一些理解。
情況慢慢清晰起來。
如何讓一個布爾值符合這種命名機制？這樣做：
- function fix(boolean_value) {
- return boolean_value ? 'tru' : 'fls';
- }
好吧，但愿事情到此為止，但我發現了另外一個有趣的東西…這個東西在很多代碼里反復出現，我不敢動它們，我怕會發生什么不可思議的事，會讓有些程序跑不起來。
我有沒有跟你們說過這個項目是沒有單元測試代碼的？當發現需要給它們寫單元測試時你知道我有多受打擊嗎？但是，好在這個項目看起來最終不需要通過一個安全測試….哦，等一下，程序里有安全檢查代碼。
- if (!thing || thing === 'null') ...
起初我一直在寬慰自己說他們這樣做一定有必要的原因。
不管怎樣，我全忍受了，有些東西從某種角度看似乎是合理的，有些可能是過度優化造成的。很糟糕，但有些我還是可以忍受的。
下面的這個是讓我真正抓狂的東西：
- function getPurple(cake) {
- cake.color = global_color_setting;
- return cake;
- }
我甚至不知道如何入手去重構它，讓它變得有實際作用…完全就是…什么玩意？誰干的！？
然而，這最糟糕的事情，最最糟糕的事情是，這個項目不知從何時起由傳統的jQuery轉向了Backbone。這沒任何的問題，遷移的很好，我喜歡Backbone！
但他們忘了進行徹底的遷移。很多時候Backbone只是一個很薄的皮，包著舊的東西。大部分的代碼甚至根本沒有使用Backbone，仍然使用大量的$.ajax，隨處可見。
在這樣一種弱類型化的語言、沒有單元測試代碼的情況下，我根本不可能說“嗨，我修改名稱X，請把相關的所有引用都改一下”…用grep命令搜索，也只能這樣了，我的這段日子過的太充實了。
不知道系統什么時候就會突然崩潰，因為我也忘了去測試…
