初めて趣味で書いたプログラムは自分の本を管理するためのもので、書いたこともないPythonを言語として選定して、一般的なコーディング規約もなにも気にせず、自分でボタンだのなんだの画面のパーツを実装し、勢いに任せて書き切った。自作オブジェクトどころか、自作関数すらほぼ作らなかった。命名規則もなし。ただPythonだったのでインデントだけ整っていた。もうそのプログラムは使っていない。
なぜ使っていないかというのは、本を管理するという用がなくなったわけではない。Python自体と一般的なコーディング規約を全然知らずに勢いにまかせ、ただ動くものを書き切ってしまったために、おそろしくメンテナンス性が低く機能追加が容易ではなかった。ここでコードのメンテナンス性の大切さを痛感し、コーディング規約やオブジェクトの使いかたを理解した上で代わりになるものを最初から書き直した。そっちを現在は使っている。たまに機能追加とかリファクタリングしながら。
趣味でプログラムを書く場合にも、メンテナンス性は大事だと思う。趣味だからこそプロトタイプを作って動かしてみて、そこから改良を加えていくことがあると思う。メンテナンス性が低いコードだと改良のためのコード書き換えが面倒になり、プロトタイプの域を出る前にプログラム自体が投げ出されたりしてしまう。そういうことを考えると、チームで仕事をするとき以外に、自分のためにもメンテナブルなコードを書くことを心がけるのはなかなか役に立つことだと思う。というわけで冒頭の一冊『メンテナブルJavaScript』。もちろんメンテナブルなことはチームへの恩恵があって、以下のように書かれている。
”誰が書いたかによらずにどのコードも非常に似ているだけでなく、ほとんどの開発者が他のメンバーの作業を分担し、バグの修正や新機能の実装をすぐに行えたのです” [vi]
すごく端的に見ると上記に反しそうな文がWikipediaに転がっている。「プログラミングは、芸術であり、文学である（参考）」と。芸術というと独創性が必要だと思えるし、文学というとちょっと堅苦しそうだ。Donald Knuthの考えらしいが、どういう文脈でこれを言っていたかを簡単に見つけることはできなかった。機会があったら著作を読んでみたい。
Knuthの名言集みたいなもので、上記の文に近いニュアンスのものを拾えた。
”A programmer is ideally an essayist who works with traditional aesthetic and literary forms as well as mathematical concepts, to communicate the way that an algorithm works and to convince a reader that the results will be correct.”
やや意訳で「プログラマーは理想的には、伝統的な美学を持ち数学のごとく明瞭な形式の文章を書くエッセイストのようなもので、彼の書いたアルゴリズムを読めば結果が正しく返されることが納得できるだろう」ぐらいの意味に取れる。やっぱり読みやすさとか考えてコードを書けってことなんだろう。
個人的にはどうも、文芸に比べると文学が決して読みやすいものではなく、むしろ難解さを持ったものだと思っている。辞書で調べると両者に大差はないのだが、本屋で文学の棚と文芸の棚を見比べると差がある。文芸では現代的な小説や最近の人のポエムなんかも並んでいて、楽しそうなものや簡単に読めそうなものが多い。一方で文学の棚に行くと、ドストエフスキーだのアンドレ・ジッドだのサルトルだの内容が哲学にまで影響を与えている作品がズラーッと並んでいる。そんな文学作品は楽しめる人と、そうでなく読む時間が無駄だったとする人で読み手が割ときれいに二分されてしまう。そもそも内容が難解だし、作家の個人的な価値観が内容のベースになっていたりする。アンドレ・ジッドなんて一般に伝統的な美学に対して亀裂を入れようとしてそれが評価されたようにすら考えられる。文学作品として出てくる有名どころは決してお行儀がいいものばかりではない。文学をそんなふうに捉えているので、「良いコードは良い文学作品を書くように」と聞くと、どういう文脈でそう考えているのかと確認したくなる。そして本屋の棚に並んでいる本の比較で読みやすい本を考えると、文芸作品と言われたほうがまだしっくりくる。
では良いコードは文芸作品のようにあるべきだろうか。
先日バイクが故障して、エンジンが止まった。ぼくはバイクなど全然詳しくなく、原因の特定もできそうにないなと困っていたところ、説明書を見つけることができた。説明書には故障原因の特定から処置の方法まで載っており、詳しくないぼくでも開けるところ開けてヒューズをチェックをして処置をするまでができた。日本語を読んで理解できればそれでバイクに詳しくなくても処置ができてしまう、よっぽど雑に書かれた説明書でなければ誰でもできるだろう。バイクに限らず他の家電でもそうで、説明書って実はすごいんだなと思う。
個人的にはコードをレポートや論文、あるいは説明書のようなものに近づけるように意識して書いている。誰が読んでもその使いかたが一定に解されるべきと考えているから。だからレポートや論文、説明書と同じように、特定の機能の記述は特定の箇所にまとめ、規約を参考にしてなるべく標準的な書き方をし、命名とかで独創性が出ないようにしている。話の流れに矛盾がないようにとかで文芸が良いコーディングのたとえに出されることもあるかもしれない。だがレポートや論文などでも読み手に理解される説明をするために文章に流れを持たせ、入り組んだ構造にしないのが鉄則だ。読み手に意図の伝わる文体を考えるというのは、文芸をやっている人だけの仕事ではないだろう。そして自分の個性を出すことより、自分の意図が伝わることに重きを置いて一定の枠組みで文章を書く。レポートや論文、あるいは説明書は読み手に内容を明確に理解してもらうために書く文書で、このコンセプトはメンテナブルなコードを書くそれと共通していると思う。
こんなことを長々と書きながらも、良いコードを書きたければ先人の意見をいろいろあさって読んでみるのもいい手だと思っている。だいたい比喩に出される『文芸』や『芸術』という言葉の、受け取り手の印象の違いぐらいしかなくて、実際にどうコードを書くかとなると読みやすくメンテナンスしやすくという具体的なところは一致するのだから。どう書けば読みやすくメンテナンスしやすくなるか、そんなわけで『メンテナブルJavaScript』も。
別の視点からコードは文芸ではないという話も
CODE IS NOT LITERATURE
スポンサーサイト
