読書会(現場で役立つシステム設計の原則)第1回議事録

=============================================================
Java読書会BOF「現場で役立つシステム設計の原則」を読む会第1回
=============================================================

.. csv-table:: 開催概要

  "日時", "2018年8月18日 10:00 - 17:00"
  "場所", "川崎市教育文化会館第3会議室"
  "出席者(敬称略)","高橋(徹)、高橋(智)、岩室、芝村、藪下、小棚木、平山、吉本、小貫、井上、遠藤、常念、加藤(書記)"

はじめに
=========

* 初版第1刷の人と第2刷の人がいるみたい

* 技評のサポートページでエラッタが公開されている: http://gihyo.jp/book/2017/978-4-7741-9087-7/support

第1章小さくまとめてわかりやすくする
====================================

なぜソフトウェアの変更は大変なのか
----------------------------------

プログラムの変更が楽になる書き方
--------------------------------

* そもそもオブジェクト指向の説明がないような、なぜ修正が楽になるのかとか

  * 知ってる前提で説明していると思われる
  * そもそも OOD の話なのか OOP の話なのか
  * OOD の話であれば、ここで変数名が云々という話が始まるのに違和感がある
  * コードに現れる身近な話題である名前から、ドメインモデルの話に持ち込みたいという狙いかもしれない

* 専門用語とかで変数名が30文字とか40文字とかになるケースがある

  * 用語辞書を作って、プログラムの名前でどうするのかまでも規定したいところ
  * 用語辞書が肥大化するとメンテつらくなる・・・
  * 用語が決め切らない状態でコードが先行するパターン、用語が曖昧なままコード進めるパターンなどあるが、後者のほうがより辛い
  * Java なら変数名に Unicode 使えるので日本語使う手もある

* リーダブルコードだと変数名に単位を入れると良いという助言もあった

  * 単位系は単位系でライブラリで (型をわけて) 解決する手段もある
  * 型が増えるとデータベース連携が辛くなることがある

* リストのコードスタイルに違和感がある

  * `if` の後ろにスペース入れるかいれないか
  * カッコ内の先頭と末尾にスペースをいれるか入れないか
  * スタイルが異質なのは譲っても、スタイルにゆらぎがあるのはいかがなものか

* `taxRate()` は `double` か？ `int` に `double` かけて `int` に代入なので端数切り捨てとなるが、わかっていてやっているのか

  * 金額の計算に `int` はそもそも御法度では、 `BigDecimal` とか使うところ
  * まあ、ここはあくまで説明用のサンプルコードということで

* 重複コード、自動で調べられるツールがあったはず

  * IntelliJ の Locate Duplicates 機能

    * https://www.jetbrains.com/help/idea/analyzing-duplicates.html
    * 書記補足: 残念ながら、有償機能なのでした

  * JS の Linter 系
  * PMD
  * Jenkins プラグイン
  * etc...
  * サイクロマティック複雑度なども測れるものがある

* 送料クラスの例、これを使うのが `shippingCost` メソッドからだけだと過剰な気がする

  * オブジェクトのライフサイクルが短すぎる
  * まあ、今後これを再利用する前提ということで
  * DDD 屋らしいサンプル

* 業務に合わせてドメインオブジェクトを設計する・・・

  * わかりやすくなることはそうだが、その前にアーキテクチャが必要、業務の構造がそのままプログラムの構造になると思うか！？
  * オブジェクト指向勃興期に言われたことと全く同じ
  * フレームワークとか土台・グランドデザインが既にあるからこそ成り立つわけで

小さなクラスでわかりやすく安全に
--------------------------------

* 日付処理といえば、サマータイム・・・

  * DB によっては明示的にタイムゾーンを指定する必要があったりして面倒

複雑さを閉じ込める
--------------------

* `Customers` クラスの例、フィールドを `private` にすべきでは (Java なのでこの例はパッケージ内の別クラスからアクセスできてしまう)

  * 本文で `Customers` クラスの外部からできないようにするという説明があるので、このコードでは目的を果たせていない
  * そもそもこれまでのサンプルコードで `private` を書いたり書いていなかったりする
  * 可視性については P85 に言及があるが、あくまで `public` かどうかの話
  * Jigsaw 導入すれば蓋できるレイヤーは増えるが・・・
  * そういえば JDK 今後色々きえていくよね、CORBA とか、JAXB とか・・・ (脱線)
  * Java Day Tokyo 2018 の桜庭さんのセッション思い出した

    * セッション資料: http://otndnld.oracle.co.jp/ondemand/javaday2018/JSE-5

  * あ、アプレット・・・
  * アプレットの代替技術は？WebAssembly かな？

