システム開発で思うところ

Javaで主にシステム開発をしながら思うところをツラツラを綴る。主に自分向けのメモ。EE関連の情報が少なく自分自身がそういう情報があったら良いなぁということで他の人の参考になれば幸い

Java EE・Jakarta EE のメモ

JavaEE Jakarta EE Payara

全般

オープンソースソフトウェアへの取り組み： 勉強会資料アーカイブス ｜ SCSK株式会社

www.slideshare.net

Java EE 8で何が変わったのか? – Mushagaeshi.com

www.slideshare.net

GitHub - chiroito/weblogic-jee-quickstart

www.slideshare.net

GitHub - javaee/tutorial: The Java EE Tutorial

www.slideshare.net

Concurrency Utilities for Java EEをつかってみる #JavaEE - Qiita

マイクロサービス | 豆蔵デベロッパーサイト

OpenAPI

MicroProfile OpenAPI 3.0の新機能と既存機能の比較 | 豆蔵デベロッパーサイト

msa-rms-platform/platform-fw/src/main/java/io/extact/msa/rms/platform/fw/webapi/openapi/CommonOpenApiModelReader.java at 844516120363c0447fe349f384738db30870ef6a · extact-io/msa-rms-platform · GitHub

APサーバー

www.slideshare.net

https://blog.ik.am/entries/427

[Java]Payara MicroProfileでぱやぱやする - プログラマのはしくれダイアリー

認証

Java アプリケーションコンテナに依存しないユーザー認証 : まだプログラマーですが何か？

www.slideshare.net

Payara

Payara Documentation :: Payara Enterprise Documentation

とりあえずおさえておきたいGlassfishのチューニングリスト #Java - Qiita

JavaEEだけでここまで出来る！GlassFish+Eclipseで高速Webアプリ開発【環境構築編】 - 技術ブログ | 株式会社クラウディア

JavaEE7の環境構築 #glassfish - Qiita

GlassFishにリソースを追加する方法4つまとめてみた - なにか作る

glassfish へのリソース設定はリソースファイルを使うべし その１ - A Memorandum

glassfish へのリソース設定はリソースファイルを使うべし その２ - A Memorandum

glassfish へのリソース設定はリソースファイルを使うべし その３ - A Memorandum

https://donow.jp/skillup/?p=135

Loading...

Payara(GlassFish)でMariaDBのJDBC接続プールが作成できない - 行きあたりばったりエンジニアの日記

商用環境向けPayara サーバで行うべき設定 - A Memorandum

Jakarta EE

https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html

その他

データベースのメモ

DB

基本

「理論から学ぶデータベース実践入門」読んだ - $shibayu36->blog;

多分、この資料の勉強会（？）は、直接聴講したと思う。

RDBとNoSQLにみるDB近現代史 データベースに破壊的イノベーションは二度起きるか？ - エンジニアHub｜若手Webエンジニアのキャリアを考える！

設計

データベースオブジェクトの命名規約 - Qiita

DB スキーマ設計のガイドライン - Qiita

しょぼちむにデータモデル設計について教えてくださいの会 #syoboben - 資料一覧 - connpass

H2

毛嫌いされる今だからこそ、Java！ --- JPA編 ---- - Qiita

h2 databaseをリカバリする - Qiita

H2をインメモリで動かすときの注意 - Yamkazu's Blog

GitHub - vasouv/jpa-h2-payara: Demonstration of the embedded H2 database in Payara 5

JavaEE7の環境構築 - Qiita

リファクタリング

マイクロサービスの最難関、どうするDB分割？ | 日経 xTECH（クロステック）

ロック

JavaでRDBデッドロック検出 - Qiita

データベース - Webアプリケーションのデータ更新で楽観ロックを使う理由について｜teratail

i am BEST : 楽観的ロックに必要な悲観的コーディング（2）

排他制御のあれこれ - Qiita

他の人にも勧められる書籍

楽々ERDレッスン （CodeZine　books） [ 羽生章洋 ]

楽々ERDレッスン （CodeZine　books） [ 羽生章洋 ]

SQL 第2版 ゼロからはじめるデータベース操作 ゼロからはじめるデータベース操作 （プログラミング学習シリーズ） [ ミック ]

SQL 第2版 ゼロからはじめるデータベース操作 ゼロからはじめるデータベース操作 （プログラミング学習シリーズ） [ ミック ]

