中身はUNIXに関することというよりは、どういうコンセプトでUNIXが作られているかというのに重点がおかれているものです。コンパクトに短くまとめられた本なのですぐに読むことができました。私自身はターミナル万歳というほど使いこなしているわけでもなく、設定ファイルをviで少しいじったり、gitのコマンドうったり、シェルスクリプトで面倒な作業をやったりという感じです。プログラミングは基本IDEで行います。いくつか気になることがあったので興味を持ちました。最近の課題「どうやったらメンテしやすいプログラムがかけるのか」ここ1、2年の自分の課題として、「どうやったらメンテしやすいプログラムがかけるのか」というのがあります。以前は、1度書いたらそれでおしまいで、たぶんその後は全く見ないプログラムというのが多かったです。数年前からちょっとしたツールアプリを作る機会が増えてきました。すると、以前よりもそのアプリに機能を追加したり、コンテンツの中身を入れ替えたり、新しい環境に合わせて出てきたバグを修正するということが多くなりました。そのとき、自分の書いたプログラムと向き合う必要が出てきました。これがものすごくつらいのです!何を思ってこういう処理をしているのか?このイベントの流れってどうなっているの?などということが、すぐに理解できなかったからです。最初は、プログラムの書き方に問題があると思っていました。それはもちろんその部分もあるかと思ったのですが、そのうちこれは大きな原因ではないんだと思うようになりました。結論からいいますと、単に自分が「プログラムを読む力」が全然ないということでした。プログラムでは書く力と読む力は別のところにあるんだと思います。文法を覚えて、いくつかのデザインパターンやライブラリの使い方を覚えれば、ある程度は書くことはできます。その書いたプログラムを時間がたってから読み直すというのは、また別の力なんだなと。3日だか1週間、あるいは3ヶ月でしたっけ?それだけたったら、たとえ自分で書いたプログラムでも、それは他人の書いたプログラムになるっていう有名な話。自分としては読む力をつけることをかなり怠けていました。フリーランスでプログラムを書いているので、他の人のプログラムを読む必要があまりなかったというのが主な理由です。必要にせまられなかったというか。仕事では分業体制で行うことがあり、私がメインのプログラムを書いて、コンテンツを量産するときは、依頼主の会社さんで行うといったことはよくあります。この場合も私から誰かに渡すことはあっても、誰かからもらってそれを取り込むという機会はあまりなかったのです。いまはもっと意識的に他の人のソースを読みたいなと思っている次第です。ライブラリやら、サンプルコードやら。それと合わせて、プログラムを書くときも後からみたときにわかりやすいプログラムになるようにしようと思うようになりました。前にリーダブルコードを読んだときにも思ったのですが、難しいことはあまり良くないと思うようになりました。頭をなるべく使わないですむように、マジックナンバーは定数としてわかりやすい名前で定義しておくとか、変数、メソッド名はぱっと見ただけで何をやっているかわかるようにつけるとか、そういう一見地味な、だけれでも後からソースを見返したときに、じわじわ効果がでるようなそんなプログラムがメンテのしやすい良いプログラムがなんだと思うようになりました。話を戻して本の感想です。いくつかなるほどと思うところがありました。90パーセントの解を目指す詳しい説明は本にゆずります。興味があれば、見てみてください。この本で一番良いなと思ったところは、「現実的な解を良し」としていたからです。机上の空論ではなく、あくまでも現実に合わせた答えを示しているところ。LINEスタンプ作りました!毎日使える。日記このブログについてこんにちは。フロントエンドエンジニアです。自作のiPhoneアプリを作っています。