More than 1 year has passed since last update.

[経験則]プログラミングする前に頭に入れると得なこと

Last updated at 2023-09-23Posted at 2023-09-23

プログラミングする前に頭に入れると得なこと

結論を先に言うと

これは自分が今までたくさんコードを書いていく中で

後から自分が気づいて後悔したことでもあり、

プログラミング構造上の利点がすごくあるので紹介してみます。

もし大きなプロジェクトなどでこれをやってしまうと。

後々すごいめんどくさいことになってしまうんです。

その理由を説明したいと思います。

仮に、アバターキャラクターを変更するクラスを実装したとしましょう。

一見、一貫性が伴い、問題ない構造のように思えますが。。。

実はこのクラスはキャラクターの辞書は切り離したほうが良いのです。

代わりにキャラクター登録クラスを作成して

データと、そのデータをキャラクターチェンジクラスに渡す処理を書いた方が

コードの保守性が高まります。

なぜなら、辞書の形式を変えるかもしれないし、新しいジェネリッククラスを継承して

機能を拡張しようとしようものならばキャラクターチェンジクラスのプロパティデータは

そのままである保証はどこにもないのです。

特にこのようなソフトウェアの核に近い部分の実装では

内部アルゴリズムや、処理コードの一新は起こる可能性が高いです。

ゆえにコードをあとからリファクタリングする機会はとても多い、

そういった時に、そのクラスに存在したデータまでもが犠牲になり、

あ、旧データは消えたから今のデータ形式に合わせて、また作ってね

これが何度も発生するかもしれません。

なのでシリアライズされたデータを保持するようなクラスは。

その一新の影響があるクラスの中に記述するのではなく

切り離したほうが保守性が高まります。

大体のネットや記事にあるようなソースコードは

データと処理はセットになっています。（一部言語にもよるかもしれませんが）

基本、それは完成されたコードなのでもちろん問題はありません。

しかし、プロジェクトのコードは完成されてるわけではなく、何度も書き換えや一新が起きます。

なので、それと同じ感覚でプログラミングをするとあとで後悔を生むコードになってしまうかもしれない

という警笛でした。

それのみならず、公開されているソースコード例が実際のプロジェクトのニーズとは異なる場合があり。

学習段階で見る多くの例は、教育のためのシンプルなものであるため、

実際の開発現場での要件や複雑さを考慮していないことが多いです。

その中でもこのデータと処理の分離は、抑えたほうがいいよという駄文でした。

あとは皆さんご存知の、Solid原則としてデータのみならず、機能を疎集合にして構成するのは大事です。

ちなみにUNITYが開発しているECS（Entity-Component-System）アーキテクチャは、

データと処理の分離を必然的に行わなければならない非常に実践的なフレームワークになっているため、

このようなアーキテクチャに触れると体系的な理解ができます。