這幾天參加了 Kotlin Hero 程式競賽前的練習,有個特別的體驗。
看題目一邊理解題意時,一邊就會在心理想像出程式流程的設計長得怎麼樣,比如輸入數值的型態為何?需不需要字串拆解?用什麼迴圈或遞迴編碼結構?一邊實作出來。或是歸納題意後,用數學運算公式整理簡化,比如真值表簡化換算,或是套用等差級數和公式等,再依簡化後的目標實作出來。前者依程式邏輯直覺,快速實作,後者需演繹歸納,但有優化。後者比較正確,但有時因為維護成本、時間不夠,前者的方式是很常見的。
回到練習,其中有個題目,我一眼掃過去,題意給我第一眼的感覺應該有個隱約的算數方式可以套用,也驗算了算數沒有問題,我就依照想法實作出來,上傳結果驗證通過。驗證結果會附上用了多少時間執行驗證,還有用了多少記憶體。這樣就可以得知你要運行你的程式要耗用多少資源。
這時就會好奇,那其他人的解法會是什麼?怎麼他耗用的資源可以比較少?此競賽練習期間可以點選其他人的解法,看他人怎麼寫。這樣反倒是幫助你可以深化對這題目的了解,和其他解的可能性探索。
偷看他人的解法發現,我的解這題的方式並不是比較直覺的解法。比較直覺解法是需要用到排序來找出資料間的關係,而我因為沒有想到排序前,就有了一個比較不直覺的算式,而且是正確的算式。導致我用數學運算,解了排序要解的問題。所以我的解法不用排序。而以算數代替排序的結果是我的解法耗用比較少的記憶體。我的解法雖不直覺,但低消耗資源。
看別人的解法還有一個有趣的地方就是可以看到不同風格的編碼寫法。會有 "喔,有這種簡潔的寫法","喔,原來還有這麼棒的內建函式可以這樣用" 的驚嘆。這對新語言的掌握可以更有幫助。整個解題過程,可以讓你更加去掌握新語言的運用細節。
另外的觀察,這樣的程式競賽系統和一般線上解題系統其實都是一種 TDD 的一種實現,只是單元測試撰寫者(出題人)和產品程式撰寫者(解題人)不同人而已。