書籍・読書 Java

現場で役立つシステム設計の原則

投稿日:2017年10月6日 更新日:

増田亨氏(株式会社ギルドワークスのエンジニア)の「現場で役立つシステム設計の原則」という本を読みました。

きっかけは、次案件でSpringMVCを使って画面の設計以降を任されることになったのですが、ある処理をControllerクラスかServiceクラスのどちらに書くべきか?を判断したいからです。(この答えはp153にありました)

その判断材料になるぴったりの本でしたが、この本の内容を全て実践するのは難しいと思いました。

今まで良いと思ってきた設計・実装と違う点が多く、メンバーにこの本の内容を取り入れて設計する理由を納得してもらえる自信がないからです。

この本の内容は理想的な業務アプリ設計だなとは思うのですが、クラスを細かく設計段階から設計するのは工数的には難しいです。

また、クラスを細かく分けると、クラス設計図も増えてしまい、できればやりたくないです。

さて、ここまで読んでどう思いましたか?今私が挙げた、この本の内容を実践できない理由こそが、変更に弱い触りたくない設計・ソースを生み出している原因なんです。

保守性の高いソース

JavaServletをそのまま使った or struts 1.Xによって開発されたソースの保守改修の経験はありますか?

以下、特にびっくりした内容をメモしておきます。

現場あるあるのNG例

共通関数クラスはNG

getterメソッドはNG

オブジェクト指向言語を使って、手続き型プログラミングをしている

読んでいて感じたのは、私はこれまでJavaというオブジェクト指向言語を使って、手続き型のプログラミングをしてきたに過ぎないのです。

JavaはC言語という手続き型言語を踏襲しているため、手続き型言語としても書けます。

現場で「動けばいい」という言葉を聞いたことありませんか?その言葉を聞いたら、手続き型のプログラミングをしている可能性が高いです。

オブジェクト指向のメリットを活かした設計を学んでこなかったことが、手続き型のプログラミングをやっている理由です。

手続き型はコードの上から順に処理を追っかけていけばいいので、読みやすいは読みやすいからです。

ドメインモデルがSIerのシステム開発にそぐわない理由

上流工程、下流工程

日本のシステムエンジニアは多くの場合、担当範囲が決まっています。いわゆる、上流、下流というものです。

上流は要件定義~基本設計まで。下流は詳細設計~実装です。もちろん、中には基本設計から入るという人も多くいるでしょう。

一方、アメリカのエンジニアは上流を担当した人がそのまま下流もやるみたいですね。

ドメインモデルを取り入れるには、どれだけ業務を知っているかが命です。

日本の場合、業務を知っている上流の人とそれほど詳しくない下流の人が別れてしまっています。

ドメインモデルは変更箇所が1ヵ所になる

読めば読むほど、ドメインモデルは合理的な設計思考です。

何より、エンジニアが嫌いなスパゲッティコード、解析に時間がかかるソース、リスクの高いソース修正がキレイに解決できそうです。

その理由は、ドメインモデルは業務と対応しいるからです。

5章にSpringframeworkが登場

本章は超重要です。SpringMVCで開発する人は必ず読まないといけません。

Serviceクラスの役割をはっきりさせます。

Serviceクラスはシンプルに保たなければいけない。

MVCフレームワークで画面開発する人は7章を読もう

このサイトでもSpringMVCを紹介しています。

まずは引用します。

画面単位のプログラムは、ソフトウェアの記述を不要に複雑にします。-p198

画面ありきで開発すると、画面を表示するロジックと業務ルールを表現した業務ロジックが混在しがちです。-p199

まさに私が本書を買った理由が画面表示ロジックと業務ロジックの切り分けをどうするか?という点でした。

また、画面を作る時にやりがちなのが、プロジェクト固有の共通関数です。(CommonUtilクラスを見たことがあるでしょう。)

7章を読まずに更改するなかれ

7章を読まずに既存ソースを元に大幅に更改したとしても、見た目上はソースがキレイになり、最新のMVCモデルになるかもしれません。

