透過視覺化語言傳達設計概念

人人學程式的風潮看來是一波波勢不可擋，隨之而來的，是越來越多工具與語言，各自強調撰寫程式的低門檻性，讓更多人相信寫程式是件簡單的事。

如果每個人都想學程式了，除了「簡單」之外，實際上，也還有更多重要的設計觀念，能透過這類簡單的工具或語言來突顯與傳達，進一步讓大家設計上實際的考量有哪些，而不僅止於學習那些結構化程式元素！

視覺化語言的時間成本

各式各樣各種顏色的積木方塊，交錯縱橫的流程與資料線充斥著整個畫面，「嗯？這條資料線接到哪了？」在一陣上下左右地捲動畫面之後，終於搞清楚資料線的目的地了，想想還是縮小畫面好了，這樣比較能一眼看出資料走向，而在縮小畫面之後，「嗯？這方塊中的值寫了什麼？」為了看清楚，又得放大畫面了，在一陣上下左右、放大縮小的來回操作之後，我極度不滿意地看著螢幕上凌亂的畫面，這明明是幾分鐘前才寫好的東西，為什麼現在卻看不太懂了？

在我先前專欄〈視覺化程式語言訓練了什麼？〉中，談過視覺化語言的幾個優勢，像是可以免除語法的糾纏，用視覺化的方式呈現出程式搭建過程，對於初次接觸程式的使用者而言，視覺化語言總被認為是低門檻、低時間成本的選擇，然而，複雜性就是這麼一回事，你一開始隱藏的某些複雜性，必然在後續於某處償還，視覺化語言免除了學習上的時間成本，最終，就是在空間維護上，造成了極大的時間成本。

或許有人會說，真正複雜的程式，就應當使用更實務的語言來撰寫，視覺化語言只要做為接觸程式的啟蒙語言，就足夠了，這在我看來有幾個問題，什麼樣的程式才是複雜？切換到實務性語言，初學者面對驟然攀升的學習曲線，就不複雜嗎？

實際上，就算只是寫幾個玩具等級的功能，也會讓視覺化語言的設計畫面，爆炸性地填滿各式程式元素積木，就拿Scratch來說就好，只要玩個幾小時，孩子們就可以在一個畫面中塞滿許多東西。

既然是要讓人們能體會程式設計，那麼就不該迴避這類問題，視覺化語言在接觸不久之後，空間上的維護成本很快就會突顯出來，即便如此，不如趁機做幾件事，善用這樣的機會，來突顯撰寫程式時也必須做的幾個設計考量，像是分而治之（Divide and conquer）、程式的簡潔、可讀性，以及註解的重要性等。

分而治之與事前規畫

現代程式設計鼓勵函式或方法儘量設計的短而小，像是最好不超過五行，最多最好不超過十五行，一個函式或方法中，若有太多行程式碼，應當找出子功能進行重構，獨立出來成為另一個函式，如此，函式不但容易閱讀、好維護，將來也易於與其他函式進行組合，建立新的功能。

對於初接觸視覺化語言的人們，通常會採取增量式的任務，例如，想讓機器人走出方塊路線，一開始可以讓它能直線走出指定長度，接著讓它能左轉或右轉90度，初學者往往在能走出直線後，繼續在既有畫面上增加功能，然後積木佔據的空間就逐步膨脹，隨便改動一個方塊，都可能造成程式異常而無法查出原因。

因此，在人們能設計出直線前進時，就可以教導他將這個功能封裝為一個獨立的積木，再繼續增加下個功能，而不是直接在現有的畫面中，繼續增加新的功能；另一個相反的方向，就是在看到畫面上開始充滿積木且凌亂時，鼓勵他將畫面中的邏輯泥塊（Logical lump，視覺上看來真的就是團泥巴）分解重構，讓畫面變得簡潔，每一層畫面只關心當時該關心的事。而且，如果必須瞭解某個積木的執行細節，可以進入另一個畫面，這是程式設計上階層化的概念。

