テセウスの船をプログラミングで考える

2025/05/15

ジョーク

t f B! P L
eyecatch 数年前に竹内涼真主演のテレビドラマでタイトルが有名なため、ネット検索してもエンタメ情報ばかり出てきますが、 テセウスの船という理論が非常に面白いのです。 Wikipedia : https://ja.wikipedia.org/wiki/テセウスの船 知らない人の為にベリー簡単に説明すると、 「全部パーツ交換したのに、それってまだ元の船なん?」って話。 例えば、ラーメンの具をチャーシューから焼肉に、麺をうどんに変えて、汁を味噌汁にして、それラーメンか?ってこと。 今回はそれをプログラミング理論として考えてみたいと思います。

if文で船は沈む話

かつて、次のようなif文がありました。 ※ちなみに、プログラム言語はPythonです。 if part == "old": replace_with("new") 船のパーツを一個ずつif文で置き換えるコードです。 気づいたらif文が300行になって、Gitの差分も真っ赤な状態。 もはやこれ、テセウスの船というより、デスマーチの船なのである。

クラスで船をモデル化した結果…

class Ship: def __init__(self, parts): self.parts = parts def replace_part(self, part_name, new_part): self.parts[part_name] = new_part それぞれのパーツを辞書で管理して、順次差し替えるスマートな設計。 ・・・でもふと気づくことがある。 「この船、コンストラクタの中身全部変わったけど、selfはいったい誰?」 その結果、アイデンティティ・クライシス(自己とは何か問題)が発生しました。

船長が変わったら、もはや別プロジェクト

class Captain: def __init__(self, name): self.name = name 「船長(プロジェクトリーダー)まで変えたら、もうそれ別のコード(案件)じゃん」という問題が勃発する可能性もある。 GitHub上では別リポジトリとしてforkされがち。 テセウスの船長(Captain Theseus)が退職エントリ書きそうという話はおいといて、 プログラミングをリファクタリングする時によくこうした問題が起きがちだけど、結構こうしてプログラムコードは変化していくモノ。 こうしたプログラミングにおけるテセウスの船って、結果的にそれをコンパイルした(Webで公開した)サービスを使う人が、 同じ感覚で使い続けられるのであれば、同じプログラムと言ってもいいものかどうか?

Dockerコンテナで再現してみた

船 → コンテナ パーツ → イメージのレイヤー 替えてもID同じ → 「やっぱこれ同じ船です!」理論 でもマウントしてたボリューム消えたら → もうただの空の箱
確かにDockerで考えたら、別モノ扱いになるため、テセウスの船理論としては弱い感じがしますね。 しかも、イメージボリューム名が別ものになるので、もう一つ別のファイルが作られることを考えると、 同じでないことは明確。

あとがき

テセウスの船が同じかどうかは、観測者の主観によるという事。 コードも、「書いた人」ではなく「読む人」が「これ何の船やねん」と思った時点で別物と考えても良い。 結論として、 人は変わる、コードも変わる、でもバグは永遠。 という事。 何となく物語に落とし込みやすいストーリー期限として、「テセウスの船」を取り上げてみました。 ゲームのストーリーにもってこいですな!

人気の投稿

このブログを検索

ごあいさつ

このWebサイトは、独自思考で我が道を行くユゲタの少し尖った思考のTechブログです。 毎日興味がどんどん切り替わるので、テーマはマルチになっています。 もしかしたらアイデアに困っている人の助けになるかもしれません。

ブログ アーカイブ