ぐらめぬ・ぜぷつぇんのはてダ(2007 to 2011)

2007年~2011年ごろまで はてなダイアリー に書いてた記事を引っ越してきました。

ソースコードを絵画にしてくれるツールが欲しい。

独り言。
YakiBikiを会社で使う為に、あらためて操作マニュアルというかそんな感じのメモを作ろうと、色々弄り回してるんだけど・・・やっぱり、最初の頃に作ったコードの部分はBUGヒット率が高い。YakiBikiは仕様が徐々に決まっていったやつなので、例えばエラー処理とかログイン周りとか、後になって追加したり、最初にコードを書いた当時は意識していないハンドリングが増えたりしてた。

これは曲がりなりにもプログラマーとして働いている個人としては深刻な問題で、以前関わったPrjでもやっちゃったんだけど、初期に作ったコードや、単体テストが始まった最初の頃のテストのエビデンスとかは後になって実はBUGってたり、エビデンスの内容が不適切だったりする場合があった。結局コード全体を俯瞰して、昔のコードの「ムラ」に気づかない・気づけなくなってしまってる。マズイ。非常に、マズイ。

子供の頃、お絵かきの手習いに出ていた時があった。「ハッカーと画家」じゃないが、結局そのころの手法で今もやってしまっているのかも。つまり、最初は下絵描き、スケッチで、だんだん筆がのって色もどんどんのっていく感じ。プログラミングを独学で勉強した場合は大体そんな感じになるのじゃないだろうか。最初はとにかくたたき台、というかやりたいこと・作りたいことが本当に実現可能かどうか、簡単なテストプログラムを作ってみて、それを徐々に肉付けしていったり、時にはぶちこわして作り直したり。

で、「絵」であれば過去に描いた部分も一枚の絵の上で見渡せるから良いのです。「あー、この部分、まだ下書き線が見えてる。ぬりぬり。」とか、「あー、離れて見るとここの箇所、色が合ってないなぁ・・・。結構初期にぬりぬりしたところだし・・・」と、一目で判断が付いて手を打てる。

ソフトウェア、というか現状の自分の技術ではそれができない。プログラムに対して。なので、タイトルのような欲求が芽生えてきたわけです。バージョン管理ソフトのコミットログとかがそれになるのかな。うーん・・・。例えば関数やメソッドの中には沢山のWordが埋め込まれているわけで、このWordの分布をRGBにしてみるとか・・・。例えば共通のエラーロジックが組み込まれるべきモジュールは一枚の「絵」としては近い位置に配置させれば、共通のエラーロジックを組込忘れているモジュールだけ色合いが違ってくるので一目で分かるとか・・・。例えばコードの行数を色の濃度で表すと、短めなユーティリティ関数をそれっぽい位置に配置して、コード行数が長めのロジック処理の入ったモジュールとかはそれっぽい位置にすれば、やたら長くなってしまったユーティリティ関数や、大切な処理が抜けていて(=初期に作成した)コード行数が短めのロジック処理とかが色合いの違いで分かる。

ソフトウェアメトリクス・・・とは、違うのだろうなぁ。規模とか結合度、凝集度・・・と関連しなくも無いのだけれど、自分が把握したいのはむしろコードの「ムラ」を一望できるようなツールだから・・・。コミットログの最終変更時刻を使って白黒のグラデーションにしても良いかも・・・。例えばエラー処理など、モジュールを横断してコードの変更が必要な場合、これで視覚化することで未対応のモジュールが分かるかも・・・。でもなぁ、色合いの似たもの、似るべき者同士をどうやって近い位置に配置するのかは結局作る人が頑張らなくちゃ行けないわけだし・・・。語彙の出現傾向を判別して自動的に配置するとか、命名規約から似たもの・似るべきもの同士を自動的に寄せ集めるとか・・・しないと?だめ?

というかそもそもこうした思考自体が何か根本的に間違ってる気がする。