初学者の頃、ググった記事に載っているコードが「お、思っていたことが出来そう！」と嬉々としてコピペ、使おうとしたら動かない…こんな経験はないでしょうか。
「どうせ記事にするならちゃんと動くようにしてくれよ！」と、口にこそ出しませんがそう思っていたころ、
「わざと完全動作するコードは提供せず、必要と思った部分だけ抜粋するべき」
え、わざとイジワルする人もいるの？？ じゃあ記事にしなきゃいいじゃん！
当時の私には理解できませんでした。わからんやつはわからんのが悪いんだよ。記事の向こうでニタニタと、笑われている気がしたものです。
でも、そもそも記事に完全性を求めるのは正しいのでしょうか。
こうして記事を書くようになると、「気持ちはわかる。。でも、それは正しいことではないんだ」と思うようになりました。
校正には時間がかかる
ブログはほとんどが個人で管理しています。
そして、記事を書くには当然時間がかかります。内容によりますが、１つに何時間もかかってしまう事も。
その上で校正もするとなると、更に時間を取られてしまいます。
（私は一応記事を作ってから、読み直すようにしていますが平均１割は追加で作業時間がかかります。大幅に直す場合は５割以上になることも）
これを年単位で続けると結構な時間校正に費やしてしまいます。
おそらく訪問者は何百とある記事の１つにしか興味はなく、「なんでその１つが間違えてるんだ」と思うわけですが、１つ間違いを修正していたのであれば、かかった時間が何百倍にも膨れ上がるんですよね…。
それでもなるべく、記事の間違いは防ぎたい、と思ってイマス。
時間をかけたところで、100% 完璧になる保証はない
プログラマーが自分でチェックする場合、どうしても「これは正しい」という思い込みバイアスがかかっているので、間違いに気づきにくいです。それは記事も同じこと。
私も、ちゃんと見直しているはずの自分の記事を後で見返して「………」と沈黙してしまうミスを見つけることもしばしば。
小説でも、校正は別の人が行います。ゲームもデバッガー（最近はQAチェックと言うことが多い）に間違いを指摘してもらいます。
もちろん、それでもミスは100% なくなりませんし「ちゃんとデバッグチェックしてるんですか？？」と言われてしまうわけです。ましてや個人が、100% ミスを防ぐのはほぼ不可能でしょう。
このミスも「作者野球知らなさすぎｗｗｗ」というのはちょっと短絡的で、膨大な徹夜の末朦朧としながら書いてたらやっちまった…のかもしれない。
出版物なので校正も入っているはずですが、その校正者だって見逃しているのです。
苦労なくして、身につかない
３番目のこれが、一番最初に「イジワル」と評した部分の本当の意味だったんだと思います。
ソースコードで本当に必要な部分だけ抜粋する。
この「必要な部分だけ」というのは見る人のレベルによって変わります。例えばこんな unity のコードで、こんな抜粋。
button.onClick.AddListener( callPush );
void callPush()
{
Debug.Log("push button.");
}
unity でまがりなりにもゲームを作り上げた事があればこのコードだけで何をいってるかわかるでしょう。でも、初学者なら「button ってどこから来たの？」「Monobehaviour どこ？？」となり、ここで理解がストップする。
…と、ここでストップせずに、「じゃあ onClick.AddListener でググってみよう！」と自ら先に進める人でなければ、今後もプログラマーとしてやってくのは厳しいんじゃないの？ というのが、
「わざと完全動作するコードは提供せず、必要と思った部分だけ抜粋するべき」
の真意だったのだと思います。
これをもし、完全に動くコードで提供した場合エラーもなく動作しますが、
public class Test : MonoBehaviour
{
[SerializeField]
UnityEngine.UI.Button button;
private void Start()
{
button.onClick.AddListener( callPush );
}
void callPush()
{
Debug.Log("push button.");
}
}
- SerializeField ってなんなのか
- using UnityEngine.UI という記法
- button.onClick.AddListener( () => Debug.Log("push button.") ); とも書ける
こういった勉強の機会を奪っている可能性もある、という事ですね。
ただ、苦労させすぎるのも問題
ただ、「全部自分でやらせるのが一番いい経験になる」わけではないとも思います。
わからないストレスが強すぎれば結局新人プログラマーの芽を潰すだけかもしれないし、プログラム言語（やフレームワーク）の流行りなんて２～３年で変化するのですから、「必要と思った部分」が独りよがりでないか、十分考えたいですね。
熟考しても、人によって差が出てしまうと思いますが。
10 年 Laravel やったら１人前、なんてことしてたらそのプログラマーは 10 年後使えないと言われて職を失うでしょう。
ブログの記事が玉石混交なのは、一人だけの経験・意図で紡がれるもののため。
ちょうど同じステージにいる人にとっては素晴らしい記事になりますし、及ばない人にとっては役に立たない事も多いでしょう。
それでも私は様々な記事によって助けられましたし、これからも助けられると思います。
私の記事も、知らない誰かにとって役立つ事を願っています。
