日々常々

ふつうのプログラマがあたりまえにしたいこと。

簡易的な技術記事の取捨選択法

見るべきポイント

3点です。

  • バージョン
  • ソースと実行結果
  • プロダクトのソースコードや公式ドキュメントへのリンク

これらが記載されていない技術記事は、参照する優先順位を下げるのがいいです。

説明

増え続ける一方の技術情報ですが、あまりにあふれすぎて「何を参照すればいいかわからない」といったことに陥りがちです。これはある程度経験を積まれている方でも同様で、調べ物されているのを眺めていると「ガチャっぽい調べ方してるなぁ」と思うことがしばしばあります。 「ガチャっぽい」と言うのは、当たる当たらないの話になっているので、「いつ解決するのか」が全く見当もつかないことを指しています。天井なしのガチャですね。関係ないけど最近のガチャは天井があって親切……よくすり抜けるけど……。

さてそんなわけで技術記事に溢れる昨今、私が言語化できている取捨選択法を書いておこうと思いました。 例えばドメインで「このサイトは信用に値しない」とか言うのは簡単なんですが、玉石混交なので流石に厳しいと感じ始めてきました。 もしこれができるならHTTPSみたく証明局つくって「この技術記事は信頼できます」とか(妄想)。

調べ方は調べ方で一大テーマなので別枠として、本記事は出てきた後の取捨選択に関わる、上記3点の説明です。「そうだよね」と思われているなら読む必要はありません。 技術記事を書く時の基本といえば基本です。

バージョン

まずバージョンは自分の状態と一致するかどうかです。前提として自分がどのバージョンを使用しているか把握しておく必要があります。

バージョンが重要なのは、書いている通りやってうまくいかなかった時にバージョン違いに見当をつけられるからです。 バージョン違いはリリースノートやマイグレーションガイドなどを参照すれば解決する可能性があります。 「少なくともこのバージョンでは動いていた(らしい)」であれば、同様の問題に衝突している人もいるでしょう。その観点で調べ直せばきっと解決します。

また、記事のバージョンよりも自分の使用しているバージョンが古い場合。これもリリースノートなどを見てからですが、「無いんだな」と諦めることができます。無いものは仕方ない。いやバージョンあげろよって話かもしれませんが、できない事情もありますしね。無い物を探すと言う完全に無駄なコストをかけずに済むようになります。部分的にバックポートとかも選択肢に出てきますし。

ソースと実行結果

ソースは文字通りの「出どころ」くらいの意味で使っています。ソースコードに限らず、設定も含みます。 そのまま実行できるコードがGitHubなどにあるとベスト。設定もas Codeできる時代ですしね。

これがあると「動いた(らしい)」から「動いた」に変えられます。「らしい」を外すのは非常に重要なのですが、ものによってはすごく手間です。 実行可能状態で公開してくれてると非常に助かるんですよね……自分もそうしようとするんですけど、面倒でついサボってしまう。

「同じバージョンでやってるつもりでも動かない」は往々にしてあります。 書いているものと他の何かしらの環境が違うのかもしれませんし、些細なミスかも知れません。 この時に自分の手元で動くものを確保できるかで精度は段違いになります。不具合も再現できるかが重要ですよね。あれと同じです。

あと、公開してくれているソースそのままでも動かなかった時、もっと外側の環境要因を疑えるようになります。 関係ないけど、この環境要因もコンテナがかなりの部分を解決してくれてますね。

プロダクトのソースコードや公式ドキュメントへのリンク

参照した記事には記者の解釈を多分に含みます。切り捨てられている情報もあることでしょう。なので出典が欲しいところです。「ソースはWikipedia」は技術問題の解決にはちょっと微妙。 「最初からソースコードや公式ドキュメントを読め」と言うのは尤もなんですが、それができる方は本記事とは無縁に生きていると思うので割愛。

ソースコードや公式ドキュメントのリンクがあると、正確な一次情報を知れますし、少し応用する場合に対応できる幅が広がります。 またとっつきにくい公式ドキュメントであっても「こう読めばいいのか」「この内容はここに書いてあるのか」と言うのが分かります。 一次情報に当たれるようになると今後の調査精度も上がりますし、自信を持って答えられるようになります。

蛇足

昨今の富豪的な計算資源により、トライアンドエラーにかかるコストは大幅に減っています。そのため「出てきた情報をとりあえず試す」と言うのはそれほど悪くはない選択肢です。動くのは絶対的な価値です。しかしながら、もし仮にそれで動作したとして「それでいいのか」と言う問題が残ります。少なくとも調べ物をすると言うことは、その知識がない状態の人間(自分)が手を出しているものであり、そう言う人間(自分出なかったとしても組織としてそう言う人を受け入れている)が今後も触ると言うことです。もしうまく動かなくなった際、再び調べる必要が出てくるでしょう。この「将来調べるのにかかるコスト」は負債であり、もしかしたら支払うタイミングは永久にこないかもしれません。

対象によりますが、「動いた」で進んでしまっていいものもあると思っています。私にしてもガチャのような調べ方をすることもあります。さほど重要で無いものの場合もありますが、重要なものであってもなんとかできる自信のあるもの(詳細は忘れたけれど過去に調べたことがあるものなどが該当します)はそんな切り捨て方をしていますね。無限に調べる時間なんてないので。後者は「書いている通りやってみる」と言うより「自分の記憶と符合するか」のフィルタリングがかかっていますので、本記事の「簡易的な取捨選択」のテーマからは外れますね。

本記事は読む時の話ですが、当然そのまま書く時にも転用できます。 あと、書く側だとこの辺を読むといい気はします。読んだはずなのに内容すっかり忘れてグダグダになってる私が勧めるのもどうなのよって思いつつ……読み直そう、うん。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))

参考になる技術記事の例

Javaな方々ならきっと一度は見たことのある方々のページをどうぞ。

「XXXさんの記事だから」って安心感は調べ物を効率化してくれますよね。安心できるのにも理由があるんだよなぁって思ったり。