* Java 9 以降なら `Collections.unmodifiableList` の代わりに `List.of` も使えそう、と思ったが配列にして可変長にぶち込む処理が必要

  * Java 10 の `Collectors.toUnmodifiableList` と Stream API の組み合わせという手も一応ある

第2章場合分けのロジックを整理する
==================================

プログラムを複雑にする「場合分け」のコード
------------------------------------------

* P49 のコード、なぜプリミティブの `boolean` ではなくラッパークラスの `Boolean` なのか

  * ここでは意味がない気がする
  * Word で書いてるのでは・・・ (冗談)

* P57 のコードは不変ではないが・・・

  * まあ、不変は不変、ここはここということで

* Enum の要素が小文字なのは違和感があるが、 `valueOf` で引くために意図的やっているというのはわかる

  * Enum は便利だが DB 格納などでは考えないといけないところがある、動的に入れることもできないし
  * 動的に入れることができないのは仕方ないとして、MySQL では enum 型ある
  * JPA だと名前や ordinal でマッピングできるが、ordinal に依存したアプローチで良いのかはまた別の問題

* Enum 要素に日本語わかりやすい

  * クラス内の要素であれば良いが、クラス名も日本語にしてしまうと OS によって問題が・・・

* P64 のリスト中の `Set` は型引数 `State` を添えるべき

  * ちなみに `EnumSet` は `Set` インタフェースを実装している

* P65 `allowed` は `EnumMap` を使うべき

  * パフォーマンスが良い、Effective Java でも推奨されている
  * キーが自然順序になるおまけつき

* P65 `canTransit()` で `from` に終了を入れるとぬるぽで落ちるのでは？

  * 明らかにバグ

第3章業務ロジックをわかりやすく整理する
========================================

データとロジックを別のクラスに分けることがわかりにくさを生む
------------------------------------------------------------

* 共通関数でメソッドだらけになって使いづらくなる経験はある

  * ただ、データとメソッドをセットにすれば解決、ってだけの話ではない

* 「三層のそれぞれの関心事と業務ロジックの分離を徹底する」とあるが、業務ロジックは三層の一つの「アプリケーション層」の関心事と説明しているので (P69)、文章が破綻している

  * 「プレゼンテーション層」と「データソース層」から「業務ロジック」を分離する、であれば筋が通る

* 「Web アプリケーション用のフレームワークでは、データクラスと機能クラスを分けることを基本にしています」とあるが、この説明はちょっと・・・

* 「Java は、C 言語からの移行しやすさを重視して設計されました」は本当か？

  * 文法こそ参考にはしているが・・・

データとロジックを一体にして業務ロジックを整理する
--------------------------------------------------

* `PersonName` クラスのコードにコンストラクタか setter などを想像させる「・・・」がないので、全く使えないクラスになっている

* P81 で「オブジェクト指向設計の基本です」などと言い切っているが、これは OOD ではなく OOP ではないか

* パッケージの分割・命名も大事だけどそもそも設計を理解するためのドキュメントも大事だよね

三層の関心事と業務ロジックの分離を徹底する
------------------------------------------

* パッケージ依存関係の説明があるが、本当に入金・請求・出荷は顧客、商品には依存しないのか？

  * パッケージ依存の解釈にはいくつかあるので、議論が難しい

* 図3-4 の矢印、実線と点線の差異を説明してほしいかも、純粋に UML として解釈していいのか不安

第4章ドメインモデルの考え方で設計する
======================================

ドメインモデルの考え方を理解する
--------------------------------

* 分析クラスと設計クラスを一致させるという話だが・・・

  * 分析レベルでは設計を考えないという考え方もあるはず、例えば多重継承とかは考えずにモデリングするなど
  * 分析・設計・プログラミングの担当者が一致したほうがいいという点は確かに理想ではある

* 図4-2 で明細行から商品を直接持っていない (破線の依存関係になっている) のは、スナップショットを取っているからかな

----

本日は、 p.102 の「なぜドメインモデルだと複雑な業務ロジックを整理しやすいのか」の手前まで

----

[ 戻る ]