00:01
最近ですね、お腹の調子を悪くしがちなんですよね。
ここ10年ぐらいですね、どうも小麦粉がダメらしいということが分かりました。
例えば、昼にカレーを食べると、
必ずお腹を壊すとか、昼にラーメンを食べるとお腹を壊すとか、
あとはですね、ピザとかですよね、パスタとかもそうなんですけど、
それ単体だとまあ何でもないんですけど、なんかそれに加えて甘いものを食べるとか、
あとは、まあよくわかんないんですけど、
そこら辺の、そのお腹を壊す時の要因を探ってみると、
どうも小麦粉が、小麦を使った何かが影響しているらしいとか、
まあうどんとかもそうですよね。
実際そこら辺の食べ物を食べて、必ずではないんですけど、
まあまあ高い割合で、
で、ここ3日ぐらい本当にそれの症状がひどくってですね、
もはやなんか小麦アレルギーなんじゃないかっていうぐらいに、
結構小麦に対する耐性がないことに気づきました。
うーん。
で、それに関してはですね、
小麦アレルギーなんじゃないかっていうぐらいに、
結構小麦に対する耐性がないことに気づきました。
うーん。やばいですね。
妻からは、もう霞しか食えないんじゃないのとか言われてるんですけど、
まあ本当にそんな感じはしますね。
小麦は結構最近天敵になりつつあります。
で、今回はですね、捨てられるソフトウェアということで、
やっていこうかと思ってます。
先週Ruby会議があったんですよね。
内容は全然見てないんですけど、
捨てられるソフトウェアについて喋ろうと思ってて、
捨てられるソフトウェアって何かってことですね。
捨てられたソフトウェアではなくて、捨てることが可能なソフトウェアという意味で捨てられるっていう言い方をしています。
どこの文献かわかんないんですけど、
結構そのソフトウェアはソフトだという話はちょいちょい、
いろんなというか、いくつかのソースを見て、
そういうワードを見ましたと。
で、これもなんかアジャイル系の書籍だったと思うんですけど、
ソフトウェアを作るにあたって、
最初に要求を実現するためにこれをやって、
次のイテレーションでもともと作ったやつを捨てて、
さらになる追加要求に対応して、
さらにその次のイテレーションでも今まで作ったやつを捨てて、
03:02
最終的な形に持っていくみたいなことをやったというのを見た記憶があります。
このコンセプトがまさに捨てられるソフトウェアなんじゃないかなと思っていて、
やっぱりソフトウェアってソフトであって、
簡単に壊したり簡単に取り替え可能であって欲しいと思うんですよね。
だからこそのソフトウェアという名前で、
ハードウェアに対する対比としてはそうですよね。
例えば機械とかマシン、
コンピューターそのもの、
本当に物理的な何かって、
厳密な品質管理とかを経て、
それで世に送り出されてっていう風な工程を経るので、
どうしても、
出した後にすぐまた置き換えればいいやってわけにはいかないものが多いと思うんですよね。
だからこそハードウェアって言われるものは、
厳密にしっかりしたチェックを経て世に出るっていうのがあると思います。
それに対するソフトウェアなんですよね。
ソフトウェアは本当にソフトでやって欲しいと。
ソフトであるって何かって言うと捨てられるっていうことだと思うんですよね。
ハードウェアも結局最終的にはリプレイされるような気はするんですけど、
未来英語を使うものではないよねっていう前提で設計するのがいいんじゃないかなと思うんですよね。
未来英語ではないと。
よくあるのが、拡張しやすいようにプラガバルにしようとか、
あるいは後でこういう要求が来るかもしれないから、
まあ、何でしょうね、
あらかじめこういう風なのに対応できるようにしておこうと。
この機能しかないから当然この機能だけのもの、
例えばENUMとかデータベースのステータスみたいなのがあって、
今は全然使わないのに後々の拡張性を考慮した、
なんとかとかなんとかみたいなステータスを用意するみたいなのがあると思うんですけど、
それってENUMって値だけセットするだけだから別にいいじゃんって思うかもしれないけど、
でもそれがあることによって後々誰かがコードを見た時に、
このコードはこういうのがあるかもしれないって思わせて、
あんまりそこのドメイン知識がない人にとっては結構意外と認知不可になったりするんですよね。
あとまあそういった今後の拡張みたいなのって、
よく言われてるヤグニっていうところにもなりますよね。
そうやっていくと、かえって捨てづらくなるんじゃないかなと思うんですよね。
06:04
捨てられるソフトウェアって、
最近のTidy Firstとかの考えにも通じるような気がするんですけど、
プラグインにする、例えばさっきのプラガブルにするっていうところなんですけど、
プラグインにするっていう意思決定自体を遅らせるのが狙いなんじゃないかなとか、
狙いだと思ってますと。
プラグインにする決定をした時点で既存の枠組みをとりあえず捨てて、
じゃあプラグインにしようかっていうところにできると。
今のところがTidy Firstで言っていたオプショナルの考えに近いと思うんですよね。
違うのかな?ちょっと違うのかもしれないですけど、
捨てられるような状態にするというオプションを手に入れることによって、
後で選択できるようにすると。
後で結局プラグインにしないという決定になるかもしれないし、
後でやっぱりプラグインにしようってなるかもしれない。
その選択肢を与えるっていうのが捨てられるソフトウェアなんじゃないかなって思うんですよね。
これって基本的には作り直しを奨励する考え方なんじゃないかなと。
というかそもそもこの捨てられるソフトウェアっていう考え、
誰かそういうワードで何か主張してる人いるんですかね。
ちょっと分かんないですけど、まあいいや。
この捨てられるソフトウェアは基本的には作り直しを奨励と。
作り直しってことはつまり車輪の再発明ですよねと。
その通りですと。その通りなんだけど、
さっきの3イテレーション目でようやく全体的にまともなものにするっていう例があったと思うんですけど、
1イテレーション目で作ったものを捨てる、2イテレーション目で作ったものを捨てる、
3イテレーション目で作ってようやくっていう、
その1イテレーションと2イテレーション目の経験は生きてるんですよね。
車輪の再発明だとは思うんですけど、それは見た目上車輪の再発明であって、
経験自体が蓄積されているので、
おそらくその3イテレーション目とか4イテレーション目で同じものを作るって言っても、
すでにある経験を使うことによってだいぶ開発スピードは上がるはずだし、
今まで踏んだ罠みたいなのも避けながら開発をすることができるはずなんですよね。
これが捨てられるソフトウェアの真髄と言ってもいいんじゃないかなという気がします。
なので車輪の再発明なのではという問いにはその通りですと。
でも経験は蓄積されていますという感じかなと。
それはそれでいいんですけど、
ソフトウェアって意外とソフトじゃない部分って結構扱っていて、
09:00
私はウェブアプリケーションの人間なので、
ウェブアプリケーションの例で恐縮なのですが、
ウェブアプリケーションだとだいたいデータベースっていうのが絡むんですよね。
データベースって言うとだいたいRDBMSですよと。
ノーエスケールとかちょっと分からないですけど、
RDBMSだとそのデータベースのスキーマ定義みたいなのがあると。
このテーブルがあって、この絡むがあって、
この絡むにはこういうタイプがあってみたいなそういうところですよね。
そこってちょっと変えづらいんですよね。
データ…そうですね。
絡むの追加とかって結構大変じゃないですかと。
そんな軽々しくできるものじゃないっていう認識みんな持ってると思うんです。
特にその対象のテーブルがすごくよく使われているとかそういうパターンですよね。
インデックス貼るとかもそうかもしれないですよね。
あるいはタイプがそうだな…
バーキャラの255みたいなそういう定義があったとして、
実はでもそれで収まらないから長さ変えたいみたいなのって結構気を使う操作ですよね。
隙間変更。そういうのって実は全然ソフトじゃないハードな部分ですよねっていう気はするんですけど、
じゃあ捨てられるソフトウェアという概念はそこにどう立ち向かっていくのかっていうと、
まずですね、全部が全部捨てられるかどうかともかくとして、
あるウェブアプリケーションがあって、その中のある機能があるとしましょうと。
Aという機能を実装しますって言った時に、Aという機能を捨てられるようにしましょうと。
そのAという機能自体が捨てられるようになっていれば、
使わなくなったらその機能自体削除すればいいんですよね。
Aという機能を残したままソフトウェア的に捨てるっていうのは確かに大変なんだけど、
A自体がなくなれば全然、たぶんおそらくドロップテーブルとかすればいいだけなんですよ。
もちろんそのテーブルへの参照とかないかとかいろいろ確認する必要があると思うんですけど、
それで全然ことたりると。
あとですね、データの話で絞ると、
そもそもそのさっきのAという機能ですね、
Aという機能を使った時に蓄積されるデータ、
そのデータって本当に未来英語を残す必要があるのかとかは、
いい問いかもしれないですよね。
実は大したことに使ってないから別に削除してもいいよねとか、
そういうのであれば、
Aという機能自体は残しつつも、
でもシステム的にというかその実装部分を捨てて新しく作り直すって、
12:01
できなくはないかもしれないと。
ちょっとチャレンジングな気がするんですけど。
理想はやっぱり機能自体が捨てられるっていうところですよね。
もちろんソフトウェアのソフトの部分だけで立ち向かうことができればハッピーなんですけど、
そうもいかないんで、
じゃあこの機能自体は捨てますよね、捨てられますよね、
うまくいかなかったら捨てますよねみたいなのは握るっていうのは、
それもそれで開発者のコミュニケーションで必要な話なのかなとも思いますよね。
あとはよくあるのはパッケージングするみたいなのがありますよね。
パッケージング、境界を定めるとか、
そのパッケージ自体を削除できるようにするみたいなそういうプラクティスもあるかもしれないです。
ただそれもやっぱりパッケージ自体を削除するってことはおそらく機能自体を捨てるっていうことにもなるので、
結果的にはやっぱり機能自体を捨てられるようにするっていうのが、
捨てられるソフトウェアがハードな部分に立ち向かうのに必要なところなのかなと思いますよね。
そういうのを支援する仕組みがあるといいのかもなとも思うんですけど、
今のところちょっと思い浮かばないので、
いいアイデアがあればぜひという感じですね。
というところで、今回は捨てられるソフトウェアについてちょっとしゃべってみました。
このあたりですね、ちょっと探求しがいがある話なので、
もしかしたら何回か話すかもしれないし、
ちょっと夏休みの宿題にしようかなと思っています。
それではまた。
