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