ブログ

フロントエンドの知識が、断片のまま溜まっていました。

必要になるたびに調べて、動いたら次へ進む。それを繰り返していたので、個々のやり方は知っているのに、全体のどこに位置する話なのかが分かっていない状態でした。

調べて覚えると、地図が作られない

検索して覚えるやり方は速いです。目的がはっきりしているので、無駄がありません。

ただ、この覚え方には抜けるものがあります。自分が今どのあたりの話をしているのかが分からない。

右の列が空いていると、選べません。目の前の記事に書いてあるやり方を、そのまま採用するしかなくなります。合っているかどうかも判断できません。

並んでいることに意味がある

そこで、範囲を区切って1冊読むことにしました。この本を選んだのは、フロントエンドの守備範囲を一通り並べている構成だったからです。

1つ1つの解説の深さは、専門書には及びません。ただ、目的が違います。深く知るためではなく、何があるかを知るために読みました。

読み終えて変わったのは、知識の量ではなく、調べ始めるときの精度でした。何の話をしているかの見当が付くので、検索の言葉が決まります。出てきた記事が自分の状況に合っているかも判断できます。

発行から時間が経っている

この本の注意点は、そこに尽きます。フロントエンドは入れ替わりの早い領域で、当時の道具立てと今のものは同じではありません。

実際、自分が今このサイトで使っている作り方とは、前提からして違います。当時の具体的な手順をそのまま真似すると、古い書き方を覚えることになります。

それでも読む価値があると感じたのは、道具は変わっても、その道具が解こうとしている問題は残っているからでした。何を自動化したいのか、なぜ分けるのか、どこで速さが落ちるのか。その部分は入れ替わっていません。

今から同じことをするなら

全体像をつかむ目的なら、この本でなければならない理由はありません。今のフロントエンドを一通り並べた本であれば、同じ役目を果たします。

大事なのは本の新しさよりも、断片を集める読み方と、地図を作る読み方を分けていることのほうだと考えています。前者は検索で足りますが、後者は検索では作れませんでした。

今回の学び

まず、検索は見当が付いている範囲にしか効かないということ。知らないものは検索語にできないので、調べ続けているかぎり空白は空白のまま残ります。

次に、浅く広い1冊には、深い1冊とは別の役目があること。深さを求めて読むと物足りませんが、地図として読むなら浅さは欠点になりません。求めているものが違います。

そして、古い本は、問題と手段を分けて読むこと。手段は入れ替わりますが、その手段が何を解こうとしていたかは残ります。分けて読めば、古い本からでも持ち帰るものがあります。

プログラミングを教えていると、質問の種類が2つに分かれることに気づきます。

ひとつは「この書き方が分からない」。これは調べれば答えが出ます。もうひとつは「どっちがいいですか」。こちらは答えが1つに決まりません。

後者に答えるとき、自分が何を根拠に喋っているのかが曖昧でした。経験からそう思う、としか言えない。教える側としては、そこが一番あやしい部分でした。

教えやすいことと、伝えたいことがずれている

教材にしやすいのは、正解のあるものです。文法、関数の使い方、エラーの読み方。手順が決まっていて、できたかどうかも判定できます。

ところが、実務で差が出るのはそこではありません。

右の列は、教科書の形になりにくい。正解が状況によって変わるので、「こうしなさい」と言えないからです。

この本は、右の列について書かれている

この本が扱っているのは、ほぼ全部が右の列です。原題は The Pragmatic Programmer で、日本語版は第2版が出ています。

言語の解説はほとんどありません。代わりに、仕事の進め方そのものが並んでいます。同じことを2か所に書かない。壊れたまま放置しない。自分の道具を選んで使い込む。見積もりをどう扱うか。

ひとつひとつは短く、独立しています。順番に読まなくても成立する構成なので、必要なところだけ拾えます。

教える側として、いちばん効いたところ

この本を読んで、自分の説明の仕方が変わった部分があります。

それまでは「こう書くといい」と結論だけを渡していました。読んだあとは、「こうすると後で何が起きるか」を先に話すようにしています。

たとえば、同じ設定値を2か所に書いた場合。その場では動きます。問題が出るのは、片方だけ変えたときです。「今は動くが、変えるときに壊れる」という形で伝えると、納得の仕方が変わりました。禁止として覚えるのではなく、理由として残ります。

このサイトを作るときにも使った

教える側の話だけではなく、自分の作業にも効きました。

このサイトでは、ドメイン名やRSSの場所といった値が、いつの間にか複数のファイルに散っていました。どれも画面に出ない値で、書き換え漏れがあっても見た目では分かりません。

