小さくまとめてわかりやすくするを参考に図などを使ってまとめました。駆け出しエンジニア・プログラマーの方達には早い段階で理解して頂きたい内容です。現場で役立つシステム設計の原則を読んでの気づきなどのまとめ記事を作ったのでこちらも合わせてご覧ください。設計なんて頑張ってやらなくてもいいのかもしれません。最近のほとんどのシステム開発においては、(使い物にならず即捨てられるケースを除けば)リリースしたらそこからは保守開発をほぼ必ず行い続けることになります。設計は作ってリリースして終わりでなく、そこからさらに保守開発し続けることにフォーカスしていると言ってもいいのかもしれません。設計はリリースでなく保守開発を見据えているイメージ設計の善し悪しは、ソフトウェアを変更するときにはっきりします。機能追加したり仕様変更といった保守開発の作業がカオスになります。設計のいろんなテクニックがあるのだと僕は思います。亨)設計において命名と小さく分けること関係と重要性ここまで設計が目指すところについて見てきたので、ここからは設計において最も基本で重要となる(個人的にそう思う)命名と関心事を分けることの重要性について見ていきます。略語でamt(金額を表してるつもり)よりamountの方がわかりやすい。ここまでは当たり前じゃんってなると思いますが、、、、もしクラス名にふわっとした命名をすると、そのクラスにふわっといろんな関心事が集まってくる。分岐やフラグ、パラメータやモードなどで処理がカオスになってくる。その結果、変更の影響範囲が危険で厄介になる。いったことに陥ります。(現場でリファクタリングや設計をするとこういうケース本当によく見かけます)例えば、変数名がふわっとしてしまうと最悪、色んな意味で1つの変数が使い回されてしまったりします。feeIncludeTax例えば、クラス名がふわっとしてしまうと全然関係のない関心事のメソッドがそこに集りがちです。orderLogic(){・・・}}例えば、メソッド名がふわっとしてしまうと一つのメソッドの中でいろんな処理をする神メソッドになりがちです。変更時の影響調査も大変になります。ならないように、とある小さな目的に特化してクラスやメソッドを命名するのが重要です。影響範囲が歪に波及しないように意識し続けることも重要です。強く関連するものが1箇所に集まり、どこに何があるかの整理整頓もしやすくなります。命名が設計(どこに何が書いてあるか整理)の基本であり、いろんな勉強会で登場するくらい重要であることがここまで見ると駆け出しエンジニアの方達にも納得できるかなと思います。保守開発で仕様変更や機能追加を重ねるごとに当時のクラスやメソッドに徐々にいろんな意味を持たせてしまって結果的に命名がぼやける。言うこともよくあります。(自分の経験ではこっちの方が陥りやすい印象)目の前の仕様変更や機能追加の対応を、リリース当時の命名の意図を無視して(人の入れ替えも激しく引き継ぎもろくにしなくて)、とりあえず処理をコピーしたり分岐ちゃちゃっと増やしてその場しのぎの改修を繰り返してる現場では良くこれになります。その結果、リリース当初は小さく目的に特化した命名やメソッド、クラスだったものが、いつの間にかいろんなフラグや分岐が入り混じってきてパラメータによっていろんなモードで動く巨大メソッドみたいなものが完成してしまいます。関心事を小さくメソッドやクラスに分けることに繋がる。変更時の影響の波及を小さい範囲に抑えることに繋がる。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。