「セマンティック バージョニング」(以下 semver )は、ソフトウェアにバージョン番号を付ける際の規則です。
semver では、バージョン番号は主に三つのフィールドに分かれ、それぞれ major, minor, patch と名付けられています。
(主にというのは、実は semver には仕様上はさらなる追加フィールドがあるのですが、今回の演習では扱いません)
例: バージョン 1.4.2 の場合、 major は 1, minor は 4, patch は 2 です。
今回はこの semver をテーマとして演習を行います。
なお、本演習は TDD を体験することを主眼としていますので、 プログラミングの速さを競っているのではない 点にご注意ください。機能を粗く速く実装することよりも、テストを書いて動かすことによるフィードバックを受けながら、リファクタリングを忘れずに着実に進めていくことの方が、本演習では重要です。
major, minor, patch 番号を与えてバージョンオブジェクトを作成し、さらに、そのバージョンオブジェクトの文字列表現を取得できるようにしましょう
- 例: major, minor, patch にそれぞれ
1,4,2を与えてバージョン 1.4.2 のオブジェクトを作成 - 例: そのバージョン 1.4.2 の文字列表現は文字列
"1.4.2" - ヒント: クラス名はどんなものが良いでしょうか
- ヒント: 使っているプログラミング言語の文字列表現化メソッドについて(あるならば)調べてみましょう
- ヒント: TDD のサイクル(TODOリスト - RED - GREEN - REFACTORING)を回してみましょう
あるバージョンオブジェクトが、他のバージョンオブジェクトと等しいかどうかを判定できるようにしてみましょう
- 例: バージョン
1.4.2は バージョン2.1.0と等しくない - 例: バージョン
1.4.2は バージョン1.4.2と等しい - ヒント: 使っているプログラミング言語の等価性比較メソッド、イディオムについて調べてみましょう
- ヒント: そろそろコードやテストコードのリファクタリングが置き去りになっていないか、確認してください。不十分な場合は、ここで整理しましょう。
semver において、 major, minor, patch フィールドはゼロ、または正の整数です。それ以外のものが与えられたら例外が発生するようにしましょう
- 例: バージョンオブジェクト生成時に
majorに-1を与えると例外を発生させる - ヒント: 今回発生させるべき適切な例外型は何でしょうか。言語毎の標準を調べてみてください。あるいは、独自の例外型を作成すべきでしょうか？
- ヒント: 言語によっては、例外に相当する概念（戻り値など）に翻訳してください
- ヒント: あるいは言語によっては、そもそもゼロと正の整数以外ではバージョンを作れないような新たな型を設計してみましょう
- ヒント: 使っているテスティングフレームワークで例外をテストする方法を調べてみましょう
- ヒント: 他にも例外条件があるかどうか、少し考えてみましょう(プログラミング言語によって違いが出てくる領域です)
semver におけるバージョンアップにはルールがあります
- 下位互換性のあるバグ修正を行う場合は patch フィールドをインクリメントする (パッチバージョンアップ)
- 下位互換性のある機能追加を行う場合は minor フィールドをインクリメントし、 patch フィールドを 0 にする (マイナーバージョンアップ)
- 下位互換性を壊す変更が入る場合には(バグ修正であっても、機能追加であっても)、major フィールドをインクリメントし、 minor, および patch フィールドを 0 にする (メジャーバージョンアップ)
以上の仕様を踏まえて、上記三種類のバージョンアップ機能を設計/実装しましょう。
- ヒント: ここからは設計の自由度が高くなります。どのような設計をするか相談しながら進めてください
- ヒント: 急ピッチで前に進むのではなく、問題の分割やリファクタリングを忘れないようにしましょう
あるバージョンを、他のバージョンと大小比較できるようにしてみましょう
- 例: バージョン 1.3.9 は バージョン 1.4.2 より小さい
- 例: バージョン 10.3.5 は バージョン 2.23.1 より大きい
- ヒント: 使っているプログラミング言語の大小比較メソッド、イディオムについて調べてみましょう
短縮URL: https://bit.ly/2myMHIF