" />
本ページはプロモーションが含まれています。

スポンサーリンク

設計

業務システムのアンチパターン。1つの画面で複数のことをやろうとする。

1つの画面でいろんなことをやろうとすると、フロントの実装(コード)が複雑になります。1つの画面でいろんなことをやろうとすると出てくるのが、いろんな「状態」です。そうすると、画面制御パターンも増えてきて、誰も手に負えない、実装者もメンテナンスしたくなくなるフロントのコードの出来上がりです。

シンプルな設計は、全体工数も短くなる

出来ることは同じでも、画面が複雑になればなるほど、実装・テストにかかる工数は増えます。一方、品質は下がります。

利用者も1つの画面で何でもできることを望んでいるわけではありません。利用者は便利なシステムを望んでいます。

1つの画面で何でもできる(項目を増やす)ようにするのではなく、

  • 無駄な動線がないか検討してみる。
  • API呼び出し後にリロードしないようにする。

そういう工夫で、1つの画面にあれもこれも詰め込まなくても、エンドユーザが喜ぶ便利なシステムは実現できます。

1つの画面にあれこれ詰め込むのは、不幸の元です。1画面1機能、1画面は1つの目的のためにしましょう。

実装の遅延は複雑な設計による

うちのチームは順調なのに、あのチームは遅れてる。順調に終わったら、あのチームを助けてあげてくれない?と言われてヘルプに行きました。

そしたら、何か複雑な画面–APIになっちゃってるんですよね。遅れているあのチームの人たち、こんなもの作らされてたんだ、かわいそうにって思いました。

設計者が違うと、同じ対象をシステム化しようとしても、全く違うシステムになるということがよくわかりました。

私のチームが順調なの、私のチームメンバーが優秀なんじゃなくて、私のチームの設計者が優秀だったからなんだ。

あんな設計で実装してたら、自分がやっても嫌になったかもしれない。わざわざ難しい作りにしちゃってるんだもん。

1画面1機能にする。複数機能入れる時でも、最低限、リクエストは分割する。

最悪なのが、1画面に複数機能を持たせて、全部まとめてリクエストするようなフロント–APIの構造になってる時です。

つまり、サーバー側は1つのPOSTメソッドで、複数機能の役割を持つ構造になってるんです。これはもうめちゃくちゃ保守性悪いです。

エンドユーザもそんな構造の画面を望んだわけじゃないと思いますけどね。

1つの画面に複数機能持たせるとしても、せめてAPIは機能ごとに分割しておいて欲しい。

シンプルで保守しやすい設計にするには?

では、実装者がストレスも遅延もなく実装できて、品質にも自信が持てる。エンドユーザも使いやすくて喜ぶ。そんな設計にするにはどうすれば良いのでしょうか?

それは、複雑な画面から部分部分を切り出していくことです。複雑な画面は、1つの画面でAもBもCもやろうとしています。

Aは別画面、別APIにする。Bは別画面、別APIにする。という風に、どんどん切り出していくことで、シンプルになっていきます。

そうすると、やらないといけない機能の総量は同じでも、実装・テスト工数は複雑な画面に比べて半分近くになります。

スポンサーリンク

-設計