スキップしてメイン コンテンツに移動

書評 -「UNIXという考え方」について - その2

 

前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。

3章

最初から上手くやろうとするより、最初は上手く行かないことを前提に考える

3章では最初の仕様に変更が無いことは稀で、状況に応じて仕様の変更を加えていかないといけないこと、そしてその為には早めの試作を行い、リスクを軽減する必要性について書かれている。

第一のシステムから第三のシステムというものまで存在するが、第三のシステムの様な機能と性能が最適化されたエレガントなシステムを最初から作れる訳ではない。

第一、第二、第三と順に過程を経ることで到達するものであり、第三のシステムから見れば第一のシステムやましてや第二のシステムは劣る様にも感じられるが、それは後から見れば結果そうなのであって、その時その時ではその各々のシステムが求められている。

章の最初の方にも書かれていたが、ソフトウェア技術者を始めとした常にスキルのアップデートが必要な職業の人々はソフトウェアと同じで、最初から完璧に出来る訳ではない。

長い時間をかけてスキルを洗練させていくものであって、試行錯誤を行いながら学び続ける必要がある。

このことは様々な学習や他のスキル習得にも当てはまるなと。自身も最初から全てを完璧に習得しようとして途中で躓いた経験が何度あったことか。そもそも完璧に習得なんて考え自体が傲慢だし、あり得ないことなのだが。


「UNIXという考え方」の書籍の購入はこちらからどうぞ。


以上、4章へつづく。

コメント

このブログの人気の投稿

書評 -「UNIXという考え方」について - その3

    前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 4章 ソフトウェアが短命で終わるか否かは移植性を重視して作れるかどうかにかかっている 4章では効率より移植性が重要であり、例え効率を求めたとしてもそれは間もなく新しく来るスペックのものが来た時に残念ながらその努力はあまり意味を成さないものとなってしまうことがAtariの例も挙げられながら書かれている。 これはデータでも同様のことが言える。 取り巻く環境が変化することを前提にソフトウェアを書いていくこと。 その為繰り返し呼ばれている様な箇所以外で最適化にリソースを割き過ぎると環境が変化した時に対応することが困難になる。 その為にもまずは移植性を重視する必要がある。 環境が変化して、新しいハードウェアが登場しそこに移植さえ上手く出来れば前の世代のハードウェアで懸命に最適化して得られた効果よりももっと大きな効果を得られる。 昨今、もはやデファクトになり移植性の為にも無くてはならない存在になっているDocker。 従来以上に開発からサービスのリリースまでのスピーディーさが求められてる世の中になっている様にも感じるし、その為の環境もかつてよりかなり整備されてきている。 こういった環境の中で、効率性を上げるというよりかは、移植性を上げる方が将来的な環境の変化のことを考えると喫緊の課題と言える。 そもそも効率化や最適化を余りにも重視したところで、環境が変わって動かなくなれば元も子もないのだから。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、5章へつづく。

書評 -「UNIXという考え方」について - その5

       前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 6章 過度の対話的インタフェースを避ける 6章では主に拘束的なインターフェース、プログラム、コマンドパーサーを避けなければならない理由について書かれている。 ソフトウェア設計者にとってのジレンマ 小さなプログラムやモジュールを数多く持つことで環境への適応能力は最大となるが、取り扱いも煩雑になる。 UNIXはユーザとモジュール間に広がる溝を少しずつ小さな塊または層にして減らしていこうとすることで解決を図る。 拘束的ユーザーインターフェース このアプローチの欠点は多くのアプリケーションが稼働するシステムだったり、あるコマンドを実行していてもそれを終わらせるまでは他のことが出来ない。 何故、避ける必要があるの? UNIXユーザーにとってコマンド同士を対話させる必要がある。UNIX環境ではどのコマンドも単独では存在できない。様々な時点でコマンド同士が対話する前提だから。 拘束的プログラム ユーザーを人間と想定している為、人間の限界によって動作を制限されるようなシステムは、潜在能力をフルに発揮できない。 何故、避ける必要があるの? 複雑になった拘束的プログラムは多機能主義と相まってますます大量のシステムリソースを必要とする。 ユーザーが人間であることを想定している為、他のプログラムとのインターフェースは苦手。 拘束的コマンドパーサー あらゆる可能性に対処しようとしてコマンドパーサーが肥大化し複雑になる。UNIXプログラマはユーザーインターフェースへの対処を避けて通る。典型的なUNIXアプリケーションにはコマンドパーサーがない。 その代わり、コマンド起動時にユーザがコマンドラインに動作パラメータも入力することが前提になっている。 何故、避ける必要があるの? ソフトウェアのテコの効果を利用出来ず、他のプログラムとの対話を妨げるので、その効果をコンピュータ世界に広めることが出来ない。その為やがて取り残されて魅力を失っていく。 すべてのプログラムをフィルタにする 世界は、人間が作り出したデータで溢れている。コンピュータが発明されていなくても、データは存在している。 コンピュータは、データの収集とフィルタリングを効率よく行えるよう...

書評 -「UNIXという考え方」について - その4

      前回に引き続きMike Gancarz著の「UNIXという考え方」について、書評を書いていければと思う。 5章 ソフトウェアのテコを有効に活用する 5章では主にソフトウェアのテコとシェルスクリプトのメリットについて書かれている。 よいプログラマはよいコードを書く。偉大なプログラマはよいコードを借りてくる 自分の仕事に他人の成果を取り込むことで、先人の努力を活かし、コードの有用性を一段と高めることができる。 独自技術症候群を避ける 既存のアプリケーションをゼロから設計し直すことは模倣であっても創造とは言わない。最も成功する会社は、他からソフトウェアを「借用」し、独自拡張を行う会社である。 コードを他社がテコとして使うのを認める ソフトウェアの寿命をコントロールしようとしても、プログラム開発への投資を一時的に保護することができるだけで、ソフトウェアそのものを保護することはできない。 すべてを自動化する コンピュータにできることを人間が手作業で行うのは時間の無駄。 シェルスクリプトのメリット テコの効果と移植性を高めるシェルスクリプトには何十ページ、数百コマンドラインに渡り、そこから呼ばれる各コマンドの背後にあるC言語のコードはものすごい量となる。これこそがテコの効果である。 時間が節約になる コンパイル段階を省略できるので、開発作業に集中できる。 Cより移植性が高い あるUNIXシステムで動作するスクリプトはほとんど修正なしで動作する。コンパイルはもちろん、どのような実行のための変換も不要。 C言語で書き直すという誘惑に負けない シェルスクリプトを次の年のマシンで使えば、もっと速く実行できるようになる。非常に移植性が高いのが普通だから、次の年のマシンに移植するのに特別な作業はほとんど何もない。 「UNIXという考え方」の書籍の購入は こちら からどうぞ。 以上、6章へつづく。