気づいたときに1か所へまとめたのですが、その判断の速さは、この本で読んだ考え方が下敷きになっています。「今は動いている」を理由に放置しない、という部分です。

教材として使うときの注意

そのまま課題図書にするのは向いていないと考えています。読ませるなら、ある程度の期間、自分で作って詰まった経験があってからのほうが効きます。

自分の場合は、必要な項目だけを取り出して、目の前の作業と結びつけて話す使い方をしています。本そのものを渡すのではなく、本から取った言葉を渡す形です。

今回の学び

まず、教えにくいことほど、実務では差が出るということ。正解のあるものは教材にしやすいのですが、そこは調べれば済む部分でもあります。時間をかけて伝える価値があるのは、判定しにくいほうでした。

次に、考え方に名前が付くと、会話が短くなること。感覚として持っているだけだと、毎回説明が必要です。名前があれば指し示せて、その先の議論に進めます。

そして、結論ではなく、後で起きることを渡すこと。「こう書きなさい」は覚えるだけで終わりますが、「こうしないと何が起きるか」は判断の材料になります。次に似た場面が来たとき、自分で決められる形になっていました。

自分で書いていないコードを直す仕事が続いた時期がありました。書いた人はもういません。仕様書もありません。あるのは動いているコードだけです。

読んでいて思ったのは、これを書いた人を責めても何も進まないということでした。同時に、自分が書いたものも、いずれ誰かにこう読まれるということでもあります。

読めないコードは、読みにくいコードとは限らない

最初に困ったのは、きれいに整っているのに何をしたいのか分からないコードでした。

字下げは揃っています。短い関数に分かれています。それでも読めない。理由を探していくと、名前でした。

const data = getData();
const result = process(data);
if (flag) {
  doIt(result);
}

形としては悪くありません。ただ、この4行を読んでも、何の処理なのかが1つも分かりません。名前が全部「何かの入れ物」で止まっています。

この本が答えていること

この本は、そういう「読む側の負担」を軸に書かれています。副題が「より良いコードを書くためのシンプルで実践的なテクニック」で、扱っているのは設計論ではなく、もっと手前の話です。

名前の付け方、コメントに何を書くか、条件分岐の並べ方、1つの関数にどこまで詰めるか。どれも今日書く1行に効く内容で、大きな作り替えを必要としません。

いちばん残ったのは、コメントには「何をしているか」ではなく「なぜそうしたか」を書くという指摘でした。

// ユーザーを取得する
const user = fetchUser(id);

これはコードを日本語に訳しただけで、読む側は何も得ていません。知りたいのは、なぜここで取りに行くのか、なぜこの方法なのかのほうです。

引き継ぐ側にとって、いちばん欲しかったもの

実際に困った場面を思い返すと、欲しかったのは常に判断の理由でした。

右の列が分からないと、触っていいのかどうかが判断できません。一見無駄に見える処理が、実は過去の不具合への対処だった、ということは珍しくありません。理由が書いていないと、消して初めて分かります。

読んだあとに変えたこと

このサイトのコードでは、コメントの書き方を変えました。処理の説明ではなく、なぜその選択をしたのかを残すようにしています。

たとえば「この値を1か所にまとめた理由」や「この設定を別のファイルに切り出した理由」を、選ばなかった案と一緒に書いています。半年後の自分は、今の自分が何に困っていたかを覚えていません。困りごとごと残しておかないと、また同じ場所で悩みます。

合わないかもしれない場合

扱っているのは小さな単位の話なので、設計全体をどう組むかという話は出てきません。そこを求めて読むと物足りなく感じます。

あと、例に使われているコードはC++やJavaScriptなどが中心です。普段そのあたりを書いていなくても読めますが、言語固有の書き方を学ぶ本ではありません。考え方を持ち帰って、自分の言語に翻訳する読み方になります。

今回の学び

まず、コードは書く時間より読まれる時間のほうが長いということ。引き継ぐ側に回って初めて実感しました。書いているときは自分しか読者がいませんが、動き続けるコードには読者が増えていきます。

次に、名前は飛ばし読みのための道具だということ。読む人は全部を読みません。名前で当たりを付けて、必要な場所だけ開きます。名前が中身を表していないと、この省略が使えなくなります。

そして、残すべきは処理ではなく判断だということ。何をしているかはコードを読めば分かります。分からないのは、なぜそうしたかのほうでした。そこが書いていないと、後から来た人は消すことも直すこともできません。