読者です 読者をやめる 読者になる 読者になる

その手の平は尻もつかめるさ

ギジュツ的な事をメーンで書く予定です

デプロイ考,あるいは仕組み化考

良い感じに酔っ払っているのでここ最近デプロイについて考えていることについて記す.


デプロイの仕組みが単純であれば単純であるほど良い,というのは総意だと思っている.
単純な仕組みによってデプロイされるのと,複雑な仕組みによってデプロイされるのとで比較した時,
互いの結果 (つまりユーザに提供できる機能) の差が有意でなければ,
単純な仕組みの方が総コストが低くて良い.


で,ここで出てくるのが「仕組み化」ってやつで,
仕組み化はそうした総コストを下げる為にやる,
つまり作業を楽ちんにするためにやると思うんだけど本当に楽ちんなのかどうかは
冷静に考える必要があると思っている.
(あるいは例えば,それオーバーエンジニアリングやん,とか)


最初のうちは仕組み化できて嬉しい,最高,これで平和が訪れた! みたいな感じになると思うんだけど,
ゆくゆくは色々な事情から変更変更そして怒涛の変更が訪れて,仕組みもありのままではいられないと思う.
ビジネスは素早い.


そういう感じで変更が生まれた時には仕組みに手を入れる必要が出てくると思うんだけど
そういう「仕組み」っていうのはたいていブラックボックス化されていて,
つまり表層の面倒臭さみたいなものを抑えこむ為に複雑怪奇なメカニズムになってる場合が多い気がする.
(あるいは何かPaaSを使ってるとしたら,なんらかのhackishなプロセスが要るとか)
「まあブラックボックスだからええやん?」みたいな感じでゴミ溜めのようになりがちというのもあると思う.
結局そこに手を入れる事で要らぬ苦労をし始めてしまって,楽をするための仕組みをいじるために異常に苦労するという
ケースが少なからずあってつらい.仕組みに囚われる.仕組みに殺される.


で,そういう地獄を避けるためには変更に強くする必要がある.
変更に強くするというのは重要で,我々はその点に心を強く持つ必要がある.
(あとはその副次的な要求で,構造をシンプルに保つというのもあると思う)


さて,その「変更に強い」というのは本当に変更に強いのだろうか?
ただ単純に「物を追加しやすい」だけではないのか?
「変更に強い!!!」とうそぶいて,アドホックに欲しい機能を追加しまくっていった結果
死んでしまった存在というのを我々はたくさん見てきたのではないのか?
「変更に強い」というのは,むしろ使わなくなった機能を抽出・検出しやすい,
そして取り替えやすいということではないのか? 機能の足しやすさとはまた違う概念なのではないのか?


まあ,とにかくそういう感じでデプロイのプロセスが複雑になっていくのは,
そもそもそういう複雑さをアプリケーションが要求しているからではないのか,
という事は心の隅に留めておくと良いのではないか,と思っていて,
「シンプルなデプロイでいける!」という構造を心がけるのは重要な気がしている.
例えばサーバサイドでステートを持つ必要が無いやつはjsオンリーで書いて,
GitHub Pagesにpushするだけで動く,みたいなのがシンプルで良い気がしている.
まあ,なんだかんだでFTPでファイルアップロードして一発で動く,みたいなのが理想なんじゃんすか?
というわけで,シンプルなデプロイにするためにはシンプルなアプリ構造を考える必要があると思った次第.


まあなんか話が逸れましたけれども,とにかく仕組み化して終了!!! みたいなものではない,
仕組み化はゴールではなくスタートだ,仕組み化したから最高のプロダクトが生み出されるわけではない,
仕組み化してからのプロジェクトの進行,運用,そして祈りが良いプロジェクトか否かを左右するのだなあ,
というのはここ最近強く思った次第です.


メリークリスマス!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
もうだめだ