駆け足となったが、GitやGitHubの使い方について概観した。ここで、この講義の目的はGitやGitHubの使い方を学ぶためのものではないことを再度強調しておきたい。学んで欲しかったのは、ツールが導入しようとしているプロセスだ。
Gitを単に使えるようになっても、例えばブランチを作るのが面倒だからとずっとメインブランチで作業して一本道の歴史しか作らないのであればGitを使う意味が薄れる。わざわざフィーチャーブランチを作る意味は何か？それは「現在行っている作業を明確化し、それ以外の作業をしない」と(自分に)宣言することだ。新機能を実装中に、既存の機能にバグを見つけてしまった。「一本道」の開発に慣れた人なら、そのままデバッグをはじめてしまうかもしれない。しかし、「必ず作業に一対一対応したブランチを作って作業をする」ことを習慣づけている人は、バグをissueに登録して対応を後回しにするか、逆に今手がけている新機能の開発を途中で止めて、ブランチを切り替えてデバッグにとりかかるだろう。デバッグが終了したら、改めて新機能開発用のブランチでその修正をとりこんで作業を再開すればよい。この「複数の作業を同時並行で行わなわず、いま行っている作業を明確化、単純化する」というのはバグを入れないために重要な姿勢であり、それを実現するための手段がブランチであり、issueであった。歴史についても、「中途半端なコミットをmainの歴史に残さない」ことを心がけていると、バグが入った時にgit bisectが使いやすくなる。これが、そもそもビルドに失敗する状態や、テストが通らないような状態がコミットとして歴史に残っているとgit bisectが正常に動作しない。そもそも「歴史をきれいにしよう」と思わない人は、git bisectを使おうとは思っておらず(もしくは存在そのものを知らず)、もし使えていたら短縮できた大きな時間をロスしていても、それに気が付くことはできない。わざわざプルリクを作るのはなぜか？レビューとはなんのためにあるのか？ツールは開発プロセスと密接に結びついており、うわべだけツールの使い方を覚えてもご利益は薄い。
技術の怖いところは、技術の導入目的や背景について知らないと、「もしその技術を知っていたら得られていたであろう恩恵」や「知らないことで被っている不利益」を認識することが難しいことだ。私がC言語を覚えたての頃、関数毎にいちいちint i;等と書くのが面倒で全てグローバル変数にしていた。当然、異なる関数で同じ変数を参照していたらバグるが、そのたびにデバッグしていた。なぜローカル変数が導入されたのか？スコープとは何か？それを導入することでどういうメリットが得られるのか？それらを理解しておらず、そもそも「自分が時間を損している」ということに気づいていなかった。同様に「新しい技術を否定し、古い技術でなんとかしようとしてしまう人」をよく見かける。彼らは新しい技術を古い感覚で使い、それでなんとか業務をこなしてしまうため、そのことで起きる機会損失に気づくことができない。
新しい技術やツールに飛びつけ、と言いたいわけではない。大学在学中に流行っているツールに習熟することで、ある意味での即戦力にはなれるであろう。しかし、それで一生食べていけるかは不透明だ。新しいツールが出てくる時、その背景にはなんらかの哲学がある。自分が手に入れた知識を絶対視することなく、なぜそれらが生まれたか、それらを使うことで何が得られるのかを理解し、その上で採用するかしないかを判断できるようになって欲しい。そして、目先の流行にとらわれることなく、10年、20年と闘える骨太な知識、見識を身に着けて欲しい。この講義/演習がその一助となれば幸いである。