Skip to content
This repository was archived by the owner on Jun 15, 2023. It is now read-only.

Latest commit

 

History

History
69 lines (54 loc) · 5.9 KB

APPENDIX.md

File metadata and controls

69 lines (54 loc) · 5.9 KB

補足資料

Javaの開発や、OSSとして公開する際のライセンス選定、テストコードの考え方などについて参考資料をまとめました。

記載内容や参考記事の選定など、全般的に筆者個人の好みや情報収集の限界が反映されていることをご承知おきください。

Javaのライブラリ・フレームワーク

参考記事:

Javaにおけるロガーのややこしさ

参考記事:

個人的には slf4j + logback が2017年時点では比較的安定しており、利用者数も多く選択しやすい組み合わせだと思います。

OSSライセンスについて

個人で作ったツールにせよ、業務で作ったツールをOSSへの貢献で公開するにせよ、避けて通れないのがライセンスの問題です。

参考記事:

どのラインスを選ぶかだけでなく、個人的には以下の点にも注意が必要と考えています。（逆に言えば、これらの点が最終的なライセンス選定に影響してくる）

  • 他人のblog記事やSNS, 書籍などからソースコードをコピーするときの著作権とライセンスの確認・取扱
  • ライブラリをリポジトリに含めるか/含めないか、含めるとしたらソースコードを含めるのか、バイナリを含めるのか。
  • ビルドリリースに何を含めるのか。
  • ライブラリを改造して使うか、そのまま使うのか。

テストコードのススメ、その1（ライブラリの使い方を学びたい時）

  • 考え方の話になり筆者個人の主観になりますが、OSSのJavaライブラリはドキュメントが充実していないものも多々あります。
  • そうした場合、ライブラリのソースコードの、特にテストコードを見てみると使い方のパターンが載っていて、参考になることが多いです。
  • 特に Netty でそれを強く感じました。使い方まで細かくドキュメント化されておらず、じゃぁどうやってこのクラスを使うの？となったときに、テストコードを見るとなんとなく分かる感じです。

テストコードのススメ、その2（自分で開発する時）

  • コレ読んで下さい : http://t-wada.hatenablog.jp/entry/tddbook
  • あくまでも個人的な意見ですが、いくら「オブジェクト指向として正しい」コードを書いても、テストコードが無いとリファクタできず、容易にレガシー化します。
  • 逆にテストコードさえあれば、後からいくらでも必要に応じて設計や実装を洗練させることができるので、オブジェクト指向を学ぶより先にテストコードを書けるようになったほうが良いと思います。
  • テストコードを書けるクラス設計は、結果として疎結合で、副作用が少なくコードの責務が明確で、テストコード自体が使い方のドキュメント代わりになるという、メリットしか無い状況につながると思ってます。
  • とはいえなんでもテストコードを書くのは、機能によっては非常に難しくなるものもあり、時間の浪費につながります。
  • あくまでも個人的な見解ですが、まずはレイヤーで分けた上で、ユーティリティクラス / DBのモデルクラス あたりで、テストコードを書きやすくて再帰テスト実行のメリットが大きいところから手当をすると進めやすいかと思います。
  • ネイティブUIについてのテストコードは非常に難しいですし、Webアプリケーションが生成するHTMLのテストになるとE2Eテストとなりまた別のレベルになりますので、分けて考えてあげれば良いかなと思います。