金融系のソースコードの「独立性」

例の話に関しては、特に言うことはありません。違う話です。

何かの拍子に、「金融系はバグに対する影響が大きすぎるのでコピペ推奨」みたいなものいいを見た気がするが、本当だろうか。幸いにも金融系の現場には縁がなく、コピペ推奨ならば、それこそ縁がなくて幸いである。

コピペ推奨、という文字列を見て反射的にカッとなってしまったが、そこはもう大人である。深呼吸して、この文化（が本当だとして）に正統性がないのかどうか少し考えてみることにした。

我々はふだん、疎結合疎結合と呪文のように叫んでいる。ネコも杓子も依存性を憎んでいる。というわけでモジュールを細分化し、テストのためにモックを挟む。さて、ソースコードを全てコピペするのは、これと比較してどうだろうか？完全に悪と言い切れるのか？ある意味で、単機能に関して完全に「疎」と呼べてしまったりしないのだろうか？

脊髄反射を抑えて（脊髄反射って医学用語ではないらしいですね）逆に考えよう。全部コピペして、失うものはなにか？コピペした一箇所でバグが発生したら、全部の箇所を修正する必要がある。それはDRYになっているときよりも、時間がかかる。それは避けたいだろう？それなら、同じ内容を関数にまとめるんだ。

…という話の流れをずっと、わたしも受け入れてきたわけですけど、修正に時間がかかる、という点を他の方法で補えるのであれば、それでいいのか？例えば、大量の人員。プロジェクトリーダーが担当者たちに調査させ、その人たちに一斉に修正させる。全員分を合わせた手間はかかりますが、それぞれの箇所の「独立性」は保たれる。つまり、不具合の影響が広範囲に及ばないことが保証できる。人の管理をしていれば、不具合を起こした人間の責任を問うこともできる。

なるほど。なるほどね（浮かない顔）。

その人員たちが、修正をある程度の精度で行ってくれることが期待できるのであれば、この方法は一定の合理性がある、と、認めざるを、得ないですよね（おえない、じゃない！）（真顔）。

プログラミング人口がこれからたくさん増える（？）のであれば、そういった方法もますます（雇用確保の面で）意味を持つのかもしれませんね（白目）。というかそれは現状でもある程度、一定の界隈では、すでにそうなっている気がしてきました（だから金融業界ではそうだとすでにどなたかは言っているではないか）。

さらにコピペ側に有利な話をしてしまうと、一見、同じに思えたコード片が本質的には違うものであると後から分かることも多々、あります。そもそも、コードをまとめるスキルって想像以上に高度らしいのです、特に巷では（自分が得意だとは口が裂けても言えない）。

それでも、こう書きながら、わたしは絶対にコピペしないでしょうし、慎重に考えながら処理を共通化していくんだろうと思います。だって、コピペOKにある側面では一定の正当性がありそうなのはなんとなくわかっているけれど、それってプログラミング以外でもできる「作業」なんだもん。わたしがプログラミングに求めているのはきっと、なんかスタバでMacBook広げるイケてる姿でもなく、１０００万稼ぐ手段でもなくて、「少ない手数で多くの目標を打ち抜く」ってこと、なんだろうな。わたしにとっては、ね。