[rakuten:book:12782740:detail]

その他

MongoDBの様なNoSQLに勢いがあるのは何故ですか？SQLと比べてどんな利点や欠点がありますか？

www.slideshare.net

テストのメモ

Test

考え方

- JUnit 実践講座

http://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TM_Version2012.J03.pdf

これだけは覚えたい、ユニットテストを書くための４つのデザイン - Qiita

実践テスト駆動開発(GOOS)読んだ - Qiita

ユースケースからテストケースへの追跡可能性

【初心者向け】テストコードの方針を考える（何をテストすべきか？どんなテストを書くべきか？） - Qiita

speakerdeck.com

speakerdeck.com

www.slideshare.net

アサーション

JUnitの新しいアサーション assertThat - A Memorandum

標準出力のテスト

標準出力に結果を出すプログラムをJUnit 4.1でテストする方法 - 結城浩のはてなブログ

検証

http://tomoyamkung.net/2013/08/26/java-junit-list-assert/

JUnitでの例外テストの書き方 - Qiita

JUnit のテストメソッドを複数スレッドで実行する - 日々常々

テスト管理ツール

www.slideshare.net

www.slideshare.net

JUnit

JUnit5で変わるテストの書き方 - きしだのHatena

Spock

www.slideshare.net

Spockのドキュメントを読んだよ - Mitsuyuki.Shiiba

JavaのユニットテストにSpockを適用する - Qiita

Spockでデータベースが絡むテストを書くためにやるべきこと その１ - Qiita

Spockの知られざる機能 - うさぎ組

Spock1.1の新機能紹介 - うさぎ組

mike、mikeなるままに…: Spockで例外のテスト

その他

Ansibleのテストで使いたい8つのServerspec ｜ DevelopersIO

Commits · bufferings/tdd · GitHub

www.slideshare.net

リファクタリングのメモ

Java

自分向け。
過去に作ったものは、この考えに則っていないものは多々あるが、あくまで「今」の考え。多分今後も変わり続けると思う。

継承か委譲か

継承にするか、委譲にするか迷った時の判断基準

継承しているクラスのメソッドを拡張していないんだったら委譲にする

継承を使ったらコード量は減るけど、機能追加をするときに継承元のクラスの実装とかフィールドを見ないといけない。見ること自体はどっちにしても見るべきとは思うけど、数日経ってから「なんだっけ、このthis.hogeって？、となったりする。
もっとちゃんとした理由は調べれば色々あったりするけれど、こんな理由もあるというメモ。

委譲とインターフェースで余計な操作は公開しない

実装もありつつ統一操作も持たせたい時には委譲したクラスの操作で共有したい操作のみインターフェースで定義する。 それって抽象クラスと同じで、単に委譲実装をするから手間は増えるだけに感じるけど似て非なる実装。 なお、委譲の実装はIDEの機能を使えば そこまで大変ではない。

抽象クラスを使用しないことにムキになっているなっているわけではなくて、抽象クラスは基本的にテンプレートパターンのような「拡張」を前提とするものに限定しておいた方が良いのではないかな、というのが現時点の整理。

インフラやシステム環境のAPIにはラッパーを準備する

インフラやシステム環境は、後々、横断的な対応をしたくなることはよくある。テストの時にもモック化しやすい。過去の経験では日付や時間は操作できるようにしておく方が良い。少なくとも営業経過日のテストや日替わりの時刻変更をしなくて良かったケースは皆無だった。

継承を疑う条件

methane.hatenablog.jp

継承したクラスが継承元にはないpublicなメソッドを持っている時点で、一回疑うべきである。

カプセル化

カプセルは多少緩くても良い気がする

