技術的負債がいかに問題かをどう伝えるといいのか

沢山の方がチャレンジしては上手く行ったんだが行ってないんだがみたいな結果に終わるコレに自分もチャレンジしてみようと思う。

上手く行ってるか分からないのは自分が技術者だからなんだけど。

まず技術的負債って言葉で、何か悪いものがたまって行くのはわかると思うが、どのくらい深刻なのかは伝わらないよな。

それと、プログラムが日に日に複雑になって行くというのがなかなか他に似たようなケースがなく、何が大変なの？という感じなんだと思う。

特に少しだけ、小規模なプログラムをかじったことがある人には。

彼らはやり方を知ってる分アレを取ってきてアソコに出すだけでは？何が大変なの？とふざけた事を思うだろう。

プログラムをメンテし続けた人にしか分からないこの難しさを別の形でイメージしやすいもので伝えないといけないんだと思う。

ここからがチャレンジ。

まず、プログラムというのは矛盾があっては行けないルールブックのような、法律のようなものです。

矛盾があると、プログラムは止まったり壊れたりしてしまいます。

出来るだけ避けないといけないです。

なので、時間がなくて、その場を取り繕うような適当な、厳密に言うと嘘があるルールを定義してしまうと、後で矛盾が出やすくなってしまいます。

このまま突き進むなら、嘘をつき続けたり、嘘をつくための更なる嘘をつくことになります。

どんどん巨大なルールブックになって行くのに、過去に定義したルールも含めて少しの矛盾も許されなくて、その上で嘘を隠し通さなければいけません。

数カ月から数年に渡ってものすごい複雑な嘘を矛盾無くつき続ける、と考えるとかなり苦しいものであることがイメージ出来るんじゃないかと思います。

これが世に言う技術的負債です。

しかし、一つ目の嘘の後に訂正の機会をもらえると、"さっきは勢いでああ言っちゃったけど、正確には違うんだ。こう言う事なんだ。"と訂正出来ます。

その後は正直に、自然にルールブックにルールを追加して行くことが出来ます。

嘘がないルールブックなので、新しいルールが増えてもどこに影響するかが分かりやすいため、矛盾が起こりにくいです。

この訂正作業が世に言うリファクタリングだったり負債の返済です。

長い期間をかけてルールブックを大きくして行きたいなら、適宜この作業を組み入れた方が合理的と言えます。

たとえ1度も適当なルールを作ったことが無くても、過去に作ったルールが全て未来を予見して作ってる訳では無いので、新しいルールに合わせて訂正しないと嘘になるケースがあります。

この場合もやはり訂正の機会を適宜設けた方が良いと言えます。

ここまで。

大分乱暴なところもあるけど、厳密さより伝わりやすさを重視した。

どうかなーやっぱ伝わんないかなー。