ライブラリ志向とは

「ライブラリ志向」

ライブラリ志向とは、現在、世の中にあるライブラリの不満点を踏まえて、新しく作った（又は昔からある）プログラミングの考え方です。

ライブラリというのは、ファンタジー世界で例えると、魔法使いの一団が共通で使う「魔法書」のようなもの。

魔法書に書かれている「呪文（関数名）」を唱えれば、それに応じた処理が実行されます。

良い魔法書とは、「手続きが簡単で、短い呪文で魔法を使える」もの。
面倒な魔法書とは、「手続きが複雑で、長く呪文を唱えなければならない」もの。

もし「良い魔法書」を持った一団と、「面倒な魔法書」を持った一団が戦った場合、どちらが勝つかは言うまでもないですね。

同じようにプログラムの世界でも、「良いライブラリ」を使ったプロジェクトチームの方が良い成果（工数＆人数＆バグを少なくできる）を出すことができます。

「ライブラリ志向」とは、「プログラマが使い易いライブラリを作る」ということを最優先にする考え方です。
凄く当たり前のことですが、多くのライブラリでそれができていません。

尚、ライブラリ志向は、オブジェクト指向等、他の哲学と対立するものではなく、
まずは「使い易いライブラリ」を作ることを優先し、その後は、プロジェクトリーダーの思想に合わせて、プログラミングしていけば良いと私は考えています。

ライブラリを作る立場にある人は、オブジェクト指向の圧力に屈せず、是非この「ライブラリ志向」を導入して頂きたいです。

※関連記事はこちら↓（ゲームプログラミングで目指すべき方向性）

　http://giw.cocolog-nifty.com/blog/2017/01/post-78ce.html

アルゴリズム（プログラミング技術）の歴史

＜メモ＞

・昔は、プログラムのアルゴリズム（目的を達成する為の設計）は、1人又は数人の職人がベストな方法を編み出して作っていた。

・時代が進むと、数十人規模のプロジェクトが必要になってきて、全員が職人ではなく、実力のある人と、そうでない人で、差がでるようになった。

・実力差を埋めつつ、途中で誰かが抜けてしまっても（実力者が会社を辞めても）、プロジェクトが動けるような仕組みが求められた。

・そこで編み出されたのが「オブジェクト指向」。１つのルールで統一し、特殊な処理を排除することで、理想としては「誰が抜けてもプロジェクトを存続できる」アルゴリズムが生まれた。

・実際にその理想が100％達成されているわけではないが、高・中・低のプログラムが入り混じった状態よりは遙かに良い、ということで広まっていった。

・そのアルゴリズムは、難易度的には「中」のプログラムである必要がある。
　新人は「中」を目指して精進し、実力者は「中」に合わせたプログラム（「中」としての完成度を高める）を書く。

・結果として、「高」である職人的なプログラミング技術は失われていった。

・現在の問題点は、実力のある人が「中」を極めようとするあまり、「高」のプログラムとは別の分かり難さが発生してしまっていること。

・「高」をアセンブラ等を使って極めたソースを「極高」だとすると、実力者がオブジェクト指向の範囲内で極めたソースは「極中」と言える。

・「中」を基本としてる人から見た分かり難さで言えば、「極高＞極中＞低＞高＞中」という感じかも？

・この順序が正しいとすると、「極中」よりも「高」の方が分かりやすいということになる。

ゲームプログラミングで目指す方向性

===================================================================

「ゲームライブラリ制作で目指べき方向性」

１．ライブラリ制作者は、ライブラリ使用者が使い易い構造を目指す。
　※”使い易い”とは、「見やすく、バグが出にくく、覚えることが少なく、少ない工数」で組めること。

２．１を可能な限り達成しつつ、ライブラリの中身も、なるべく簡素にする。
　※簡素な方が、作成時の工数が減るだけでなく、バグ修正や拡張も行い易い。

３．１と２を可能な限り達成しつつ、コンピュータが効率良く動くようにする。
　※目的に合わせて、実行速度＆消費メモリ＆消費電力等をより良い状態にする。

「個人のゲームプログラミングで目指べき方向性」

１．基本、好きなように書けば良い。
　※楽しいことが重要。楽しくなければ続かない。

２．綺麗に書くことに拘り過ぎず、自身の精神的ストレスも軽減すること。
　※疲れや眠気のある時にプログラムを組むとバグが生まれやすい。

「複数人でのゲームプログラミングで目指べき方向性」（仮版）

１．睡眠不足は最大の敵。
　※バグの元であり、喧嘩の元にもなる。

２．共通ライブラリは、「ゲームライブラリ制作で目指べき方向性」を踏まえて作る。
　※また、チームからの要望を踏まえて、より良い使い心地を目指すこと。

３．他人と連携する箇所のコメント説明や、意思疎通を怠らないこと。
　※最もバグが発生し易いのは、他人のプログラムとの連携部分である為。

４．コーディングルールは、緩めに設定すること。
　※各個人のストレス軽減と、厳しくすることによる不和を避ける為。

５．どういう思想で作るかは、プロジェクトに合わせて臨機応変に決める。
　※最適な作り方はプロジェクト毎に異なる為、１つの思想に拘り過ぎると逆に効率が悪くなる。

===================================================================

■余談

人は、自然の仕組みを理解し、効率よく利用しながら生きています。

プログラマも同じで、自然＝コンピュータの仕組みを理解し、効率よく利用することがプログラマの目指すべき姿ではないでしょうか。

自然を無視し、「コンピュータを奴隷のように働かせるプログラム」ではなく、
自然を重視し、「コンピュータと人間を上手く繋いだプログラム」こそ最良だと思います。

また、そこから生み出された作品も、最終的な使用者（ユーザー）にとって、より良いものとなるでしょう。

StudioGIW（スタジオギウ）/ 祇羽（ぎう）
http://www.studiogiw.com/

月間よく読まれた記事でゲーム部門１位

ZombieVital2が月間よく読まれた記事でゲーム部門１位になりました！

http://www.vector.co.jp/magazine/softnews/frequently/#Q7y5CzY.twitter_tweet_count_m

有難うございます＾＾