取巧圖便背后臃腫的代價 討厭的剪切粘貼
我是在譴責(zé)集成開發(fā)環(huán)境。
在過去而言，編程是一件很困難的事情。不是因為編程本身就過于困難，主要是因為編輯器太爛。很多在 70 和 80 年代遭人嫌棄的編輯器都沒有流傳至今（除了少數(shù)非常幸運的，以及那些很有可能用過 DEC 和 WANG 工具的編輯器）。我在打卡時代末開始從事編程工作。以前用打孔來寫程序非常搞笑。曾幾何時，如果你掉了一塊用在分類機上的甲板，也會鬧出很多笑話（好吧，也許兩次，無一例外，分類機每使用三次就會堵塞一次，場面相當(dāng)混亂）。我曾經(jīng)工作過的銀行在 1986 年還在使用那種分類機。
（如果你想看看順序排列< source.cbl >的等同于穿孔卡的分類結(jié)果，mv 將看起來很有歷史的 source.cbl 分離了出來，Youtube 上有一個不錯的視頻。）
幸運的是，電傳打字機取代了穿孔打卡系統(tǒng)。接著它走上了 Mastodont 的道路（人們覺得他們都一樣重要），不過最初的基于終端的通用型電腦監(jiān)控器并未比玻璃制品的電傳打字機好用。【停下來以稍作調(diào)整】
關(guān)注一下各種文檔的不同功能（假設(shè)文檔具有語言選擇功能，但你不能認為文檔理應(yīng)具備），這些功能需要有直觀的印象或者是非常嚴格的命令。否則你得花上一整天的時間去找‘那項功能’或者‘那個變量聲明’。重新編寫一塊代碼，代碼塊要求一行一行的重新輸入。這樣麻煩透了，所以你最好盡可能地避免。
有一些可以讓你不用重寫大量代碼的方法：
▲在寫代碼之前先花很長一段時間思考程序，這樣就不用頻繁地改動
▲確信在整個程序中一次就把代碼寫好
▲盡可能多地將你的代碼提煉到你的重用代碼庫中
探測性編程代價巨大
后來全屏式的編輯器出現(xiàn)了。相對于行式編輯器，這種編輯器無以倫比。真的。如果你不相信的話可以花一兩天去試試’edlin’。到時候我們就會知道你是多么的愛不釋手。至此，你就會知道，在頭二十年的計算機操作中，所有的軟件編碼一點都不容易。
之后，你每天也要受 Irons 和 Djorup 他們二位的罪，每天兩次。（伯樂在線注：Edgar T. Irons 和 Franz M. Djorup 兩人開發(fā)過一個全屏式的編輯器：O26。）
我工作用的第一個編輯器不錯，可以快速移動文本，擁有區(qū)塊標記，復(fù)制，移動和刪除等功能，是我集成在 6809 微型計算機上的編輯器。有些設(shè)計計算機設(shè)計工具的事情確實很煩人，這就是：工具綁定。無論你正做（build）什么工具，你都需要另外一個工具。為了寫一個匯編程序，你需要一個編輯器和匯編程序，而且為了寫一個編輯器，你需要第三方編輯器和匯編程序（或者編譯器）。如果沒有借助第三方編輯器來編寫你自己的編輯器是很棘手的事情。
當(dāng)編輯器做好之后，第三方編輯器雖然不完善但也還能使用。我將它命名為‘e’（我真的不喜歡鍵入長命令的名字，‘e’以及它的后續(xù)版本在 2000 年早期的時候作為我主要的 go-to 文本編輯器，用起來還不錯，它擺脫了處于 vi 和 emacs 中間的地位。它已經(jīng)退休了，現(xiàn)在版本控制系統(tǒng)庫中安享晚年）。
在幾年之內(nèi)，“編輯→編譯→測試”或者“編輯→匯編→測試 ”循環(huán)從幾個小時縮短到幾秒鐘，就像以前社會勞動生產(chǎn)力得到了最大限度地提升一樣。
曾經(jīng)我能夠進行模塊復(fù)制，我注意到我的程序會瞬間很快變得很長，變成在一瞬之間從幾千行擴展至1萬多行的龐然大物。在變成有效的模塊之前，這個龐然大物好像在短短的時間之內(nèi)做了太多太多的事情。
在我可能將通用的行為抽象為一個函數(shù)，或者增加一個參數(shù)，設(shè)計若干可以調(diào)用一個已有功能的宏命令之前，一字一句地重復(fù)鍵入若干行代碼的代價精簡為三個按鍵就可以很快完成復(fù)制，這看起來是一個非常好的主意，我并沒用花費太多時間就認識到了。
在我發(fā)現(xiàn)這個隱藏的壞習(xí)慣之前，我已經(jīng)編寫了很多代碼。也許這個事實對我真的有所幫助。所以很自然地，我沒用那樣做，這是一個讓我們很容易上當(dāng)?shù)南葳澹T惑無處不在。這僅僅是一段代碼，對嗎？我碰巧遇到了，也許你也會碰巧遇到。剪切粘貼，那時候看上去是多么好的一個構(gòu)想啊。
不過就像任何靈敏的工具一樣，它有剪切的能力，就像你砍木頭一樣，所以你得小心運用。
隨意使用剪切粘貼工具的代價可以用臃腫來形容，如此的臃腫把最簡單的程序變成了一大串解釋不通的語句，其中夾雜了許多的功能和僅僅在細枝末節(jié)上有所差別的部分代碼。前段時間，我參與了一個項目，這個項目是用一種我在這篇博文中沒有提到的語言（Java）編寫的，而且該項目在“linecount部門”這一功能上有一些嚴重的問題。之前有個程序員一怒之下辭職離開，領(lǐng)導(dǎo)要求我接手，為代碼增加一些特性。這個程序絕對是一個龐然大物，但看起來也不是全部都有用。從根本上來說，這個程序需要的是，無論什么時候都可以訪問，更新數(shù)據(jù)庫中的表，或者向其插入一條事務(wù)記錄，僅此而已。
而且這些事務(wù)看起來都差不多。除了表的命名以及可能一兩個參數(shù)之外，其他都是相同的。
這些事務(wù)的真實情況是，每件事務(wù)的代碼都只有30行左右，但程序訪問了一大堆表。剪切→粘貼（或者：復(fù)制→粘貼）。
我最近參與的一個程序，最初是由另外一個程序員編寫的，乍看起來非常整潔。不過看得越多你就越發(fā)現(xiàn)，它完全是由很多個5到20行的通用模塊（Chunks）構(gòu)成。到處都是那些模塊。“剪切→粘貼”。
現(xiàn)在，別誤會我。剪切→粘貼有它們的用處。就像其他工具一樣，你需要弄清楚它們的作用，它們有什么功能（比如，如果沒有具備輕松改動周圍代碼的能力，你就不要重構(gòu)代碼了），以及它們的短處（寫代碼）。
現(xiàn)在的集成開發(fā)環(huán)境，演變成了通過一次簡單的鼠標點擊就可以產(chǎn)生幾百行的標準代碼。這種現(xiàn)象比以往任何問題都要更加嚴重。
當(dāng)然，如果你確實不想了解你要維護的代碼，這種做法也無可厚非。對此，我稱之為“Fire & Forget”軟件，或者是“職業(yè)安全感”和“噩夢”，這取決于你的觀點。
（伯樂在線注：Fire & Forget 譯為“射后不理”泛指武器在發(fā)射之后，就不再接受任何外界指揮、管制或者是射控系統(tǒng)的資料，更新自己的座標或者是目標的訊息。發(fā)射武器的載具能夠進行其他的作業(yè)，包括搜索標定下一個目標，或者是離開發(fā)射地點。 via 維基百科）
不過，如果你的目標只是為了獲取及保持對代碼的控制權(quán)，讓公司能夠生存下去的話，那么，代碼的規(guī)模越小越好。
小規(guī)模的代碼更有好處，因為規(guī)模小，你就會很清楚代碼的用途。這樣的代碼越好，因為它縮小了你關(guān)注的范圍，正如它縮小了變量的總數(shù)一樣。需要完全理解的代碼行數(shù)減少了，并且一旦你完全理解了代碼，bug自然也就藏不住了。因為你的程序會更加緊湊，運行將會更快（因為程序的較大部分適合在緩存中運行），我們也更容易維護代碼了（因為更容易理解的緣故）。其他像減少編譯時間的東東是不錯，但不是主因。
以前的程序員，只能通過全屏編輯器才能了解世界，如果你從那時候就開始編碼直到現(xiàn)在的話，我有幾句話想告訴你：
考慮下復(fù)制、粘貼的順序，下次你將會用到。這并非沒有代價，你還得敲兩下鍵盤。我討厭這兩下子……不過，每當(dāng)我需要重構(gòu)一堆別人編寫的，用起來好像不用收費的剪切粘貼軟件時，就覺得這兩下子還挺受人喜歡的。
原文作者：jacquesmattheij
原文鏈接：http://blog.jobbole.com/9047/
【編輯推薦】
