ソフトウェアを設計するとは?

ソフトウェアを開発していく上で、設計するとはという重要な問いについてまとめておきたいと思ったので書いていきます。

設計するとは?

「コードの責務の分割単位が適切かどうかを考えていくこと」だと考えています。

まず、ソフトウェアを設計する背景として、近年のアプリ開発状況が変わってきたことが挙げられます。

技術が進歩し、アプリでできることが増えたことに伴って、ソフトウェアに要求されることも増えました。特に「迅速に完成させること」「変化に対応できること」が重要な課題となっており、その要求を実現するため、アジャイル開発などの開発手法が出現しました。

アジャイル開発を実現するためにはコードの責務を分割し、チームでの開発スピードやコードの品質を落とさないことが求められます。

そこで、設計を行うことで、それを達成しようとしています。

責務の分割

責務の分割単位が適切かどうかを知るためには、原則を知ることが必要になってきます。

代表的なもの

  • 単一責任の原則(Single Responsibility Principle)
  • 依存性逆転の原則(dependency inversion principle)

原則とは、先人たちが生み出した、ノウハウをうまく言語化してくれたもので、設計などを考えず普通に開発をおこなっていると起きる問題の解決方法だと考えます。

コードの責務とは直接的には関係がないですが、KISS(Keep it simple stupid.)やYAGNI(You ain’t gonna need it)なども1つの原則だと言えます。

これらの原則に従ってコードを検証することで、責務の分割単位が適切かどうかを知るきっかけになり、結果的にアジャイルな開発を実現できます。

オーバーエンジニアリング

ここまで、原則に従うことは素晴らしいと言ってきましたが、これらの原則に従っていれば良いというわけではありません。

原則に従うときと従わないときの判断は必要です。

私たちが設計を行う一番の目的は、「迅速に完成させること」「変化に対応できること」です。

そのため、不必要な設計はコードをより複雑にしてしまい、本来の目的から遠ざかってしまいます。

このことを「オーバーエンジニアリング」と言います。

そのため、原則に従うか従わないかの判断は自分達で行わないといけません。

まとめ

ソフトウェアの設計はアジャイル開発を進めるための手段であり目的ではないことを胸に刻みながら、開発を行なうことが重要だと思います。

たくさんの原則があるので、自分で手を動かしながら、その原則の意味や効果を実感できたらもっと良い開発者になれると思います!

頑張るぞ!

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です