プログラミングのアプトプットというと、
”学習したことを使って自分なりの成果物を作る”という部分にフォーカスしがち。僕もプログラミングを始めて2年ほど、この方法でアウトプットを重ねてきた。
しかし、学ぶ言語を変え、使うフレームワークを変えて学習を進めるうちに、「さて、過去にやった言語を使ってみようか」となるタイミングで必ずハマることがある。
それは「環境構築」だ。うちの会社の強強エンジニアもちょいちょいハマっているやつだ。
とにかく環境構築方法をアウトプットせよ！
環境構築方法なんてその都度Qiitaで調べればいいじゃん。
それがプログラミングを始めた当初の考え方だった。しかし、Qiitaの記事も古かったり、フレームワークやアーキテクチャのバージョン等の違いで、一発で構築できることは稀だ。
何記事も経由してやっとできた環境構築方法を記さず、プログラミングにさっさと入ってしまうのは、今ではリスクだと思ってる。
自分なりの「虎の巻」を作っておけば再現できたものを、それをアウトプットしておかなかったがために、ほぼ最初からやり直しだ。この労力の無駄感と後悔感はすさまじいものがある。。。
リンク集だけでも作る価値あり
たとえQiitaの記事1ページで済む環境構築だとしても、そのリンクを控えておく価値はある。学びのアウトプットではないが、学びを助ける重要なアウトプットだ。
環境構築方法は、同じテーマで何人もの人が投稿している。Qiitaだけでなく、ネット上に情報があふれている。このなかから「たまたま1発でズバリの記事が見つかっただけ」かもしれない。だからそのリンクを控える。
控える先はBlogでもWebノートでもなんでもいい。できればコードが書ける媒体がよいだろう。僕はScrapboxを使っている。ネット上に公開/非公開で自分だけのノートが持てる便利サービス（無料）だ。Googleアカウントでログインできるため、本当に重宝している。
環境構築方法のストックは人のためでもある
環境構築をするケースとして、PCの新調や学びなおしの他に「他者に教える」ということがある。
新人や友達にプログラミングを教えるような場合だ。ふいにこのような状況になり慌てないためにも、環境構築のアウトプットは大切だと思う。プログラミング本に書かれている通りの環境構築法がうまくいかない、なんてことはザラだから。
ベストプラクティスは自分で作るしかない。
環境構築方法のセオリーは変わるから意味が無いか
環境構築方法は確かに変わる。フレームワークのバージョンアップや、OSなどのアーキテクチャごとに微妙に変わるケースが多い。
しかし、環境構築方法をアウトプットし続けていると、そのあたりのさじ加減がわかってくる。「今」を残すことに大いに意味はあると感じる。
- OSごとにどこを変えなければいけないか
- ライブラリやモジュールの安定バージョンの選び方
- 推奨されている方法で構築しているかの確認
など。環境構築方法の”勘所”さえつかんでおけば、久しぶりの環境構築でも慌てることはない。ここで活躍するのが自分が作った虎の巻アウトプットだ。ローカルで開発している場合、HDDが吹っ飛ぶということもありうる。
GitHubにソースコード上げてあるからいいや、ではなく、Gitの設定をアウトプットしていなければ、１から調べなおしだ。僕も何度が経験し、GitHub接続の虎の巻をやっと作った。こういう作業は定型だが、覚える必要は全くないと思っている。カンペを見れば十分。
できることをアウトプットしても意味が無い
環境構築でハマってよくわかった。
「できることばかりアウトプットしても意味が無い」ことに。環境構築にかぎらず、プログラミングにおいて
- わかりにくいこと
- 忘れやすいこと
- 複雑なこと
- 手間がかかること
こういった部分を集中的にアウトプットすることで、効率化を図るのがアウトプットのひとつの成果だと思う。
たしかに、記憶の定着という部分でアウトプットをすすめる向きもあるが、人が覚えられることなんてそんなに多くない。それよりもつまづきポイントを的確にフォローすることで、効率を高めていった方が確実に前進できると思う。
さいごに
偉そうにつらつらと書いてみたものの、私はど素人のなんちゃってエンジニアだ。プログラミングも週末にちろっと嗜む程度。
それでも、会社の強強エンジニアですらやったことがあるはずの環境構築に手間取っているのを見ると、やはり初学段階での環境構築のアウトプットは重要だと感じる。
それにしても開発環境の構築方法はなんでこんなにややこしいんだろう。
コメント