いや、よくない。
はじめに
こんにちは。
この記事は、グロースエクスパートナーズ Advent Calendar 2022 13日目の記事です。
私はQiitaに書かれるポエムが大好きです。
知識だけではなく、その人の思想に触れることができるから。
なので私もこれを機会にポエムを詠もうと思う。
プログラミングに挫折した人が、「おまじない」のために分からなくなったと書いていたのを某所で見たことがあります。
これは少し残念だなと思ったので、それをネタにします。
ソフトウェア技術者をやるのであれば、いつまでも付き合うことになる「おまじない」のお話。
「おまじない」の定義
この記事ではこう定義する。
「プログラムにおいて、理解が足りずに使っているモノ」
はじめての「おまじない」
Hello, world
多分世の中で一番有名な「おまじない」は、
C言語の初学者に書かせることの多いプログラム"Hello, world"の#include <stdio.h>ではないだろうか。
#include <stdio.h>
int main (void)
{
printf("Hello, world\n");
return 0;
}
#include <stdio.h>の説明に困った教え手が、「おまじない」と表現したりする。
そして、しばしばそれが批判の対象となる。
「おまじない」以外、どう教えるか
その説明で大丈夫か
#include <stdio.h>は、標準入出力のライブラリを読み込むための命令です
みたいな説明を読んだことがある。
この説明は大丈夫だろうか・・・。
こういう理解をすると、いつか「#include <math.h>を書いたのにsqrt関数が使えない！」と泣くことになるだろう。
参考記事：ライブラリのリンクを忘れずに
ちなみに私も若いころこれで泣いたことがある。リンクを知らなかったんだな。
私なら・・・
じゃあ私ならどう説明するかと言うと、
「stdio.hという標準入出力用のヘッダーファイルを組み込んでいるんだよ。printfは標準入出力の関数だから必要なんだ」くらいなものだろうか。
これもどうだろう。
stdio.hって何？ヘッダーファイル？なぜ必要なの？
ええとstdio.hにはprintfのプロトタイプ宣言が書いてあってな。
プロトタイプ宣言がなぜ必要かというと……さて困った。
まだ関数も引数も戻り値も教えていないのにどう説明したもんか。
聖書の記載
それではC言語の聖書、プログラミング言語C(K&R)ではどう解説されているか。
このプログラムの最初の行
#include <stdio.h>
は,標準入出力ライブラリについての情報を含めるべきことを,コンパイラに対して指示するものである。
この標準ライブラリについては,第7章および付録Bで説明する。
流石K&R！なるほど！
・・・これは初学者に分かるだろうか？恐らく難しい。
それなら「おまじない」の方がマシでは？
#include <stdio.h>という「おまじない」を、正しく説明するには"Hello, world."段階では無理だ。
教える側として、初学者に分からないと認識させるか、
正しくない(足りない)知識を与え、さも分かったつもりにさせるかの究極の2択なのだ。
ならばまずは素直に「今は分からない」と認識させる方が、
正しく誠実であり初学者のためにならないだろうか。
教えられる段階に達したら教えればいいさ。
「おまじない」でもいいじゃないか。今はまだ。
君はプログラマ
「今は分からない」だけでは、挫折の原因になるだろう。
自分はダメだ。出来ていない。これでは先に進めないと。
いやいや。みんなそんなもんだよ。今はそれで十分なんだ。やれることはやれるし先にも進める。
#include <stdio.h>が分からなくても、
"Hello, world." を書き換えて"Goodbye, me."と表示させることは出来るだろう。
これで君はプログラマーだ。
プログラムを書くことで、自分が意図した通りのことをコンピュータに実行させたのだから。
こんにちは世界。さようなら私。うん。ポエムっぽいな。
新しい世界に飛び立ち古い自分に決別するみたいな！
私がオッサンになっても
私はプログラマを職業として今ではオッサンとなったが、
今でも新しいことをやるときは、まず動かすことから始める。
丸写しでも「おまじない」だらけの状態でも、
まず動いたことを喜び、少し改造して変化を楽しみ、分からないことを少しずつ紐解き理解していく。
初めから全部「おまじない」を解決してから進んだりはしない。
だって動かした方が楽しいじゃないか。
「おまじない」があってもプログラムは楽しめる
それで挫折してしまうのは勿体ない。
「おまじない」でいいわけないだろ
「おまじない」でいいじゃんと書いたが、職業としてプログラマやるなら話は違う。
職場で自分が書いたソースコードの意図を問われたとき、「この文はおまじないです」と話したら、怒られるか落胆されるかだろう。
それは自分が書いたプログラムを理解していないことを意味するからだ。
理解していないのだから、プログラムがどう動くか予想が出来ず、
それによって不都合な動作を生み出す。バグだ。
だからプロのソフトウェア技術者であるなら、「おまじない」は全て無くすべきである。
・・・あるべき論では。
それでも「おまじない」は存在します。ほらあなたの後ろにも
「おまじない」はどうすればすべて無くせるのだろうか。
書籍を読み漁り、公式のリファレンスマニュアルを全て理解するでよいだろうか。
こんなものに遭遇した。
Undocumented Android 7 BLE Behavior Changes
内容を簡単に書くと、あるOSの機能を呼び出した際、とある条件でOSが動作を失敗させエラーも返さないという「仕様」だ。
呼び出し側からすると、失敗したことすらも分からずリトライ等の対応もとれない。
そしてその挙動は文書化もされていない。
(ので文書化すべき！というのが上記のサイトの主張である)
残念ながら私は知らなかった。
つまりOSの動作への理解が及んでおらず「おまじない」が残っていたことになる。
そしてそれはバグとなった。
こんな挙動をするOSが悪い。文書化されていないのも悪い。そう言いたくもなる。
そうであっても客からしたらソフトウェアが万全に動いていないのだ。
我々プロがフォローし解決しなくてはならない。
他に誰がやるのさ。
しかし、そんな「おまじない」を無くすことができるのだろうか。
上記の例を見ても、公式文書を隅から隅まで読んで完全に理解したとしても、
「おまじない」は無くなったりしない。
関連するすべてのソースコードを読んで理解するか。
そんなことは現実的に出来やしない。
「出来やしない」ことを、まずは認識しなくてはならない。
そこを認識すらできていないというのは危険だ。
そのリスクに対処できないから。
じゃあ「おまじない」をどうすればいいのさ
どうにもならない。
地道に調べ、知恵を振り絞って設計し、慎重に実装し、テストを重ねて。
それでも万全ではないことを理解しバグに備える。
バグの流出が阻止できなくとも、せめて発生した時に解析出来る方法は用意すべきだ。
そういう当たり前のことを愚直に積み重ねるしかない。
それも限られた時間で。
ソフトウェア開発は困難だ。
「おまじない」でもいいじゃないか。いや、よくない。だが・・・
初学者からプロまで「おまじない」とは付き合うことになる。付き合い方を変えながら。
初めは「おまじない」でもいい。
次に「おまじない」を無くしていくことを目指す。
それでも「おまじない」は無くならないことを認識する。
おわりに
「おまじない」を漢字で「御呪い」と書くと、なんかよからぬことに見えてきてしまいますが、
多くの人がおこなう「おまじない」は、ちょっとした「祈り」や「願い」と思います。
普段信仰心の薄い私だけれども、
クリスマスや正月があるこの季節は、願いが叶ったり、
祈りが通じたりするんじゃないかとふんわりと感じてしまう。
やるべきことをやって、それでも最後に残った「おまじない」が良い結果をもたらしますように。