カプセル化としてフィールドやメソッドをprivateにする作法がある。むやみに拡張をさせたくないときに、そのようにしましょう、という作法という理解。意識せず機械的に作法的にそうしているケースもある。
ただ最近、多少緩くても良い気がするように段々となってきた。勝手に使用したり、拡張されてほしくないケースもあると思うが、それを開発時にすべて想定するのは難しく、だからカプセルに閉じ込める、というのは利便性が下がるように思い始めているから。 ということで、最近のメソッドにはprivateではなくdefault（無印）を使うようにしている。一応、フィールドは更新をされると想定外の挙動になる可能性があるのでfinalで更新不可にはしている。 おそらく正しい作法としてはインターフェースと実装をペアにしてコンポジションなりを出来るようにしておけば、それが一番良いのだろうとは思う。でも、ちょっと全部にそれをするのはシンドイ。。
内部実装が漏れるのは良くない、というのは分かるけど、特にフレームワークなど基底層の場合「デバッグなどで必要としている情報をクラスが保持しているのは分かったけど、アクセッサが無くて参照できない」ということに何度か遭遇すると「更新はしないから参照はさせて・・」と言いたくなることが多々あった経験から。当然だけれど、そういう操作については、ドメイン層のクラスから直接参照するのはNGだと思うので何かしらのラッパークラスを設けて必要最低限の操作のみを開放するという作法は実施する。
インフラ層（フレームワーク含む）をドメイン層から直接使用しないようにするのは、実装による使用不可にするというよりも、動的・静的解析によって使用禁止喚起することをプロジェクト毎の基準を持って実施するのが良い塩梅では無いかな、と思う。
実際の現場はカオスなので、少しでも開放すると既得権益となってしまって済し崩しで設計思想が破壊されてしまう可能性が十分あるので、なかなかそうもいかないというのは分かるけど、とりあえず自分の開発では多少緩くするのが現在の指針。

不変の作法

フィールドの不変の作法

  • プリミティブ系：final
  • List系：Collections.unmodifiableList()
  • Map系：Collections.unmodifiableMap()

インスタンス構築

newよりもstatic factory

構築するインスタンスの確定を遅れさせることが出来るので、newよりもstatic factory。緩いカプセル化と同じく、どういう要件で拡張をしたくなるのか未来は分からない。未来に対しては寛容でいた方が、後々幸せな事が多い気がする。
実装時の注意としてはコンストラクタはprotectedにすること。そうしないとサブクラスが作成できないから。

参考

いぬごやねっと

補足として、決して new が嫌いという訳ではない。作成するインスタンスを確定させておきたい強い意志がある場合は、newの方が良いと思っている。例えば独自の実行時例外。

パラメータ、必須はstatic factory、任意はbuilder

newよりもstatic factoryにする延長で、static factoryは必須項目、builderで任意項目という整理をしておくと使用時に分かりやすい気がする。
ただし、builderパターンは、パラメータの相反については表現しづらいので、任意項目だけれどstatic factoryが全くない訳ではない。static factoryであれば、相反は表現できる。

Builderパターン

2017/8/27追記

Effective Java の Builderパターンとその拡張 - がくぞーのメモ

私の認識が間違っていたかも。

命名

パッケージ名

パッケージ名は、単数形？複数形？ - Qiita

クラス名

うまくクラス名を付けるための参考情報 - Qiita

オブジェクト指向

おすすめオブジェクト指向練習方法 | サイバーエージェント 公式エンジニアブログ

リーンなコードを書こう：実践的なオブジェクト指向設計

コーディング

Null

2017/8/18 追記

  • 戻り値がNullかもしれない場合にはOptional

Java 8 "Optional" ～ これからのnullとの付き合い方 ～ - Qiita

セキュアなコーディング

www.slideshare.net

例外

段階的に理解する Java 例外処理 - Qiita

その他

DBリファクタリングの勘所と所感 - そーだいなるらくがき帳

パッケージの循環依存の対処

Java Maven

一般的にプログラムにおいて循環依存は良くないことと言われています*1。

とはいえ、Javaは循環依存をしていてもコンパイルエラーになることはありません。
なので気が付かない間に循環依存をしてしまっているケースはあるように思います。

とりあえず、パッケージの循環依存については、チェックするやり方がありますので、それを活用するのが良いと思います。 （本記事はmavenのjdepend-maven-pluginの使用例でもあります。）

blog.guildworks.jp

ところで、私もチェックを実施したところ、ちょこちょこと循環依存をしてました。

これからも同じように気がつけば循環依存をしてしまっているケースが発生すると思います。反省も含めて、どういう循環依存の実装をしてしまって、それをどういう風に対処したのか、というのを記しておきたいと思います。

コマンドパターンのような実装をしたい

デザインパターンのコマンドパターンのようなことをしたいと思って実装したら循環依存エラーになりました。

