読書会(Clean Code アジャイルソフトウェア達人の技)第6回議事録

=============================================================================
Java読書会「Clean Code アジャイルソフトウェア達人の技」を読む会第6回議事録
=============================================================================

.. csv-table:: 開催概要

"日時", "2014年3月15日 10:00-17:00"
"場所", "川崎市教育文化会館第3会議室"
"出席者(敬称略)", "高橋(智)、岩室、遠藤、目谷、吉本、井上、小棚木、門脇、中島、松永、高橋(徹)(書記)"

議事
====

第15章 JUnitの内部
------------------

* p.338 「メンバー変数のfプレフィックス」
* うちの組織ではC++ではメンバー変数にfを付ける規約になっている、との紹介あり。
* m_を使うのはよく見かける → MicrosoftのMFCですね。

* p.340 この本の著者は抽象度を揃えよと言っているが、そうでないところがある。

* p.347 いまはStringBuilder使わずに文字列の+結合がコンパイラで置き変わるのでは？
* ちょっとしたコードを書いて評価してみたところ、StringBuilderを使っていた
* eclipseとjavacでは生成されたバイトコードに違いがある
* eclipseだと、StringBuilderをnewするときに1つ目の文字列をコンストラクタ引数に渡しているのでappend呼び出しが1つ少ない。
* eclipseはJavaコンパイラを内蔵しておりOracle JDKのjavacとは違うコードを吐くことがある
  * 宿題) eclipseでコンパイラをJDKのjavacにする設定があるか調べよう。

第16章 SerialDateのリファクタリング
-----------------------------------

* p.350 日付表現のクラス「なぜまた作るのでしょう？」
* p.448のソースコード 67行目からのJavadocコメントに理由が書かれている
  標準のDateクラスは厳密すぎる(日付だけ扱いたい、タイムゾーンは考慮したくない、という用途に使いずらい)
* Java SE 8のDate and Time APIではこの問題に対処している

* p.351「そこでまったく独自に単体テストを書きました」
* テストコードは1つのテストメソッドに多数のassertEqualsを書いている
* パラメタライズドテストを使うときれいにかける例ですね

* p.351 のリストはどんな意味？
* p.456のリストから次の変更がある
  * 数値のときに、0とか13とかが返らないように、再度 resultに-1を再代入
  * 文字列の比較をequalsからequalsIgnoreCaseに変えた
分かりにくいコード!

* p.407 「T6」バグの周辺は徹底的にテスト
* 「8割のバグは2割の人が作る」というのもあるよね。
* 「スキルと仕事のミスマッチ」は、レビューでは救えない

* p.352 「正しいアルゴリズムを以下に示します」
* 負の数の剰余は、処理系によって異なる
  * 例) -5 % 4 の結果
   * Delphi, C, Java, C#は、-1
   * Ruby、Python、Common Listは、1 (数学的にしっくり来る)
* 剰余演算の数値が負にならないよう調整している

* p.352 「更新履歴」
* ソースコードを入手できてもバージョン管理ツールにアクセスできない場合、更新履歴が書かれていると助かる
  * sourceforgeやGitHubなどで公開されているものはバージョン管理ツールにアクセスできるので、最近はそう多くないかも
* (話題から派生して) かつてCVSからSubversionに移行したとき、移行ツールもあったが信頼性が不明だったので、履歴は継承せずに移行、古い履歴を参照するときはcvsを見る運用にした。
  * バージョン管理ツールとしてCVSで困ることは？
   * ディレクトリが消せない
   * ファイルの移動が困難
   * コミットがアトミックでない、タグ付けでファイル一式をひもづけする際に裏でコミットが行われていると誤ったひもづけがされる
   * ブランチ、マージ大変

* p.398 「J1：ワイルドカードを使って、長いimportのリストを避ける」
* なんとワイルドカードimportを推奨している! えーっ
* C#はusingで名前空間までしか指定していないので、usingを追加したときにエラーが発生することがある。ソースコードでFQCNするか、エイリアスで型名を付け変えて回避する。

* p.353 l6 誤植「全体を<pre>で囲んでしまい。ソース内での書式が」
* 「全体を<pre>で囲んでしまい、ソース内での書式が」

* p.353 下l3 誤植「MonthConstants(リストB-3、474ページ)」
* 「MonthConstants(リストB-3、474ページ)」

* p.355 重複の排除
* しすぎると返って読みにくくなる(あちこちに飛ぶなど)ことがある
* 共通化の手法が「共通関数」だけでは読みにくくなるだけ
   例)なんでもutilパッケージにまとめる
* 分かりやすいかの基準は人それぞれなので、正しいかどうか

* p.355 脚注3 serialVersionUID
* コンパイラに生成を任せると、シリアライズ対象フィールド以外の変更(例、メソッド追加)で変わってしまうので、シリアライズデータの互換性を考慮すると自分で付ける必要がある。
でも、人の作業なので忘れることもある。この問題はとても難しい。この本ではプログラマは定義せずコンパイラまかせにしろ派
* Effective Javaではプログラマがちゃんと管理しろ派
* 永続化にシリアライズを使ってしまうと、データの移行が必要になってしまう。データ移行は大変な作業。
* Java Object Serialization Specificationでシリアライズされたデータのフォーマットは決まっている。頑張れば元のクラスが失われてもデータの復元はできなくはなさそう。

* p.357 SpreadsheetDateFactory
* メソッドがpublicになているけど、protectedでいいのではないか？

* privateフィールドの是非
* JUnitで、定数的なフィールドを参照したいことはよくある。privateでは参照できない。
* テスト原理主義的になるが、実装を信用しないという意図で実装の定数を参照せず、テストケースで仕様から定数を別に定義する考えもある。(テストコスト大)
* 聖戦勃発!

* クラスのメンバー記述順番
* 未だコーディング規約で、アクセス修飾子順(public,protected,-,private)というのがある。privateを-に変えたら位置を変えねばならない等面倒。
* eclispeのパッケージエクスプローラはabc順
* 並び換えのルールは設定で変更可

次回
----

次回はp.356の先頭(ソースコード)からです。

[ 戻る ]