「とりあえず仕様を満たす」から「機能性、保守性を高める」設計・コーディングへ|設計を学ぶ意味とは??

はじめに

今回は、アプリケーションの設計について自分が勉強したり9年間現場で設計する中で感じた、

設計の重要性、設計を学ぶ意味、設計ができる人材の価値などについて

まとめてみました。

 

 

ビジネススピード・コストの壁・品質担保・技術負債に立ち向かう開発現場のリアル

現場での泥臭いリアルな話と設計を学ぶ意味

少し想像してみてください。

保守フェーズに入ったとあるシステムの面倒を見ることになりました。

 

次々と追加機能実装、仕様変更が求められ、

設計書、モデル図、テストコードもなく、

仕様変更の内容だけみるとそこまで難易度が高くないため工数は確保できず、

影響調査を時間をかけてやる時間もなく、

既存機能に影響が出ないように既に実装済みのビジネスロジックと同じような処理を書いてその場をしのぎ・・・

 

簡単な仕様変更ですら危険なシステムで、

この状態でいかに品質担保取るかを考えたり品質担保の時間が仕事の大半(肝心の機能追加に使える時間はわずか)

プログラマーのモチベーションは下がって引継ぎはあまりできないまま人の入れ替えが頻繁に発生・・・

 

少し極端な例かもしれませんが、

こういった現場を経験されてきた方はまぁまぁおられるのではないでしょうか。

 

当たり前ですが

もし、

機能性(機能追加がしやすい)、

保守性(仕様変更などが安全にできる)

を考慮して設計できていればこの事態をある程度回避できたはずです。

 

機能性・保守性を向上させるための設計の1つとしてドメイン駆動設計があり、

例に挙げたような事態を回避するためにドメイン駆動設計の考え方や細かいプラクティスや

設計スキルを身に付ける必要があるのだと僕は考えます。

 

仕様変更や機能追加を楽に安全にするための設計をすべきで、

これこそがアプリケーションの設計をわざわざやる意味だと思います。

 

 

技術負債による毎年12兆円の経済的損失とアプリケーションアーキテクト不足

2025年以降、毎年の技術負債による経済的損失は12兆円とも言われており、

技術負債とそれ起因で例に挙げたような問題が

いたるところで発生していることがこの金額からもわかると思います。

 

一方で、

アプリケーション全体を機能性・保守性を考慮して設計できるアプリケーションアーキテクトが

不足しているのが現状です。

 

 

機能性・保守性を考慮して設計できるスキルを身につけることができれば、

(カオスなレガシーシステムをなんとかする代わりに)

市場価値は高くいろんな現場で引っ張りだこで、

給料も200万円近くは差が出ると思います。僕の周りではそんな感じ・・・

 

それくらい機能性・保守性を考慮して設計できるスキルをもつプログラマー・エンジニアは必要とされており、

これからさらに、

2025年の壁やDXの遅れ、技術負債に対してなんとかするために

いろんな企業が機能性・保守性を考慮して設計できる人材を確保しようと動くのではないかと思います。

 

逆に、もし、

機能性・保守性を考慮して設計できるスキルがなければ、

周りのプログラマー・エンジニアとの差別化が難しいです。

(他人に負けない専門分野がありそのスペシャリストであれば話は別ですが)

 

フルリモートワークが可能なこの職業を目指している方も多く、

とある言語でプログラムを書くだけなら、

いくらでも替えが効くようになってきていると個人的には感じており、

いつまでも安い単価で仕事をさせられてしまうのだろうなとも思います。

 

どうでしょう・・・

少し極端で、僕の推測も混ざっていますが、

機能性・保守性を考慮してアプリケーションを設計できる

スキルを身につけるということの意味を自分なりに持つことができているでしょうか??

 

まずは設計の目的や重要性を知り、

自分なりの設計スキルを磨く意味を持ち、

モチベーションを維持して学習し続けることが重要だと僕は考えています。

 

 

設計・コーディング時に僕が大事にしている考え方を紹介

ここからは、

僕自身が設計やコーディングの時に大切にしている考え方をいくつか紹介します。

 

ビジネスで扱うデータと関連するロジックをまとめて1箇所へ|クラスはロジックの置き場

クラスをただのデータの入れ物だと考え、

使う側が外からセットアップしてクラスの値を直接みて判断、加工、計算などなどをやり始めると

ロジックが至る所に散らばり、結果同じロジックが至る所にできがちです。

 

 

一方で

クラスを関連の強いデータとロジックの置き場所と考ると、

ロジックが散らばりにくく1箇所に集まり仕様変更が楽で安全になります。

 

 

この辺りの内容を具体的なサンプルコードを作りながらまとめた記事があるので、

そちらもご覧ください。

現場で役立つシステム設計の原則第4章を読んで|気付きや今後参考にしたいことなどをまとめてみました 良いコード/悪いコードで学ぶ設計入門第3章を読んで|気付きや今後参考にしたいことなどをまとめてみました

 

 

使う側がシンプルでありつづけられるように

先ほどのロジックと強く関連するデータを1つにクラスにまとめる例は、

使う側は想定外の値かどうかチェックなどをする必要がなくなり、

使う側がシンプルにできた例の1つです。

 

他にも、使う側が複雑な分岐処理を書かなければならないものを

strategyパターンを利用して使う側がごちゃごちゃしないようにしたり、

使う側が細かい値を見て回って何かしらの処理をしなくて済むようにカプセル化して

細かい値をあえて公開せず、使いやすい機能だけを外に公開してなど

いろんな工夫をします。

 

使う側が複雑になるということは、

複雑な処理が至る所にできてしまうことに繋がります。

また、たいてい使う側が複雑になるのは、