やりたかったこと

  • HogeController：共通の呼出窓口となるクラス。
  • FugaCommandHandler：Commandを実行するクラス。
  • FugaCommandManager：Commandを管理するクラス。
  • Piyo1Command、Piyo2Command：Commandクラス。

FugaCommandManagerで、Commandクラス（Piyo1Command、Piyo2Command）を登録して、 各CommandクラスはCommandInterfaceを実装して統一的な操作が出来るようにします。
また各Commandは個別機能ということでパッケージにまとめておきます。

機能としては、HogeControllerから呼び出したFugaCommandHandlerがFugaCommandManagerに登録した各Commandを実行します。

この例ではクラスが少ないので同一パッケージにしても良いかもしれないのですが、各Commandについては複数のクラスを使用しているので、個別のパッケージを設けることにしました。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample1-error: 循環参照サンプル１（循環参照エラー）

パス構成

org
└─vermeer1977
   └─sample
       └─circular_reference
           │  CommandInterface.java
           │  EnvironmentItem.java
           │  FugaCommandHandler.java
           │  FugaCommandManager.java
           │  HogeController.java
           │  Main.java
           │  
           └─command
               ├─piyo1
               │      Piyo1Command.java
               │      
               └─piyo2
                       Piyo2Command.java

ぱっと見た感じだと問題なさそうな構成に思っていましたが循環依存が発生しました。

循環依存になったと思われる理由

HogeControllerにて取得した実行環境情報EnvironmentItemを各Commandで使用するのですが、それが原因だと思われます。

対処例

FugaCommandManagerを独立したパッケージに分割しました。 こうすることで、HogeControllerのパッケージとPiyo1Commandのパッケージが直接依存する関係が、仲介するパッケージを経由する状態になり循環依存のエラーがなくなりました。
発想としては、UMLの関連クラスを緩衝材として実装するイメージ、もしくはDTOを仲介させることで直接参照をしないようにするイメージです。

GitHub

GitHub - vermeer-blog-circular-reference/sample1-ok: 循環参照サンプル１（循環参照エラーの解消）

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  CommandInterface.java
            │  EnvironmentItem.java
            │  FugaCommandHandler.java
            │  HogeController.java
            │  Main.java
            │  
            └─command
                │  FugaCommandManager.java
                │  
                ├─piyo1
                │      Piyo1Command.java
                │      
                └─piyo2
                        Piyo2Command.java

副産物

分割したことで、今後、Commandクラスを増やした時に改修するクラスがパッケージレベルで整理されているので見通しも良くなった気がします。

呼出元のクラスを引数にしたい

やりたかったこと

呼出元の情報を元に呼出先で編集処理をしたい。

循環参照あり

GitHub

GitHub - vermeer-blog-circular-reference/sample2-error: 循環参照サンプル２（循環参照エラー）

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      
            └─caller
                    Caller.java

循環参照になった理由

説明の余地のないくらい、しっかりした循環依存です。

対処例

呼出先のクラスCalleeで実際に操作したい機能を満たすインターフェースを作成して、引数の型を変更しました。

修正前は呼出元クラスCallerのインスタンスを呼出先クラスCalleeで参照したため循環依存になります。
修正後は呼出先クラスCalleeで必要となる振舞いを定義したインターフェースを呼出元クラスCallerに実装することで循環依存が解消されます。
参照する向きを変更したイメージです。
（ちょっと今回の例だと、何のどの概念をインターフェースとしたのか分かりにくいのが難点ですが・・）

GitHub

GitHub - vermeer-blog-circular-reference/sample2-ok: 循環参照サンプル２（循環参照エラーの解消）

パス構成

org
└─vermeer1977
    └─sample
        └─circular_reference
            │  Main.java
            │  
            ├─callee
            │      Callee.java
            │      CalleeInterface.java
            │      
            └─caller
                    Caller.java

実装の抜粋

  • Callee

calleeパッケージにCalleeクラスのメソッドの仮引数の型をCallerクラスからCalleeInterfaceに変更する

＜修正前＞

    public Callee(Caller caller) {
        this.caller = caller;
    }

＜修正後＞

    public Callee(CalleeInterface caller) {
        this.caller = caller;
    }
  • Caller

CallerにCalleeInterfaceをimplementsする

public class Caller implements CalleeInterface {

・・・

}

副産物

インターフェースを介することで、どのようなメソッド（振舞い）が呼出先として必要であるのか見通しが良くなりました。クラスのままだと、どのメソッドが使われているのか使用箇所の調査をしないと判別できません。

