はじめに
・処理内容は分かる
・コードも書ける
でも、
👉 「これ、どこに書けばいいの？」
で止まる人へ
例えば、
・とりあえず今触っているクラスに書く
・近くに似た処理があったのでそこへ書く
・動いたからそのままにする
👉 こんな経験ありませんか？
実務では、
・UI開発
・Web開発
・組み込み
・ミドル層
・ドライバ
・AI関連
など、
担当する層や言語が違っても、
👉 「どこに処理を書くべきか」
で悩むことがよくあります。
この記事の位置づけ（シリーズ）
この記事はシリーズの続きです。
・① 新人・初級PGが最初につまずくポイント5選
・② なぜ仕様書とコードは繋がらないのか
・③ 仕様書は読めるのにコードにできない人へ
・④ ソースは読めるのに処理が追えないのはなぜ？
・⑤ どのソースを見ればいいか分からない人へ
・⑥ 処理は追えるのに 「中で何してるか」が分からない人へ
・⑦ 処理は追えるのに「なぜそれをしているのか」が分からない人へ
これまで、
👉 「理解できない原因」
を整理してきました。
今回はその中でも、
👉 「処理を書く場所」
について整理します。
なぜ「どこに書くか」で迷うのか
理由はシンプルです。
👉 “誰の仕事か”が整理できていないから
例えば、
SaveUser(user);
この保存処理を書くとして、
・画面側へ書く？
・Serviceへ書く？
・Repositoryへ書く？
👉 判断できない
よくある状態
初心者の頃は、
👉 「動けばOK」
になりやすいです。
例えば、
private void Button_Click(...)
{
db.Save(user);
}
これでも動きます。
でも実務では、
👉 後からどんどん辛くなる
なぜ辛くなるのか
例えば、
・別画面でも使いたい
・APIからも呼びたい
・テストしたい
・処理変更したい
となったとき、
👉 UIに処理が埋まっている
すると、
👉 修正箇所が分散する
実は「役割分け」が重要
ここが重要です。
コードは、
👉 「役割ごと」に分ける
必要があります。
この「役割」のことを、
👉 責務
と呼びます。
難しく聞こえますが、
👉 「その処理の担当」
という意味です。
例えば、
画面表示の担当
通信の担当
データ保存の担当
のように、
👉 “誰の仕事か”
を分ける考え方です。
WPFだとこう分かれる
例えばWPFでは、
View
→ 画面表示ViewModel
→ 画面の状態・操作Service
→ 外部連携・業務処理Model
→ データ
という形で分けることが多いです。
これはWPF特有の話ではない
この考え方は、
👉 WPFだけの話ではありません
例えば、
・Web開発なら
→ Controller / Service / Repository
・組み込みなら
→ UI層 / ミドル層 / ドライバ層
・AI系なら
→ 前処理 / 推論 / 後処理
のように分かれることがあります。
👉 呼び方や構造は違います
でも共通しているのは、
👉 「役割ごとに分ける」
という考え方です。
つまり、
画面のことは画面側
通信は通信側
保存は保存側
のように、
👉 “似た役割の処理をまとめる”
ことが重要になります。
じゃあ、どう判断するのか
ここで重要なのは、
👉 「その処理は何のためか」
を見ることです。
例① 画面表示制御
IsButtonEnabled = false;
これは、
👉 UI状態の制御
なので、
👉 ViewModel寄り
例② DB保存
repository.Save(user);
これは、
👉 データ保存処理
なので、
👉 Service側寄り
例③ API通信
await apiClient.SendAsync();
これは、
👉 外部連携
なので、
👉 Service側
ありがちなミス
ここかなり多いです。
❌ とりあえず今いる場所へ書く
人は、
👉 「今見えている場所」
へ処理を書きたくなります。
初心者〜中級でかなり多いです。
UI開発なら
・画面コードに全部書く
・ViewModelへ集約する
・近くのクラスへ追加する
ミドル層なら
・共通Utilityへ追加する
・Managerクラスへ集約する
・既存制御処理へ混ぜ込む
AI開発なら
・推論処理へ直接書く
・データ加工を全部同じ場所へ書く
・後処理へロジックを混ぜ込む
👉 「今見えている場所」に寄せてしまう
すると👇
・どこに何があるか分からない
・修正箇所が散らばる
・同じような処理が増える
状態になりやすい。
なぜそうなる？
理由は簡単。
👉 “一番見つけやすい場所”
だから。
でも実際には、
👉 「書きやすい場所」
と
👉 「その処理の担当として正しい場所」
は違います。
判断に迷ったら見るポイント
重要なのはこれです。
✔ その処理は誰の担当？
例えば、
画面表示？
業務処理？
外部通信？
データ管理？
👉 まずこれを考える
✔ 他からも使う？
ここかなり重要。
例えば、
別画面
API
バッチ
からも使うなら、
👉 UIに閉じ込めない
✔ UIがなくても必要？
これも重要。
例えば、
「画面なくても必要？」
YESなら、
👉 Service寄り
可能性高い。
「動く」と「設計が良い」は別
ここかなり重要。
初心者の頃は、
👉 「動けば正解」
と思いやすい。
でも実務では、
👉 後から変更される
👉 再利用される
👉 他人が触る
つまり、
👉 “未来の修正”
まで考える必要があります。
正解は1つじゃない
ここも重要です。
実務では、
👉 絶対の正解
はありません。
でも、
👉 「なぜそこに置くか」
を説明できること
が重要です。
実際の現場ではこう考える
例えば、
画面専用？
共通処理？
業務ルール？
を整理して、
👉 “誰の仕事か”
で分ける
まとめ
「どこに書けばいいか」で迷う原因は、
👉 “誰の仕事か”が整理できていないこと
です。
そのため、
・画面の仕事？
・業務処理？
・外部連携？
・データ管理？
を意識することが重要です。
そしてこれは、
👉 WPFだけではなく
👉 言語や担当層が変わっても共通する考え方
です。
✔ 1つだけ意識するなら
👉 「その処理は誰の仕事？」
これを考えるだけで、
👉 コード配置はかなり整理しやすくなります
おわりに
実務では、
👉 「何を書くか」
だけでなく、
👉 「どこに置くか」
もかなり重要です。
最初は難しく感じますが、
👉 「その処理の役割は何か？」
を考えることで、
少しずつ整理できるようになります。
もし、
「これはどこに置くべき？」
「この役割分けで迷った」
などあれば、ぜひ教えてください。
今後の記事で取り上げていきます。
■ シリーズ記事
新人・初級PGが最初につまずくポイント5選
→ 初心者が現場で止まりやすいポイントを整理
なぜ仕様書とコードは繋がらないのか
→ なぜ「仕様」と「コード」が繋がらないのかを解説
仕様書は読めるのにコードにできない人へ
→ 「線で理解する」具体的な手順を解説
ソースは読めるのに処理が追えないのはなぜ？
→ 処理を追っていて迷子になる原因を解説
どのソースを見ればいいか分からない人へ
→ 起点からコードを追う方法を解説
処理は追えるのに「中で何してるか」が分からない人へ
→ コードの意味を理解するための「データの見方」を解説
処理は追えるのに「なぜそれをしているのか」が分からない人へ
→ 「なぜその処理が必要なのか」をコードから読み解く考え方を解説