使われる側のクラスに記述すべき重要なビジネスロジックが足りてなかったり、

要求分析・モデリングの段階で表現できていない概念があったりするのが原因

であることが多いです。

 

その状況を放置するということは、

重要なビジネスロジックが至る所に散らばってしまうということに繋がってしまいます。

 

使う側が複雑になってしまうということはそういうことだと僕は考えています。

また、

自分の経験上これが原因で保守しずらいコードが出来上がっているケースが非常に多いです。

 

「ここに分岐追加すれば簡単に仕様満たせるし既存コードに影響でないや」

「他に影響でないように使われる側はそのままで使う側で何とかしよう」

 

こういう考えは要注意です!!!

使う側をシンプルにする具体例をサンプルコードを使って

まとめたのであるのでご覧ください。

現場で役立つシステム設計の原則第2章を読んで|気付きや今後参考にしたいことなどをまとめてみました 良いコード/悪いコードで学ぶ設計入門第6章を読んで|気付きや今後参考にしたいことなどをまとめてみました

 

目的に特化した狭い意味で名前を付ける

変数名、クラス名、パッケージ名次第で、

そこに何を記述すべきか、そこに何を置くべきか、

本当に共通化していいのか、あえて共通化を避けるべきかなどが変わってきます。

 

クラス名に、ユーザ、商品などといったざっくりした名前を付けてしまうと、

文脈が変わると微妙に役割や処理が異なってくる似たようなものが1つのクラスに記述され、

混乱してしまいます。

 

 

 

混乱してしまって微妙な共通化したものの

条件によって全く違う処理をするので

とてつもない分岐を中で書いて、

いろんなモードがあってフラグで制御して・・・

見たいな共通化クラスが作られて、しかもややこしすぎて使われず同じような処理を別に作られる。

というケースを現場で何度も見てきました。。。

 

こうならないように名前は目的に特化した意味を限定できる名前で付けるようにしましょう。

 

 

 

ビジネスで扱う概念とソースコードをマップさせる

これは僕が松岡さんのドメイン駆動設計の本で学んでいいと感じたので、

実際に現場でも実践しています。

 

要求やシステムで解決したいビジネスの問題領域についてモデリングをして、

理解して整理し、ビジネスのエキスパートとすり合わせて、

さらにそれをもとにソースコードとモデリング結果をマップさせておくことで、

 

ビジネス的にはシンプルな仕様変更なのに

システム的には影響範囲が広く工数が膨大になってしまったり、

影響範囲を特定すること自体に工数が膨大にかかってしまう。

という事態に陥らずに済みます。

(モデル図を使って会話することでビジネス側と開発側との認識齟齬も減らせます)

 

実際に現場でこの考え方を取り入れて、

モデリングやそれをもとにコーディングをしてみての気づきなどを

記事にまとめたので興味がある方は是非ご覧ください。

ドメイン駆動設計でモデリング〜サンプルプログラム・テストコード作成(まとめ記事)

 

 

紹介したのは一部ですが、この辺りの基本的な考え方をまずは抑えてから、

ドメイン駆動設計の細かいプラクティスやアプリケーション設計のテクニックを学習すると、

理解度がさらに上がると思います。

 

 

プログラマー・エンジニアとして設計スキルの基礎を固めるための2022年時点での僕のおすすめ勉強法

まずは、現場のソースコードを読んで気づいたことをまとめてみたり、

自分のブランチを切って汚いなと思うところを自分なりに修正してみたりしてみるのがいいと思います。

 

ただ、いきなり本を読んだり答えをインプットするより、

自分なりの気づきや自分事として考えたことの方が頭に残るからです。

 

次に、自分の気づきや考えと上級プログラマー・エンジニアの方との考え方とを比較してみてください。

現場の先輩に聞くと当たり外れがあるので、、、

 

設計やコーディングの基礎がコードの例と共にわかりやすく纏まっている

これら2冊を使うのが2022年8月時点での僕のおすすめです。

 

これ以上わかりやすく纏まっている本は現時点ではない気がしているのと、

僕自身、現場で設計の判断に迷ったときには、

この2冊を今でも参考にさせてもらう場面が多々あります。

 

 

 

これらを、

読む際にも現場のコードと見比べたりしてみるとさらにより理解が深まると思います。

現場のコードのどこが良いコードで悪いコードなのだろう??

なぜ悪いコードになってしまったのだろう??

本のどのテクニックを使えば良いコードにできるのだろう??

 

こういったことを考えたり、

実際にコードで書くことで設計思想の基礎が出来上がってくるかなと思います。

ある程度現場のコードの課題やこうすればよくなるかなというのが見えてきたら、

自分で一回現場のコードを1からリプレイスしてみるのも勉強になると思います。

その際設計の判断に迷ったら何度も本を見直して理解し直すことが大事です。

理解できているようで手を動かしてみると意外と手が動かなかったり僕自身よくありました。

 

 

ここからはおまけですが・・・

 

ドメイン駆動設計について学びたい人は

理解しやすくソースコード付きでまとめられているこれらの本で基本を学び、

ドメイン駆動設計 サンプルコード&FAQ

ドメイン駆動設計 モデリング/実装ガイド

 

 

現場のソースコードを自分のブランチで、

ドメイン駆動設計版でモデリングしたりリプレイスしつつ、

このあたりの本を読んでみたり、

 

 

 

 

さらに、

マイクロサービスアーキテクチャを学びたい人は

この辺りの本で学んでみたり、

 

 

 

 

 

 

このあたりの難易度の高い本を読んでも設計の基礎ができていれば、

理解もしやすいと思います。

 

 

コメントを残す

メールアドレスが公開されることはありません。

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください