ロブ・パイク氏の「プログラミング5カ条」

1989年にロブ・パイク氏によって提唱されたと言われているこの5カ条、定期的に盛り上がるようだ。

Rob Pike's 5 Rules of Programming
http://users.ece.utexas.edu/~adnan/pike.html

https://news.ycombinator.com/item?id=24135189
https://news.ycombinator.com/item?id=15776124

「Goの父」ロブ・パイクの「プログラミング5カ条」、ネット上で話題に

ルール1：プログラムのどこで処理時間がかかるかはわからない。ボトルネックは意外な場所で発生するので、ボトルネックがどこにあるかを証明するまでは、臆測で速度の改善に取り組まないこと。

ルール2：処理速度を測定すること。測定して、コードのある部分が他の部分を圧倒しない限り、速度の調整をしてはいけない。

ルール3：派手なアルゴリズムは、入力値のnが小さいと処理が遅い。そして通常、nは小さい。派手なアルゴリズムは大きな定数を持っている。nが頻繁に大きくなることがないなら、派手なアルゴリズムは使わないようにすること。(nが大きくなっても、まずルール2を適用すること)

ルール4：派手なアルゴリズムは単純なアルゴリズムに比べてバグが多く、実装も大変なので、シンプルなアルゴリズムとシンプルなデータ構造を使うようにすること。

ルール5：データが支配する。正しいデータ構造を選択し、うまく整理していれば、アルゴリズムはほとんどの場合、自明のものになる。プログラミングの中心はアルゴリズムではなくデータ構造。

日本語訳よりも冒頭の原文を参照した方がよいだろう。

やらかした経験がある人ほど、心が痛くなる5カ条だが、少し考察してみる。5カ条の中でも俺は特に、ソフトウェアエンジニアリングはルール５ゲーだと思っている。

ルール１、ルール２に関しては、以前書いた「負荷試験でエンジニアの実力大体わかる説」に通ずるものを勝手に感じた。無論、彼が指摘している処理速度というのはソフトウェア工学的な側面が色濃いはずで、たかがウェブの負荷試験程度と混同してはならないのだが。

また、ルール３、ルール４に関してはKISSの原則は言うまでもないと思うが、逆に言えば、入力値nが頻繁に大きくなることがあれば派手なアルゴリズム（Fancy algorithms）の採用を検討してもよいということだ。ただし、入力値nが頻繁に大きくなるような場合、大抵はデータの構造化に失敗している。それがルール５で指摘されている。値nが大きくなるのは問題ないが、入力値nが大きくなることが問題なのだ。そして、入力値nを小さくするための努力をプログラミング側でやってはいけない。データ側でやるべきなのだ。

事業やビジネスのスキーマを上手にモデリングできる人はまだまだ少ない。じゃあスキーマレスでええやんけ、とNoSQLになんでも突っ込む酷い設計を数多く見てきた。一方で、職人技のようなデータモデリングを目の当たりにして震えあがったこともある。こういうのは本やwebを探してもなかなか身につくものではない。感覚的なもので、アウトプットが難しいのだと思う。自転車の乗り方を本で読んでも、すぐには乗れないじゃろ？

Data dominates. 

なんかカッケーからドヤ顔で使っていこう。
現場からは以上です。