以前noteに書いた記事からの転載 エクスポートできないので、定期的に少しずつ転載していきます。
いつかちゃんとしたスライドに書き起こしたいとおもいつつ、まだ手がついていないけど、この記事に書いている「プログラミングは、コードと、データと、改修の歴史の3つの要素が絡み合う」を分解していきたい。
コードと、データは本質的には不可分だし、その結びつきを分解できないように密に結合させているのが、改修の歴史なんだ
よく「データの寿命はコードよりも長い」と言われるけど、受け継がれたデータは、当たり前だけどそれが作られた当時のコードに強い影響を受けていて、不可分だし、暗黙のうちにコードの特性を引き継いでいる。
つまり、例え直接的にはコードが無くなったとしても、コードの影響が無くなるわけではない。
そして、それらの蓄積が歴史となって、全体を形作っていくんだ。
だから、データとコードの寿命は同じくらい長い、と言えるんだ。
プログラミングは難しい…たぶん。
オブジェクト指向プログラミング、関数型プログラミング、アジャイル開発手法、各種設計原則や、テスティングフレームワークを使ったTDD等々…色々なプログラミングを支える要素技術はここ10年で爆発的に進化して、「とりあえず動くものを作る」という段階から、「先を見据えて、ずっと維持できるものを作る」という段階に変わってきたように思える。
きっとそれはシステムが動く環境が変化し、以前のような「動いているものを触るな!」という思想ではとても維持できなくなって、「なにもしていないからこわれました」という時代に変わってきたからだと思っている。
とはいえ、じゃあオブジェクト指向プログラミング言語を覚えて、各種設計原則を頭に畳み込めば魔法のように解決するか?と聞かれればやっぱりそんなことは起きない。
なぜか?
定量的な情報は探しても見つからなかったけど、感覚的にコードは書いている時間より読まれている時間の方が圧倒的に長い、ということに異論は無いと思う。たいてい、プログラムの寿命から言って、新規にコードを書くより既存のコードベースに対して改修を加えていくことが多い。
その時に考えることは、以下のようなことだと思う。
- 今のコードは何をするのか、どうゆう意図か、理解できたか?
- 今回、修正すべき箇所はどこか、漏れなく抽出できたか?
- 既存のコードと、今回の修正コードは整合しているか?
- 次回修正する際の障害となるような一貫性の欠如は無いか?
- 上記の情報は、後で追跡可能なように、まとまっているか?
ベストプラクティスとして、影響箇所が局所化されるように疎結合に作っていく、改修漏れが起きないように一貫性を保って作っていく…原則は分かっていても、現実の要求に照らし合わせていくと、必ずしも全てを満足することはできない(満足することができないからこそ、原則に立ち返るのは大事だけど、それはまた別の話)。
ここで唐突に結論めいたことに突入するのだけど、プログラミングは、コードと、データと、改修の歴史の3つの要素が絡み合うと思っていて、結局コードだけ見ても分からないし、データを追加しても分からないし、これまでの改修の歴史まで見て初めて分かることが多い。
いくらテストコードにデータパターンが網羅されていても、結局git blameで改修の歴史を追いかけたことは皆さん有るはずだ。
そして、これらのテクニックは非常にプロジェクトローカルなバッドノウハウになりがちで、技術書や、スクールでも扱われない…みんなゼロからきれいなコードを書くこと、きれいな設計にしないと後で困るよ、という事は言ってくれるは、現実にそうではないコードとの向き合い方は教えてくれない。
リファクタリングの技術は、解説された本も有るけど、きれいではないコードをリファクタリングする前に、まずは理解して直すだけ、というシチュエーションの方が多い…そんな時に、どうすればいいのか?
そんな時に、プログラミングを難しいもの…と感じるのではないか?
ということで、ここではプログラミングを難しくする要素は、既存のコードベースを読み解くことです、しかもコードだけでは駄目で、データも、歴史も見ないと分からないことが難しくしているのではないか?ということを書いてみました。
この辺、もっと事例を挙げてスライドにいつかまとめて発表したいと思っている。