做自動化工具的主人，而非奴隸

自動化的科技，讓將原先需要人類介入處理的勞力或是瑣碎細節，全部都交由機械及電腦處理，讓人類省下力氣以及空出時間，來處理其他更重要的事情。而且有時候，自動化的機械在處理繁瑣的工作時，通常處理的比人更好。因為大量自動化所帶來的便利性，更驅使人類發明更多自動化的器具及機制。而在程式設計工具的發展上，更是如此。

用來開發程式的工具軟體，具有自動化特性
程式設計工具，從用以組譯組合語言的組譯器，到各種高階程式語言的編譯器，都可以說是某種程度的自動化工具。

在程式設計者編寫易於記憶的機器語言形式（也就是組合語言碼）之後，組譯器能夠自動的將它們轉換成為一對一對應的機器指令。而高階的程式語言更跨進了一大步，將原本可能需要花費眾多機器指令執行的步驟，濃縮成為更簡潔、同時也更簡單的表述形式。再利用自動化的編譯器，將高階、簡潔的程式碼，轉換成為最終、最原始、CPU可直接執行的機器語言指令碼。

高階程式語言的問世，大大簡化設計者撰寫程式時所需要處理的各種繁瑣細節，以及所花費的時間，也讓程式設計者，可以用更接近解題的方式來描述解決問題的方法。

你可以想像，如果少掉了這些語言上的自動化，程式設計者將被迫先將腦中的解題方式，轉換成為符合CPU指令的思考模式及邏輯，接著再逐一寫下由0與1構成的機器指令碼。這中間充滿著各種十分瑣碎的細節，即使再熟練的程式設計者，都有可能不小心犯錯。

而且，要利用人類的腦力，將解題方式直接轉化成為機器指令碼，更不是一件輕鬆的工作，程式設計者需要花費更多的心神在這中間的轉化，而無法專注在問題的解決本身。

有了自動化的高階語言編譯器之後，大大提高程式設計者的便利性，也省去了大量花在細節工作的時間及心力，避免無所謂的犯錯，而且更重要的是，程式設計者可以將心思放在真正需要關心的部份──也就是程式本身的應用之上。

許多的開發工具，幾乎都可以說是圍繞在這些主軸之上一代替程式設計者處理那些以勞力為主的、具有高度可重覆性的繁瑣細節性工作，以及讓程式設計者利用更接近解題空間中的表述方式，來描述解題的方法。

從使用介面開發工具的發展來看自動化
舉例來說，在所謂「所見即所得」的使用者介面開發工具問世之前，程式設計者想要撰寫產生使用者介面、以及處理和使用者介面元件之間的互動，可以說是相當不直覺。

你會需要自己寫下建構各種元件、指定其各種屬性包括位置、尺寸、顏色等等的程式碼。你得自己在腦中將所想像的使用者介面長相，直接轉換成為對應的程式碼。

這樣子的設計方式，不僅不符合設計使用者介面的直覺，而且，程式設計者必須花費較多時間才能得到心目中所預期的使用者介面。相反的，透過「所見即所得」的使用者介面開發工具來設計使用者介面，程式設計者只需要拖拉所需的元件，即可調整其位置及尺寸。

此外，對於元件各種屬性的設定，像是字型大小或顏色，都可以在設定完成後，直接反映在畫面之上。當設計者透過上述的方式完成設計之後，開發工具即可自動的產生出對應的程式碼。這樣的設計方式，不僅相當直覺，而且大大簡化了產生使用者介面程式碼的程序。

有了工具，大幅提升開發軟體效率
就生產力的觀點來說，各種透過自動化機制來提供快速軟體開發生產力的工具，對人類開發軟體，可以說是提供了相當大的幫助。各種陸續被發展出來的開發工具，也持續縮短人們開發軟體的時間、讓開發者得以在更短的時間內設計出更為複雜的軟體。

從學習的觀點來看，由於這些開發工具允許設計者，以更接近解題空間的方式來描述解題的方法（例如用所見即所得的方式來設計使用者介面），降低了設計者對於程式設計細節的倚賴，自然而然得以降低學習的門檻。

正因為這些自動化的工具能夠提供諸多的好處，所以才會有愈來愈多的開發者，在開發的工作中運用這些工具。漸漸的，也同樣有愈來愈多的開發者，對於這類工具的倚賴愈來愈重。甚至，有相當多的初學者，在一開始就使用這些自動化的工具，他們的開發生活離不開這些工具。

手動雖然很辛苦，但能讓你更隨心所欲
某種程度來說，這並不是壞事，正如一開始我提到的，工具本身的發明，就是為了代替人類處理此類的工作。對開發者來說，用更輕鬆、直覺的方式、花更少時間，還可以減少犯錯的機會，其中所得到的生產力是十分可貴的。

但是，高度的倚賴自動化工具去開發，並非全然沒有缺點。

首先，因為自動化的工具幫你隱藏住許多細節，這使得你即使不明白這些細節，也依然可以得到所需的程式碼，或是達到相同的目的。但是，有些時候，當工具為你所代勞的行為和你所預期的不同時，會因為你並不了解這些細節究竟是如何運入，而使得你陷入困境，無法找出究竟是那裡出錯的。

舉個例子來說吧，一些Java的整合開發環境，都會自動為程式設計者設定所謂的CLASSPATH環境變數，也就是Java虛擬機器（JVM）載入類別及程式庫的路徑。對於設計者來說，這當然很方便，省去了繁瑣的設定工作，也讓程式設計者得以在完全不明白CLASSPATH觀念的情況下，依舊可以撰寫、運行程式。

但是，假如所載入的類別不如程式設計者所預期時，此時，因為他完全不具備CLASSPATH的觀念、在過去都是由整合開發工具所代勞處理，所以，他會不知道該如何排除問題、甚至完全不知道，這可能是由CLASSPATH設定錯誤所造成的。

相反的，倘若程式設計者是一個透過命令列介面（Command Line Interface，CLI）來開發Java程式的設計者，那麼，為了要編譯、運行程式，他應該都具備CLASSPATH的觀念，那麼，即使這中間出了差錯，他也能找到正確的原因進而加以排除。

除了解決被自動化工具所遮蔽掉之細節所衍生的問題之外，全天下所有的自動化工具都比不上手動的一點就是──手動的方式更能隨心所欲。這就好比現代的數位相機一樣，你可以選擇讓相機自動決定快門、光圈等曝光的參數，簡單又省力。但是，自動的曝光模式終究比不上攝影者手動決定曝光參數來得隨心所欲。

因此，過度倚賴自動化工具，會陷入自動化工具所能自動化的模式之中，但是很多時候，我們所要解的問題，並不在自動化工具所提供的既定模式中，這時候，只有運用手動的方式，才能在這些模式之外，得到解決的對策。

本文的論點並不在主張不應當使用自動化工具。自動化工具有其正面的作用，但是，手動是自動的基礎。這些自動化的工具是因為工具的發明者知道如何利用手動的方式達成目的，才知道如何加以自動化。對我們來說，利用自動化工具來得到生產力是正確的方向，但是並不應該完全忽略掉背後究竟是如何運作的原理。明白這些原理，有助於在發明問題時，跳出工具的限制來排除問題。也有助於，當工具提供的現成模式無法滿足需求時，得以回到原始的手動方式來達成需求。

我們在日常生活中可以用自排車代步，但是，當我們在某些特殊的場合需要特殊的操控需求時，我們也可以開著手排車上路。