この記事は、適応型ソフトウェア開発 アドベントカレンダー 2024 の 19日目です。
適応型ソフトウェア開発的な設計思想について
ここは筆者が案件進行中に一番悩んだポイントの１つだ。
複雑適応系を形成し、簡単なルールを用いて案件の状態把握ができるようになったとしても、設計思想が従来のままだった。
その結果、全く適応力に還元されることがない状態につながってしまった。
しかし、身近な先人からのアドバイスを受けて、向き合い方を変えることができた。
どうして設計思想も適応的にやらないの？
これは本当にそうだと思った。なんでやらなかったのだろう。
ここまで複雑適応系に向き合うため、色々と思案してきた割に、エンジニアとして一番押さえておきたいポイントで適応的なことを考えていない。
早速それに「適応」し思考してみることにした。
適応できていない理由はなんだったか
それはまず動くものを作るというマインドは間違っていなかったが、試作の方法が間違っていた。
これはフロントエンド側・バックエンド側の双方からの課題がある。
バックエンド側
これは大体の場合、データベースのテーブル定義あたりに適応力を持たせることが有効だった。
特にリレーショナルデータベースとの相性は良い。
実際にどんな項目があると有効なのかわからない状態が続くカオスであるとき、とにかくがっつりテーブルを作らないことを徹底することが大切だった。
例えば、「ユーザー」という概念をモデリングしたときがわかりやすい。
ユーザーテーブル
わからないなりにモデリングを行いながら、プロトタイピングを進めていくとき、
テーブルを１つ作って進めていくほうが何だか素早く見える。
ただこの形式だとかなり適応力に乏しいプロトタイプになってしまうことが多かった。
今回適応型設計を試みたときには、このようなものを準備した。
user_role や user_department といった中間テーブルを持つことで、たとえば role というドメインがカオス探索中不要になったとしても、簡単に破棄することができる。
このように削除がどのポイントで発生するかわからないため、いつでも削除できる柔軟性を持たせることが適応力につながると考えた。
結果として簡単に実装を捨てられたり、組み換えられたりするようになったので、適応力は上がったと言ってよい。
フロントエンド側
Reactを用いて開発をしているが、vueに置き換えて考えてもよい。
フロントエンド側はとにかく関心ごとを混在せずに、役割に徹するコードやコンポーネントを小さく分割し作り続けることが最も適応力に富んだ実装だった。
コンポーネントを小さくする
ビジネスロジックを徹底的にコンポーネントから排除し、別のファイルに切り出し続けた。
例としては、useHook や Redux selector などだ。
ビジネスロジックから分離されたコンポーネントは、UIが変化したとしてもドメインが変化していないなら使いまわすことができる形になった。
そのため、デザインを思い切って捨てることができるようになり、適応能力が高くなっていった。
まとめ
ほかにもいろいろな工夫はあるが、ポイントは１つだ。
雑に作ることが大切。ただし、無暗に作るとは言ってない。
雑に捨てることができるコードを手早く作る。
そのために結合ポイントを小さくする考え方を持つことが、適応力の高い設計足りえた。