とはいえ、呼出元が呼出先の抽象概念の一部である、というのは少々宜しくないような気もします。基本的には素直に循環依存を解消するのであれば１つ目の例のように仲介するクラスを設けて、呼出元で中継するクラスを作成して呼出先に渡す、というのが良さそうに思います。可読性が落ちない程度で、仲介パッケージを作らなくても問題ないくらいの複雑度であれば、こういうやり方もありそうだ、という例にはなるように思います。

さいごに

正直なところ、始めは自分の作成した自分だけが想定される開発者なので循環参照の対応は無理しなくても良いかなと思っていました。ですが、実際、改修することで、見通しが良くなったように思います。

むかーしの話ですが、大規模SIer案件ではコードにインターフェースが使用されているものは、ほとんど*2ありませんでした。そういうこともあって「フレームワークなど抽象度の高い機能を実装しないのであればインターフェースを使うことはないだろうな」と思っていましたが、実際に自分で手を動かしてみると、そんなことは無いな、と思うようになりました。本記事もその一例のように思います。

*1:言語によってはコンパイルエラーになったりするみたいです。

*2:というか全く

新人エンジニアが読んでおいた方が良いと思う本の紹介

春もそろそろ近づいてきています。新人さんの季節ですね。

新人さんに限らずですが「こういう本を読んでおくと良いと思いますよ」と薦めている本がありますので、それを紹介したいと思います。

実際のところは「若いうちに読んでおけば良かった」という自戒の意味が強かったりします。
ここから書籍の紹介までは、おじさんの昔話なので、適当に読み飛ばしていただければと思います。

私は元々COBOLで金融系の開発をしていて、その後、PL経験を積んだ人間です。一応、物事を整理する能力は人並みにはあったということで最低限の仕事はしていたとは思います*1。とはいえ、OJTという名の下に仕事は現場で覚えるものと言い訳をして、物を作る基礎力の無い残念なエンジニアの典型でもありました。Javaでの実装経験が無くても、オブジェクト指向が分からなくても、設計書のレビューもしますし、プロジェクト管理もしますし、さらにはデバッグやプログラム改修もします。なんだか無茶苦茶ですね。でも、それが実態でした。プログラムの良いところは結果が出てくれるというところです。やり方はともかくとしても要件・仕様は把握しているので、そこを満たせば目の前の問題に限っては対処できます。また、幸いにもプログラミングについては、より詳しい技術者もいましたので、そういった方々と協力したチームを作ることで多くの問題も解決できました。PLやPMとして求められたのは、私の技術向上よりも、チームをまとめて大きい金額の仕事をしていくことなので、その意味では問題はありませんし、それも正解の１つだと思います。
ただ、私自身は大きな売り上げを出す人よりも、自分の力で１から物を作ることが出来る人に憧れがありました。だったら自分で行動すれば良かったわけですが、日々の仕事を言い訳に行動をしないままでした。そんな時、色々とあって大きなプロジェクトの開発プロセスに携わるチームに実質一人で参画できます*2。そのことが私にとって非常に良い転機になります。これまでやってきていた、お客様のシステム要件を理解することももちろん大切なのですが、システムを作ることそのもの（開発手法、プログラミング手法、方式検討など）をじっくり考えることが出来る時間が出来ましたし、情報収集・分析の一環としてVBAでツールを作ったりして、自分の手を動かして１から物を作る機会も得ることが出来ました。

そして、この頃から、ようやくシステムに関する本を少しずつですが読み始めます。そして思います「あぁ、こんなにサクッと読める本もあるのに、なんで私はもっと早く読んでいなかったんだろう。。あの時、知っていたら、もっと良い結果に導けたかもしれないなぁ」と。

とまぁ、そんな経緯もあって、私が読んだ本の中で、達人プログラマーになるというよりも、浅く・広く・難しすぎない・目を通すだけでも見ておくと後々良いと思う、という本を周囲に薦めるようになります。そして今回紹介している本はそういう経緯で選定した本です。

では、おじさんの昔話はこのあたりにして新人さんが読んでおいた方が良いと思う本を紹介していきたいと思います。

Javaアソシエイツ

SUN教科書 Java アソシエイツ (SJC-A)

SUN教科書 Java アソシエイツ (SJC-A)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