無論是從哪個方向，當人們開始懂得將獨立功能封裝為獨立積木後，進一步地，可以鼓勵他做事前規畫，比方說想設計有三個轉動方向的機器手臂控制，事先就可以獨立設計各轉動方向的控制積木，並分別測試功能正常，而不是採增量式或重構的方式來產生新積木。

相較於越來越多程式入門工具或語言，一味強調簡單，結果卻Quick and dirty，不如多強調些分而治之與事前規畫的重要性，讓人們更能瞭解程式設計上，著實有著這方面的考量。

兼具簡潔與可讀需要設計

分而治之與事前規畫，可以取得彈性，而獨立出來的積木，也能讓學習者發現重用的概念，不過有時在視覺化程式設計的環境中，彈性不見得是最重要的考量，盡量讓程式畫面簡潔且易讀，會是更重要的考量要素。

要讓程式畫面簡潔的方法之一，就在於使用數量更少的積木，完成想要的功能。舉例來說，視覺化語言中，變數的指定與讀取就可能各用到一個方塊，減少變數的使用，就能讓程式畫面變得簡潔。

在實務程式設計中，確實也有許多暫存變數是不需要存在的，在使用視覺化程式語言時，也經常會出現這類不必要的變數，而且不久就能令畫面凌亂，移除這類不必要的變數積木，不但畫面得以簡潔，有時還會發現不同的設計方式。

想辦法使用小面積的積木，取代大面積的積木，也是讓程式畫面簡潔的方法之一。

例如：分岐判斷積木往往佔據較大空間，若程式需要在X數值為1時設定A為-5，數值為3時設定A為5，直覺上是會使用分岐判斷，不過，只要將(X - 2) ×5的結果設定給A，效果也是相同。雖然目的是為了取得畫面的簡潔，然而，得到的訓練卻是不受限於結構化語法元素，也就對於一件事，能有思考更多不同設計方式的機會。

使用小面積取代大面積的積木，這需要些設計，有時會違反直覺。如果取代後騰出的面積不大，也許看不出效果，此時可維持原設計；如果騰出面積的效果不錯，但違反直覺，那適當使用註解，以輔助程式流程的意圖。

雖然有句俗話是「一圖解千文」，然而在視覺化語言環境中，使用註解來說明後續簡潔積木的設計原理，有時反而會收「一文解千圖」的效果，多鼓勵學習者為特定設計撰寫註解說明（而不是把程式做的流程翻譯為中文），確實也是實務程式設計上重視的事。

背後的設計觀念越來越難

現代的程式設計有個趨勢，程式語言與工具越來越簡單，然而背後的設計觀念越來越難，這形成了一種很詭異的現象，活像是鼓勵著一群人在一開始快快樂樂學習程式，接著在之後陸續撞牆，然後才說：接觸程式設計，不見得將來一定要當程式設計師，因為這接觸過程訓練出來的創造力、邏輯等諸多能力，是可以適用在各個領域的……

簡單的程式語言與工具，不見得就無法有不簡單的設計。面對這些低門檻工具，目標除了擺在讓更多人勇於接觸程式之外，或許該進一步思考的，是要讓更多人有機會接觸到「設計」的諸多概念。

或許有人會說，不過就是視覺化語言，有必要這麼認真看待嗎？那麼我想反問，讓人們接觸視覺化語言的目的是什麼？或者是說，讓人們接觸程式設計的目的是什麼？不就是方才聲稱可訓練出創造力、邏輯等適用於各領域的能力？

如果一味強調簡單，卻沒有傳達相關設計的概念，那麼這類創造、邏輯等能力，也未免過於廉價了，我不敢想像這種訓練出來的廉價能力，在各個領域中能發揮出什麼樣的效果，若是如此，那麼接觸訓練成果如此廉價的程式設計，才是著實一點價值也沒有。