Irohabook
プログラミング プログラミング哲学

「UNIXという考え方」から再考するソフトウェア設計とプログラミングの哲学

広告

「UNIXという考え方」(Mike Gancarz著)はUNIXの設計思想を説明した名著であり、コンピューター、ソフトウェア、プログラミングに携わる人にはぜひ読んでほしい本だ。

ここでは本そのものの内容でなく、さらに一歩踏みこんで未来に通用するソフトウェアとプログラミングの思想について考える。まずは私たちが必ず守らないといけないルールをあげる。

ルールを定める

すべての技術者が守らないといけないルールは「ルールを定める」ことだ。具体的には設計ルールやコード規約を指す。メンバ変数にmという接頭辞を入れるというルールは最悪のルールだが、ルールをまったく定めないよりはましである。

コード規約をどうでもいいと思っているエンジニアがプロジェクトを率いる責任者だったら、そのプロジェクトは崩壊するように運命づけられている。ソフトウェアという世界から追放されるべき人は、ルールを軽視する人だ。

「だ」「である」と「です」「ます」が混ざっているノンフィクションのドキュメンタリーはない。出版社の編集者は独自のルールを定め、違反している部分は訂正する。ルールが定まっていない文を読者が信用しないことを誰よりもわかっているのは、編集者であり作家である。しかしソフトウェアにいる一部の人たちは、自分たちが書いているものを文と思っていないようだ。

守らないといけない思想

データ指向

私たちはデータ(モデル)の設計を固めないといけない。つまるところデータがすべてだ。データが他のすべてを決定する。データベースを丁寧に設計しない限り、そのプロジェクトは崩壊が待っている。

モデルを1変えれば、ビューは10変わる。モデルを途中で変更することは、それ以外のコードのいくらかを消して、その何倍のコードも追記することを意味する。

反独自技術症候群

続いて「UNIXという考え方」が強調している「てこの原理」を少し説明しよう。fという関数を定義し、gとhでfを使ったとする。gでfのコードを書き、hでfのコードを書くよりも、手間が減ったわけだ。

関数やクラスの定義は、使われる分だけ全体的な効率を上げる。

関数やクラスを寄せ集めたものがライブラリだ。WordPressでブログを作った経験のある人は、最初からWordPressそのものを自力で開発しようと思わかなかったと思う。すでにあるものは使うべきだからだ。反対に、すでにあるものをもう一度作ること、作りたいと思うことを独自技術症候群という。

しかしソフトウェア開発では独自技術症候群がよく起きる。独自技術症候群は会社の時間と労力を奪う、ソフトウェア業界で悪名高い罠であるが、なぜかエンジニアはこの癖を持つようになる。

「UNIXという考え方」では独自技術症候群をぶった切りながら、他人の作ったものを再利用して「てこの原理」でソフトウェアを付加価値を上げることを推奨している。

シンプルな設計

「UNIXという考え方」で書かれ、しかもUNIX哲学でも掟とされている。

Make each program do one thing well.
Basics of the Unix Philosophy (Copyright © 2003 Eric S. Raymond)より引用

「一つのことをうまくやるプログラムを書け」というルールだ。「UNIXという考え方」はUNIXのさまざまな例をあげて、この本質を説明している。現代のソフトウェアに照らしていえば、次のサブルールが用意されるだろう。

などなど。一つの関数、一つのクラスで巨大なものを作ってはいけない。大きなソフトを作るときは、小さなものをたくさん作ってうまくつなぐことが大切だ。

プログラミングの哲学

「UNIXという考え方」から察したプログラミングの哲学を紹介する。「UNIXという考え方」はあくまでもUNIXに絞っているので、今回は現代流にアレンジしたものを考える。

開発は早ければ早いほどいい。遅いとマインドが下がり、当初あったはずのエネルギーは奪われていく。実装が遅れると、同僚や起業家仲間との非生産的な会話を優先するようになる。

スネークケースを採用する。これは「UNIXという考え方」も主張しているが、大文字は見にくい。キャメルケースにすると変数や関数の名前が冗長になってしまう

階層的につくる。あらゆるものは階層的だが、階層は順番と秩序をつくる。

(追記)

広告

コンピューター コンピューター
プログラミング プログラミング
数学 数学
英語 英語
国語 国語
理科 理科
社会 社会