Sunテキスト Javaアソシエイツ EXAM 【310-019】 (SKILL-UP TEXT)

何から勉強したら良いのかなぁ、と思っていらっしゃる方であれば、まずこれらの本を薦めています。どちらの本でも良いですし他にもあります*3。ページ数が多いから前者、通勤電車で読むからコンパクトな方が良いというのであれば後者、など立ち読みして好みの方を選んでください。知っておいてほしい知識はどちらでも学べます。

言い過ぎかもしれませんが、この資格そのものに実際のところ何の価値もありません。なので合格を目的としなくて良いです*4。

では、なぜ私がこの本を進めるかというと「教科書」的な位置づけの本だからです。SIerで勉強というと、まず出てくるのが基本情報処理試験だと思います。こちらも悪いわけではないです。ただ情報分野への理解には良いですが、システムやプログラミングへの理解という意味だと良くはないです*5。良し悪しではなく目的が違います。

教材にすることでJavaで開発をする人にとって一通り知っておいてほしい知識が身に付きます*6。AWTとかSwingとか「今、それ使う開発はあるの？」という情報もありますが、知識として知っておいて損はありません。メンテナンス対象となっているシステムが使用しているケースもあり得ます。また、Javaは関係ないから、という人もいると思いますが、もしSIerで仕事をする方であれば、UML*7や継承など、オブジェクト指向での開発に必要となる知識は必要です。言語特有の知識はありますが、自分の開発言語に置き換えながら読むなどして、いろんな言語があるんだな、という学習の仕方もあると思います。

「この程度の事をわざわざ勉強しなくても」という方もいらっしゃるかと思いますが、むしろ「この程度の事」だからこそ、きちんと勉強をしておくことが大切だと私は思います。

もし理解を深めたいというのであれば問題集もあります。私は資格取得までしたので問題集まで読みましたが、私がまず知っておいてほしい知識と思っている内容は参考書で十分です*8。

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

徹底攻略 Javaアソシエイツ問題集[310-019]対応 (ITプロ/ITエンジニアのための徹底攻略)

開発現場の掟

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

開発現場の掟 (プロの鉄則) エンジニアが現場で生き残るための極意 (開発の現場セレクション)

実際の開発現場での経験を踏まえた知恵が書かれた本です。経験豊かなエンジニアからすれば当たり前であったり、平凡なことばかりかもしれません。でも、これから経験を積む入り口に立っている新人の方には有用な情報が多いと思います。

当たり前のように思うかもしれませんが、この当たり前が実際は難しいものです。

例えば、新人の方でも、自学してスクラムとかアジャイルとか、そういった開発手法を導入しよう、なぜ導入しないんだ、あぁだからSIerは・・・と思うことがあるかもしれません。確かにそういう一面もあるかと思いますが、それを取り入れない理由もあります。おじさんになると、そのあたりも勘案するようになったりしますが、若さゆえの衝突もあると思います。ひょっとしたら、正しい、間違っているは別にして「アジャイルの劇薬の鉄則」あたりが現場の経験としてあったためかもしれませんよ。

他にも仕事の進め方や、開発時に「始めからやっておけば良かった」ということなど、まぁそういう引き出しが色々と書かれている本なので、読んでおいて損はないと思います。

楽々ERDレッスン

楽々ERDレッスン (CodeZine BOOKS)

楽々ERDレッスン (CodeZine BOOKS)

データベースはシステムにおいてほぼ必須です。データベースを使わなくてもモデリングは必須です。

データベースの設計は、設計時の初期にシステムをモデリングする際に検討することが多いため、新人はなかなか経験できません。そして経験年数を重ねて設計工程に参画することになって、いきなりやれと言われます。そこから改めて過去の自分の携わったシステムを正解として自分なりに試行錯誤をすることになりがちです。でも、まだ「やれ」と言われて経験が出来るのであれば幸せかもしれません。

設計はセンスではなく技術なので、そうやって経験を積む中でより良い設計が出来るようになるわけですが、モデリングおよびデータベース設計は、やり直しのリスクが大きいため、始めから出来るだけ品質の良いものにしておきたいところです。そうすると案件的に「経験者優先」となってなかなか経験そのものを積むこと自体が難しいことの方が多いです。

