カテゴリー: 読んだ本の感想

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

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

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

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

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

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

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

そこで、範囲を区切って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などが中心です。普段そのあたりを書いていなくても読めますが、言語固有の書き方を学ぶ本ではありません。考え方を持ち帰って、自分の言語に翻訳する読み方になります。

今回の学び

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

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

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

自分のサイトを公開したあと、脆弱性の検知と監視の仕組みを作りました。依存関係を見張って、警告が出たら気づけるようにする、という内容です。

そのとき読んでいた情報は、全部が守る側のものでした。

守り方は分かる。何から守るのかは分からない

「この設定を入れる」「このヘッダーを付ける」「このバージョンに上げる」。守る側の情報は、やることが具体的に書いてあります。そのとおりにやれば作業は終わります。

ただ、終わったあとに本当に守れているのかが判断できませんでした。

理由ははっきりしていて、攻撃がどういう手順で進むのかを知らなかったからです。手順を知らないまま対策だけ並べると、全部が同じ重さに見えます。

手を動かす本を選んだ

そこで読んだのがこの本です。TryHackMeという、攻撃を試すために用意された環境を使いながら進みます。

解説を読むだけの本ではありません。指示されたとおりに調べ、見つけ、入る。その手順を自分でなぞります。

やってみて分かったのは、残り方が違うということでした。読んだだけの知識は「そういうものがあるらしい」で止まりますが、自分の手で手順を踏むと、どこが引っかかりやすいかまで体に残ります。

読むだけでは、半分しか入らない

この本の注意点はここです。手を動かす前提で書かれているので、読むだけだと半分で終わります。

環境の準備や、うまくいかないときに止まる時間も含めて、それなりにまとまった時間が要ります。通勤中に読み進める種類の本ではありません。時間を確保してから始めるほうがいいと思います。

7日間という題名ですが、1日ぶんに何時間かかるかは書いてある内容と自分の慣れ次第です。自分は日によってかなり差がありました。

使ってよい範囲について

ここは書いておきます。

この本で扱うのは、そのために用意された練習用の環境です。同じ手順を、許可を得ていない相手に対して試してはいけません。技術として成立するかどうかと、やってよいかどうかは別の話です。

自分の場合、試す先は自分のサイトと練習環境だけにしています。攻撃側の手順を知る目的は、守る順番を決めるためであって、それ以上ではありません。

今回の学び

まず、守る側の情報だけでは、優先順位がつかないこと。対策は列挙できても、どれを先にやるべきかは攻撃の手順を知らないと決まりませんでした。

次に、体験は、残り方が違うこと。読んで分かったつもりになっていたことでも、自分の手で通してみると引っかかる場所が出てきます。その引っかかりのほうが、あとで効きます。

そして、知ることと、やってよいことは別だということ。手順が分かるほど、その線を自分で引いておく必要が出てきます。本の中で扱われている環境が、練習のために用意されたものである意味は、そこにあります。

CMSを作っている会社にいたころ、製品のベースがRailsでした。仕事は管理画面やフロントの改修です。

コードは目の前にあります。動いてもいます。それなのに、何をしているのか読めませんでした。

読めない、の中身

最初は「経験が足りないから読めない」のだと思っていました。実際には、もっと具体的な詰まり方をしていました。

目の前の1行が、Railsが用意した仕組みなのか、Rubyの文法なのかが区別できない。

これが分からないと、次の一手が決まりません。

3つのどれかは分かるのに、どれなのかが分からない。結果として、調べ始める場所が決まりませんでした。

フレームワークから入ると、言語が抜ける

入り方が逆だった、というだけの話です。

ふつうは言語を覚えてからフレームワークに進みます。自分は製品の改修という入口から入ったので、Railsの決まりごとは仕事の中で覚えていきました。「こう書けば動く」は増えていきます。

ただ、その下にある言語そのものは通っていません。だから、Railsの型に当てはまらない行に出会った瞬間に読めなくなります。

言語の本に戻った

そこで読んだのがこの本でした。Railsの本ではなく、Rubyそのものの入門書です。

文法を順番に追う構成なので、フレームワークの側から入って穴が空いている状態を埋めるのに向いていました。「ここはRubyの書き方だ」と分かるようになると、調べに行く先が決まります。それだけで手が止まる回数がはっきり減りました。

特に効いたのは、ブロックやシンボルのようなRubyでは当たり前だが、他の言語から来ると初見のものです。Railsのコードにはこれらが大量に出てきます。知らないまま読むと全部が「Railsの魔法」に見えます。

この本で埋まらなかったこと

当然ですが、Railsの作法はこの本には書いてありません。言語を埋めるための1冊と割り切る必要があります。

それと、他の言語をすでに書ける人にとっては、前半は既知の内容が続きます。飛ばしながら読んで、知らない書き方が出てきたところで止まるという読み方になりました。最初から順に読む本としては、少し長く感じるかもしれません。

今回の学び

まず、入る順番は逆でもいいが、どこかで戻る必要があること。フレームワークから入るのは実務では珍しくありませんし、そのほうが早く戦力になります。ただ、戻らないままだと「形から外れた瞬間に止まる」状態が続きます。

次に、詰まりの正体を言葉にすると、対処が決まること。「読めない」のままでは何を勉強すればいいか分かりませんが、「言語かフレームワークかの区別がつかない」まで分解できれば、読むべき本は1冊に決まります。

そして、調べる場所が決まらないことが、いちばん時間を食うこと。答えを探す時間より、探す場所を決められない時間のほうが長かった。ここは知識の量ではなく、切り分けの問題でした。