よい本を読んでもなかなか使いどころが難しいという話

先日、会社で欲しい本を買ってくれるというのでこの本を買ってもらいました。

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)

より良いコードを書くために...という副題が付いているとおり、本書はコードを書く上で気を付けるべき点について書かれている本です。

わたしがプログラムを書き始めたのは大学4年生のときなので書き始めて15年くらい経つのですが、いまだに「これだ!」という自分のスタイルを見つけかねています。「変数の名前はどういう感じに付ければいいのか?」「コメントに何を書けばいいのか?」といった基礎的な部分から「処理の分割単位はどのくらいの規模にするのか?」とか具体的な部分に至るまで、長く続けてきたからこそ身に付いている勘どころみたいなものはありますが、それがベストなのか?というとそうでもないなという気がしてならないのです。

読みやすいコード、修正しやすいコード、拡張性のあるコード。

そんなコードの書き方に関するパターン集とも言えるのが本書「リーダブルコード」でして、まだ全部は読んでいないのですがとてもおもしろいです。自分の考えが正しかったんだなと思える部分もあれば、逆に考えが足りなかったんだなと思える部分もあって久しぶりにあちこちに付箋を貼りながら読んでます。

買ってもらってよかった!


そんなわけで、せっかくいい本を読んでるわけですからいいなと思ったところから取り入れていきたいなと思ってみたものの、意外に難しいことに気付いたのです。


例えば「変数名を分かりやすくする心がけ」という部分を読んでから過去に書いたソースを読むと非常に分かりにくい名前を付けていることが分かります。名前を見れば何が格納されているのか分かるようにすべき!と言われるとそうだなと思うのですが、じゃあいま動いているプログラムのソースにさっと手を入れてリファクタリングするのか?というとなかなかそこまではできません。

変数名だけの変更であればそこそこ自動でできるとは言え、直したら直したでデグレードがないかどうか確認しなければなりませんし、まして気になる変数を全部直すとなればかなりのボリュームですので直し終わった後のテストは単体テストだけではやや不安が残ります。

とりあえずできるところから少しずつ直していくというのが正しいというのはわかりますが、こういうのはある程度まとめてやらないと読みやすさにばらつきが出て非常に管理しにくくなります。あと、直すのに時間をかけてしまうとどこまで直してどこから直してないのかがはっきりしないなんてことも出てくるわけでやるならガツンとやらないと中途半端に終わってしまいます。

でもガツンと直すとテストが大変過ぎて手が回らないと...。


こういう「改善は部分的にでもするべきなのかそれとも全体で同じレベルにすべきなのか」という話は、実はプログラムを作っているとわりとよく出てきます。C#のように言語のバージョンアップが頻繁に行われるようなケースは特にそれが顕著で、以前はベストだった方法が陳腐化しやすいという状況がよく発生します。

例えばデータベースへのアクセス方法がわかりやすいのですが、接続型(SqlConnection/SqlCommand)だけだった時代はあっという間に過ぎ去り、非接続型(SqlDataAdapter/Dataset)での方法が主流になったかと思えばLINQやEntity Frameworkが出てきてそちらがいいよねという話になっています*1

このケースの具体的な例を挙げると、最初は接続型で作っていたシステムに機能を追加しようとしたらEntity Frameworkという非常に便利なものが増えていた場合、機能追加する部分は接続型で作るべきなのかそれともEntity Frameworkで作るべきなのかで悩みます。

接続型で作れば昔作った部分と同じような内容になるのでメンテナンスは非常にしやすいのですが、最新の便利機能の恩恵にはあずかれなくなりますし、逆にEntity Frameworkで作ると開発効率はよくなるものの他のDBアクセス部分とは作りが異なるためにメンテナンスはしにくくなります。

どちらがいいとか悪いとかという話ではなく、一部にしか適用できない改善事項を積極的に取り入れるべきかどうかという選択の問題をわたしは判断しかねているという話です。


そんなわけでせっかく良い本を読んだのに、なかなか適用する勇気がもてなくてもったいないなーと悶々としている毎日です。

*1:システムの形態によって向き不向きも多少ありますが