では、本当に、その既存の設計や経験者の設計は妥当なのでしょうか？自分が設計したデータベースがただのデータの入れ物になってはいないでしょうか？

経験を補完するためには知識と疑似トレーニングが有効だと思うわけですが、紹介している本は、その２つを満たしていると思います。SQLについても基本的なところだけでなく、難解なものも事例として書かれています。この本は、モデリングだけ、SQLだけ、ではなくて、自分がモデリングしたものを実際にSQLで検索してみると、、という実践の流れまでを一通り押さえてくれているところが良いと思っています。

ひょっとしたら、本書を薦めつつ、新人さんがいきなりデータベース設計をすることは無いだろうということで、矛盾しているように思われるかもしれません。確かに設計そのものをすることは無いかもしれません。ですが、知識の習得や疑似トレーニングをしておくことで、目にするテーブル設計の意図を通じて仕様をより深く理解できるようになるのではないでしょうか。興味を持つと仕事が面白くなります。ER図を自分なりに紐解いていく中で、システムのイメージを掴めるようになります（それはモデリングの追体験かもしれません）。無機質に思えたテーブル定義が、システムを抽象的に表現していると感じるようになったら楽しいと思いませんか？少なくとも、私は、そういうことを楽しいと思うエンジニアさんと一緒に仕事をしたいです。

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

2019/4/19 追記

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ]

現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法【電子書籍】[ 増田亨 ]

オブジェクト指向の何が嬉しいの？
じゃあ実際にコードで表現するのは どうしたら良いの？
そのためには どういう設計をしたら良いの？
に対して、理解を助けてくれます。

ただし「これこそが答えである」とはしない方が良いです。
著者の増田さん（増田 亨． (@masuda220) | Twitter）も その時の自分の考えであって、今後も変わっていくと仰っています。

とはいえ、ここまで現場でたたき上げた経験の結果を記した書籍は ほとんど無いのではないかと思います。

私の書評

vermeer.hatenablog.jp

著者も参加されていた勉強会のメモ

vermeer.hatenablog.jp

Javaルールブック

Javaルールブック　?読みやすく効率的なコードの原則

Javaルールブック　?読みやすく効率的なコードの原則

最後に紹介する本は、ぐっとプログラミングよりの本になります。Java5までのコーディング規約です。今はJava8なので情報としては古いのですが、紹介している理由は新しい古いとは別の事なので問題はありません。

こちらの書籍を薦めている理由は、プログラミングでの「良い例」「悪い例」と比較してくれているところです。プログラムをする中で大切な要素に、レビューをしてもらう、という工程があります。その延長で「他人のコードを読んで勉強しましょう」と良く言われます。でも良いレビュアーに出会えないかもしれません。また、コードを読めと言われても闇雲に読むのも難しいですし、目の前にあるコードが読むに値するものか判断するためには、やはりそれなりに経験が必要です。でも、その経験そのものが無い状態では・・・というループになってしまいます。

その第一歩として、この本を薦めています。

その上で、より良いコードを書く技術の本はたくさんありますし、その中には平易なものもいくつもありますので、そちらの本を読むようにしていけば良いと思います。

最後に

紹介した書籍は「絶対に正しい事」とは限りませんし、私自身も紹介した書籍の全てが正しいというつもりもありません。プログラミングも設計も開発手法も、色々な「正しさ」を持っている人がたくさんいますし、好みの問題もあります。とはいえ、まずは土台となる基礎が無いと、そういった判断をすることも難しいと思います。
また、上述で紹介した本の後に読んだ方が良いと思う、割合と平易な本もいくつかありますが、それを言い始めるとラインナップを見ただけで、お腹が一杯になってしまうことになるような気がしましたので、私なりに厳選をしたつもりです。

これからエンジニアになろうとしている方にとって、紹介した本が一助になれば幸いです。

*1:おそらくですが、そういうSIerのシステムエンジニアと呼ばれる人は多いのではないでしょうか

*2:その時の上司に拾っていただいたというのが本当のところです

*3:私が読んだのは、この２冊です。

*4:試験料は馬鹿になりません、結構高いです

*5:無駄ではないです。というか無駄な勉強は無いです。

*6:お恥ずかしい話ですが、私はこの教科書的な知識すらありませんでした。

*7:クラス図だけだけど

*8:資格を受けるのなら黒本問題集は必ずやった方が良いです。参考書だけでは演習量が足りないです。