キレイな、かっこいい、見易い、最新のトレンドに沿ったフレームワーク、ソースになったとしても、設計思想が従来のままだと同じ問題が繰り返えされます。

本書で説明されている画面表示ロジックと業務ロジックが分離されていないままだと、本質的な問題は解決されないままです。

一発目の修正依頼の時点で、影響範囲の広い、以前と同じ問題が露呈するでしょう。

ソフトウェアの変更容易性(いわゆる保守性)は、関心事に応じた適切な設計で解決できそうです。

保守性・影響範囲・ソースの見易さ

設計レベルとソースレベルに分けて考える。

設計レベル

  • どこに何が書いてるかわからない
  • 影響範囲がわからない

↓ドメインモデル採用

  • 関心事(修正内容)からどこに何が書いてるかの対応がとりやすい
  • 影響範囲が利用者の想定と一致

ドメインモデルの肝は、利用者の想定=関心範囲と設計が一致・対応していることにある。

ウェブ系開発はどうか?

ウェブ系開発はアジャイル方式をといれている現場が多いイメージがあります。

ですが、そこで言われてるアジャイルというのは、開発の単位を細かく区切っただけのようです。

また、スピード・スピード・スピードの旗の元に設計は省いてとにかくプログラミングをするというやり方が多いようです。

時代の流れに沿った開発思想

業務システムは必ず修正と拡張(保守)が入る。

それは、ビジネス環境の変化が早い時代になっているからである。

それゆえ、修正と拡張が容易できるシステムが望ましい。

ドメインモデルは本来のオブジェクト指向がもつ特質に沿った開発思想である。

変更容易性=保守性は重要

変更容易性は経済的価値が高いです。

なぜなら、変更が難しいと変更に要するコストが大きくなるからです。

一方、変更の容易なシステムは変更に要するコストが小さくなり、確保しておくべき保守エンジニアも少なくて済み、大きな差になります。

 

システムエンジニアとしてレベルアップ

本書を理解し、少なくとも提案することで、あなたは本書の内容を知らないエンジニアより一段階上のレベルで設計できるようになります。

言われたことをやる、滞りなくタスクをこなすだけのSIerエンジニアからサヨナラする日が近いかもしれません。

増田亨氏について

この本の触りは氏のslideshareがありますので、そちらを読んでもいいですね。

-書籍・読書, Java

執筆者:


comment

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

関連記事

no image

勉強するなら同じ本を5回は読め

最近ずっと読んでる本が、「現場で役立つシステム設計の原則」です。 通勤電車の30分ほど読んでいるのですが、最近やっと内容が理解できて、頭に入ってきました。 5回くらい繰り返し読んでいるのですが、やはり …

no image

時間のない人程、本を読むべき。

本ほど時間短縮になるものはない。 編集者が読みやすく編集してくれてるんだから。 ブログやネットの記事は素人が書いたものであるから、正確性を担保する必要もないし、読みやすく配慮するには時間がかかるから、 …

no image

【書籍】【HOW GOOGLE WORKS】Googleが今ほど巨大になれた理由

Googleが今ほど巨大になった理由は、「優れた検索エンジンを開発したから」だと思っていました。 もしくは、「優れたエンジニアを沢山雇っているから」さらに成長が加速しているのだと思っていました。 どう …

no image

【夢をかなえる方程式(苫米地英人 著)】を読んで

ブリーフ 人それぞれの考え方や見方 ブリーフがその人のパフォーマンスを決定する 人はブリーフに合致しない行動はとれない 例 禁煙、ダイエットに一時的に成功しても元に戻る。 ブリーフの集合=セルフイメー …

no image

人工知能解体新書 ゼロからわかる人工知能のしくみと活用

この本は良かった。実用例が豊富だから。IBM Watsonの解説が多いんだけど、それだけWatsonはAI産業で重要なポジションを占めているってことがわかった。G検定の推薦図書では具体例が少なくて、「 …