コードの抽象化

最近は雑務に追われて自分の仕事をあまりできていなかったのだけど、今日は久しぶりにまともに機能開発に打ち込めた。プログラミングってばやっぱ楽しいよ。

先日読んだ記事でとても印象的なものがあった。

http://steps.dodgson.org/?date=20090503

コードの抽象化を行う目的・タイミング・程度についての考察。
まとめがてら追って見る。

抽象化とは何か

曰く、理解の助けになる抽象化と対象との距離を生む抽象化があると。前者はプログラムの対象の本質を捉えた上でそれらに適切な名前を与えてやること。後者はプログラムに再利用性を与えるためにより高次のレイヤーまで抽象化を押し進めること（それを補うためにドキュメントが必要になってくるという説）。これは別物ではなくて程度の差だといえそうだ。そうすると、どんな場合にどの程度の抽象化を行うべきなのかということになる。

投機的抽象 VS YAGNI →妥協案としての「目配せ」へ

将来の柔軟性・拡張性を見越してその時点では過剰と判断されるまでの抽象化を行うべきか（投機的抽象）、抽象化は必要になったときに必要な分だけ行うべきか（YAGNI）という話。
将来への過剰な危機管理が現在の最適解を見失わせるという話が頭では理解できる一方で、経験から高い確度で将来が見えるときに先手を打たないということもできない。そういうジレンマの中で筆者は先行投資のリスクヘッジを行いつつ控えめな警鐘をならしておく（目くばせ）という手法をとることがおおくなったという。
この手法の痛いところは警鐘を聞いてくれる、或はそれが聞こえる人間が周囲にいなければほとんどメリットを生まないというところにある。

リファクタリング主義者曰く

そもそも投機的抽象も目くばせもプログラムの対象を理解していないことが原因なんだと。試行錯誤（testとリファクタリング）を繰り返すことで対象への理解を深めていくことこそが重要で、それができれば必然的に必要十分な程度の抽象化に落ち着くはずだと。

結局？

扱っているものにもよるかも知れないが、現実のソフトウェア開発では大抵、対象を完全に理解し尽くすことなどできない。情報・時間・能力が足りないのかも知れないし、対象とそれを取り巻く状況自体が変化するのかも知れない。僕らはそれを前提にして、何らかの方法を選択して前に進むしかないことが多い。どの方法がベストかはその時と場合によるだろうし、どれをとっても地獄ということもあるかもしれない。つまりは曖昧な対象を目の前にビジネスをするときのジレンマとどう向き合うかという話。

確実にできることは、どんな方法があるのかを知ること、経験を積むこと、それらをベースにして考え続けること、そしてそれを繰り返すこと。大きな目で見た時、入社してからこのサイクルをだいたい2周くらいした。なんか遅いし、ちょっと笑っちまうくらい苦々しい記憶。それこそ対象の理解が覚束ないために抽象化の程度と方法を間違えてきた。少しは階段を上っていればいいのだけど。でもまあ、今の仕事の何が面白いってそれが面白いし、そういう試行錯誤がもっと効率よくされなければいい加減まずいんでないかという危機感も強い。自分が扱っているソフトウェアは同じ製品のバージョンアップを重ねて行くものなので、将来の柔軟性・拡張性が生命線になる。Martin Fawlerの言う負債の利子率が極度に高いわけで、まずは最低限必要だと確信できる抽象化から取り組んで行くだけでも効果はあるはず。