「UNIXという考え方」を読んでプログラミング時に参考になった箇所

「UNIXという考え方」を読んで参考になった箇所（特にコードを書く上で）を紹介する。

スモールイズビューティフル

プログラムを書くときは小さく書き始め、それを小さいままで保つという考え方。
例えばファイルAとファイルBにコピーするというプログラムを書く場合、以下の手順が必要になる。

1. ユーザーにコピーする元のファイル名を訪ねる
2. ファイルがあるかどうかをチェックする
3. ファイルがなければ、それをユーザーに通知する
4. ユーザーにコピー先のファイル名を尋ねる
5. ファイルがあるかどうかをチェックする
6. ファイルがあれば、ユーザーにそれを上書きするかどうか尋ねる
7. 元ファイルを開く
8. 元ファイルが空だったらそれをユーザー通知し、プログラムを終了する
9. コピー先のファイルを開く
10. データをコピー元のファイルからコピー先のファイルにコピーする
11. 元ファイルを閉じる
12. コピー先のファイルを閉じる

この手順を見ると実際にコピーを行っているのは手順10になり、他の手順はファイルの存在チェックなどの補助的な役割になる。
実際にプログラムを書くときはこれらの手順1つずつをメソッドとして切り出すのが望ましい。例えば手順2のファイルの存在チェックや手順7のファイルを開く動作は他にも流用する可能性が大いに考えられると思う。
自分はこの手順1～12をまとめて1つのメソッドとして作ってしまい、過去に保守が苦しくなった経験がある。。
手順12だけが不要な別処理が必要になった場合に手順1～11をまた別メソッドとして書き、似たような記述があちこちにある状態を作ってしまった。
この経験からもプログラムは小さく書き、そのプログラムを組み合わせるのが最も良いと実感した。

効率より移植性

効率と移植性（例えばコードが簡潔だと移植性が高い）は多くの場合、トレードオフの関係にある。
優先するのは移植性と著者は断言している。
移植性を優先する理由はハードウェアにある。ハードウェアは年々性能が高くなっており、ソフトウェア側で処理速度をわずかに速くしようとする努力以上にハードウェアの進歩によって処理は速くなる。
似たような話で「達人に学ぶdb設計徹底指南書」にも正規化とクエリの実行速度の関係を思い出した。正規化をするほどクエリは遅くなるがこの本でも正規化を
できるところまで行うことを主張していた。
プログラムにしろDBにしろやはり保守性（移植性）を最重要するべきということを学んだ。

独自技術症候群を避ける

プログラマは自分にしか書けない芸術的な難易度の高いプログラムを書くことに自分の価値を見出すべきではないという考えを著者は主張している。
自分も難しいプログラムを書いたときに達成感を得てしまうことがあるので、ハッとさせられる内容だった。
個人の経験としても頭を悩ませながら書いたプログラムは、他人からすると読みにくいのはもちろん未来の自分もすぐに理解できず困ることが多々ある。
今後、独自技術に価値を見出さずに誰でもすぐに読めるコードを書くことを一層意識しようと思う。そのために上記でも述べた「スモールイズビューティフル」などを意識する必要がある。

最後に

この本は他にもそもそもUNIXは歴史上どのような使われ方をしてきたか、ここでは紹介していないUNIXの思想、他のOSとの比較などが書かれているため、非常に面白くためになりエンジニアとして知っていて損はない内容である。