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

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

視覺化語言的時間成本

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

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

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

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

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

分而治之與事前規畫

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

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

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

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

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

兼具簡潔與可讀需要設計

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

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

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

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

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

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

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

背後的設計觀念越來越難

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

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

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

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

專欄作者

熱門新聞

Advertisement