きのこ本 感想 Part2

きのこ本

プログラマが知るべき97のこと

の感想です。

おそらく前の記事で書いていなかったことですが、この記事では一つの記事に3つのエッセイの感想を書いていく形にするつもりです。

単純にキリがいいのと、一回の記事の量としてそのくらいがちょうどいい、というのが理由です。

それでは、大したことを学んできたわけではない“非”情報系の学生によるきのこ本の感想文です。

04 コーディング規約を自動化する (フィリップ・ヴァン・ラーネン, Filip van Laenen)

コーディング規約というのは特にプロジェクトなどで言うと、重要ですよね。私みたいに個人でコードを書いているだけだった場合にはそれほど気にすることもなく、自分の中で考えているオレオレコーディング規約みたいなものに従っていればそれほど困ることはないので、私はあまり意識はしたことがありません。

もちろん、重要性については理解していますし、オレオレコーディング規約とはいえ、ある程度自分の中で決めたコーディング規約は守るようにしています。

しかしながら、プロジェクトで他の人と一つのプロダクトのためのコードを書いているときはそれではダメで、しっかりきめられたコーディング規約の下で作業するべきでしょう。

さて、そこでこのエッセイになるわけですが、このエッセイは「コーディング規約を決めたから、みんながそれを守って、それにしっかり従ったコードを書いてくれることはまずない」と最初に言っています。

コーディング規約は確かにうっかりするとすぐに違った方向に走っていきやすく、また勘違いと言ったこともあり得なくはないと思います。それ以上に守る気がない、守っていては作業が間に合わないなどの理由で守られないこともあるのでしょう。

そこで、規約を決めるだけでなく、「コーディング規約を自動的、強制的に守るような状況、環境を作る」ことが重要だと述べています。

このあたりは私がプロジェクトに関わるようなコードを書いたことがないので、全く知らない領域ですが、確かに自動的に間違ったコーディング規約などを修正、もしくは修正すべき個所のあるコードを通知するというのは、実際のプロダクトコードでのコーディング規約がしっかりと守られる可能性が高くなり、よい解決法だと思います。

このあたりは個人でプログラミングを行う場合でも、ある程度の規模のコードを書く場合には実行するべきかもしれませんね。正直、静的なコード解析ツールやテストカバレッジはそういう理由でなくてもやるべきだと思います。

…やらないと。

05 美はシンプルさに宿る (ヨルン・オルムハイム, Jorn Olmheim)

む、著者の方の名前が、実際の文字が表記できないですね… ( "O"の部分は文字が違いますが、探せなのと見つかったとしても実際にHTMLでちゃんと表示できるかわからないので"O"としておきます。著者さん、ｺﾞﾒﾝﾅｻｲ。 )

さて、タイトルは「美はシンプルさに宿る」ですが、「美」はもちろんですが、「シンプル」っていうのも意外と難しい概念だと思いますね。

どの程度だと「シンプル」なのか、これが問題だと思います。

私の主観でいうと、「単一の責任に分離されている」ということだと思います。( 奇しくも、エッセイの著者とおなじ意見ですね(ぇ )

コードを見たときに、一体何をしているのかが一目でわかるコードがあります。
そう言ったコードを見たときに私は美しいと感じるのですが、それはどのような場合かを突き詰めていくと、一つの関数、一つのクラスに明確な単一の責任を持たせている場合です。( さらに関数名やクラス名だけでその責任が何かが分かるとなお素晴らしいです。 )

こうなっていると細部の詳細な部分を読むことなく、大雑把ではありますが何をしているプログラムなのか一目瞭然で理解できます。このようなコードが書けるというのは素晴らしいことだと思いますし、一種の芸術的要素 ( プログラマのセンス ) も感じさせます。

オープンソースのコードの中にもそう言ったコードがあったりします。なので、そういうコードを読んでみることをお勧めします。

なりたいですね、そんなコードを書けるプログラマに。

ついでにコードを読むという話題なので、こんな本もありますよ、という紹介。

Code Reading―オープンソースから学ぶソフトウェア開発技法

他人のコードを読むときのコツだったり、どういう風に他の人のコードを読むかと言ったことが書いてあるいい本です。他人のコードを読むことを主題にしていて、オープンソースのコードを題材にしているので、ある程度プログラミングに慣れていないとさすがに難しいとは思いますが、一度読んでみることをお勧めします。

06 リファクタリングの際に注意すべきこと (ラジット・アタパトゥー, Rajith Attapattu)

「リファクタリング」はテストが書かれたプロダクトコードをテストが通る状態のまま、よりよいコードへと変更することです。

私はリファクタリングは基本的にテスト駆動開発のプロセスの一部として行われるのがベストだと思いますし、普通はそうであると思っています。 (おそらく一般的にもそうなのだと思います。)

つまり、リファクタリングにはテスト駆動開発の血が流れていると考えられるわけです。そう考えるとこのエッセイに書かれたことは大部分がテスト駆動開発で一般的なプロセスで求められることと同じだと気付きます。

リファクタリングを行う際は「一度の変更量は小さく」し、「既存のテストが通り」、「よりよいコードにする」。
これ以外にも気をつける点は書いてありますが、これは特に重要だと思います。これを崩してしまうと、リファクタリングとはそもそも言えなくなってしまうと思います。

ちなみにリファクタリングについては (私はまだ読んでいないのですが)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

がとても良いそうです。読まないといけませんね。

リファクタリングはより良いコードを動く状態で書くことができるよい方法ですが、間違ったやり方をするとその恩恵を受けることができなくなってしまいます。ですから、このエッセイに書いてあるようなことは気をつけるべきだと思います。

少々本題から外れますが、テストがないプロダクトコード (レガシーコード) が存在した場合は、テストをまず作ってからプロダクトコードの修正に入るのが基本です。このあたりは

レガシーコード改善ガイド (Object Oriented SELECTION)

を参考にするとよいと思います。

このレガシーコードの修正は (どうしてもサンプルというのが難しいので) 練習がしにくいのですが一度読んだ後、横に置いておき、レガシーコードにぶつかったときに取り出して見直してみるといったことをするのが妥当ではないかと思います。 (レガシーコードの修正はやったことがないので、この辺は推測です。)

最後に

個人でできることから、大きなプロジェクトに組み込まれなければ分からないことまでいろいろあるのですが、今回の3つのエッセイに関しては、個人でも行えることが書いてあったと思います。

個人でもグループでも上で書いてあるようなことを気をつけて行うことは重要ですね。

文章中に「思います」が多くなってしまっている気がしますね。もう少し上手な文章が書けるように頑張ります。