エンジニアのコラム

【読書感想】現場で役立つシステム設計の原則

更新日:

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

きっかけは、次案件でSpringBootを使って画面の設計以降を任されることになったのですが、
ある処理を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モデルになるかもしれません。

  • キレイな
  • かっこいい
  • 見易い
  • 最新のトレンドに沿ったフレームワーク

になったとしても、設計思想が従来のままだと同じ問題が繰り返えされます。

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

リリース後の1個目の修正依頼が来たら、
影響範囲の広い、
以前と同じ問題が露呈するでしょう。

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

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

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

設計レベル

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

↓ドメインモデル採用

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

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

ウェブ系開発はどうか?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

増田亨氏について

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

【転職のプロが薦める】Web系自社開発のための転職エージェントランキング!

 転職満足度は『「いかに自分の希望にあう、条件のよい」企業から内定が出たか』で決まります。そのため、Web系企業に転職するときのエージェントを選ぶポイントは、「Web系企業の求人」をいくつ持っているかに尽きます。なので、総合大手よりも、Web系企業の求人を多くもつIT専門転職エージェントがオススメです。

ギークリー

  • Web系企業の求人数は9000以上とダントツに多い。
  • 「リクナビNEXTエージェントNetwork」にて、「紹介求人案件満足度部門」「カウンセリング・対応満足度部門」で1位獲得!
  • 「営業が強い」という口コミが多いが、その分熱心に求人を提案してくれる。
  • 無料相談のWEB登録は、履歴書・職務経歴書不要で、たった60秒で超簡単
  • 無料相談は東京・神奈川・埼玉・千葉で勤務できるエンジニアが対象。

レバテックキャリア

  • Web系企業の求人数が4000以上と豊富
  • 「GOOD AGENT AWARD」で「2018年金賞」受賞!
  • 転職業界の人間同士の会話でも、ITといえばレバテックとまず挙がる。
  • 無料相談のWEB登録は、履歴書・職務経歴書不要で、たった60秒で超簡単
  • 無料相談は東京、千葉、埼玉、神奈川、大阪、兵庫、京都、福岡で勤務できるエンジニアが対象。

ワークポート

  • 求人数は2000以上と上2社より少ないが、古くからIT専門として有名。
  • 「GOOD AGENT RANKING」で「転職決定人数部門」第1位獲得!
  • 無料相談のWEB登録は、履歴書・職務経歴書不要で、たった60秒で超簡単

-エンジニアのコラム

Copyright© SIerからWeb系自社開発に転職!失敗して感じたたった1つの後悔 , 2019 All Rights Reserved.