Go言語と和解するためにやったことと、プログラミング学習についての雑感
業務上必要になったので、最近はGo言語を少々書いている。ある程度手に馴染んできたので、「何をやったか」というのを備忘録がてら残しつつ、プログラミング学習について思うところを書いてみたい。
A Tour of Go の次どうする問題
Goの学習として、最初にやることが多いのは A Tour of Go だろう。ここに異論が挟まることはあまりないと思う。言語仕様が小さいので、A Tour of Go をやれば言語についてはだいたいの知識は頭に入る。
しかし、そこから先が分からない。作りたいものは定まっていても、「テストはどうするの?」「モックしたい時は?」「モジュールはどう分割するのがいいの?」「鉄板ライブラリは?」「CIのベストプラクティスは?」みたいな実践知は様々なところに転がっていて、「プロダクト開発に投入するならこれを読め」という決定版があまりないように感じる。(あったら教えてほしい)『みんなのGo言語』もTIPSを知りたい時には良いのだが、A Tour of Go以上、みんなのGo言語未満にある領域はどう知れば良いのか……というところで詰まっていた。とはいえ、これはGoに限らない話だと思う。たぶんプログラミングという営為全てに該当する話だ。
そんな中で参考になったのが以下の記事である。XXを学ぶときに参照したリソース、みんな公開してほしい。
まずは記事内でも紹介されている技育祭でのライブコーディング動画を写経した。ポイントとしては完成したものを写経するのではなく、なるべく動画に合わせて写経したことだ。これがけっこう効いて、「Goを書くときの勘所」みたいなものが掴めた気がする。たぶんペアプロみたいな感じだろう。その言語に強い人のライブコーディングに合わせて写経すると、空気感というか、目の付け所というか、「自分がこの言語を書くときはどこに目をやればいいか」というポイントが伝わってくる。比喩的な表現をすれば、息遣いが伝わってきた。ライブコーディングの写経はこれまでやってこなかったし、発想すらしなかったのだが、思い立ってやってみたところ結構効果があったので発見だ。
CLIツールが主な用途だったのでその次は mattn/memo を読んで、細かい部分はフューチャーの技術ブログを参照することでなんとか手に馴染みつつある。
知恵は言語化しにくい
得られた知見を言語化したいのだが、困ったことに知恵というのは言語化しにくい。「テストの書き方」「モジュールの構成の仕方」「ライブラリの使い方」みたいな単体のノウハウは言語化できるしたくさん記事があるのだが、Go(に限らずプログラミング言語全般)が持つ思想と、先ほど述べた息遣いみたいなものに関して書かれた文章は段違いに少ない。それに、息遣いが手に馴染んだ頃にはそれまで困っていた部分が言語化できなくなっている。いや、元から言語化できていないのに「困った」という感覚だけが存在していたのだ。
そのギャップを超える瞬間が、自分の場合はペアプロで起こりがちだと感じている。今回はライブコーディングの写経だったが、Kent Beck の『テスト駆動開発』でも似たような効果があったと思う。
ペアプロの効果は色々とあるが、こと知恵の伝播に関しては徒弟制めいたものを感じる。職人を「見て学ぶ」というアレだ。この態度はどうも批判されがちであるが、コードを書くスピードや、試行錯誤中の動き、問題解決にあたって何を見るかといった部分はいちいち説明するよりも動いて見せたほうがより早く伝わる。
ソフトウェア開発というのは一連の連続的な動きであって、離散的な知識の蓄積ではない。知識のネットワークもやはりグラフ構造で表されるデジタルなものであって、アナログな現実世界での実践知に落とし込むには「わかるまでやる」というプロセスがどうしても必要になる気がしている。
「わかるまでやる」ことの厄介さ
厄介なのがこの「わかるまでやる」というプロセスだ。というのも、量が理解に変わるために必要な努力は人によって異なるし、場合によっては永久に辿り着けないことだってある。
永久に辿り着けない場合の話をしよう。たとえばオートバイの運転では、目線を遠くに、行きたい方向にもっていくことが非常に重要だ。にもかかわらず、初心者は転倒する恐怖から目線が近くに寄ってしまいがちだ。自分もそうだった。その癖を治すのは大変ではあるが、「目線を遠くにやる」というポイントを教えてもらわなければ、スラロームもクランクも突破できないだろう。教官はニーグリップだとか様々なことを言うし、それも大事なのではあるが、こと低速小旋回においては目線ができていないと他のテクニックは役に立たなくなる。言い換えれば、「目線」というポイントを誰かから教えてもらうか、自分で「発見」するまではどれだけオートバイに乗っても「わかる」段階には辿り着けない。
翻って、世の中には「わかるまでとにかくやれ」という指導法ですらない根性論が跋扈している。しかし現実はオートバイの例からもわかるように、何か急所となるポイントを押さえられなければあらゆる努力は完全に無駄になる。効率が悪いとかそういうレベルではない。完全に無駄だ。「理解は遅れてやってくる」とはよくいったものだが、ハードルを越えられなければ遅れは無限大になる。
もちろん、教えられずともやっているうちに急所を見抜く人もいる。それが「センス」というやつだと思う。そして良くも悪くも自分はプログラミングにおいて、その道で不自由なく食っていく程度にはセンスがある。トップ層とは太刀打ちできなくとも「新しいパラダイムでも、良いコードを見ながら触っているうちになんか手に馴染んでくる」ことが多いから困った経験がそう多くなく、したがって言語化の必要もあまりない。
「見て学ぶ」「とにかく量をこなす」というのは教育ではなく、選別なのだ。
そしておそらく、プログラミングにおける「息遣い」に関する言語化が進んでいないのはこのせいだ。得意な人間は不得意な人間が詰まるポイントが分からない。これまでは「職業としてやっていく」という選別を勝ち抜いた、適性のある人間だけがプログラミングをやれば良い世界だったから問題なかった。しかし、プログラミング教育が重要になるこれからの時代はそうではない。
必要は発明の母だから、きっと遠くない未来にこのギャップを超えるための言語化がされるだろう。どちらかというとプログラミングが苦手な人がこの言語化をうまくやれば、教師として社会的な成功が得られるかもしれない。
それまでは「わかるまでやる」しかないのだけど。
この記事が気に入ったらサポートをしてみませんか？