宮武良至10ヶ月前4/15〜4/19に行われた認定スクラムデベロッパー研修を受講してきたので、その内容をご紹介します。Bernsteinさんでした。スクラムの研修ではありますが、内容はエクストリームプログラミング(XP)とオブジェクト指向プログラミング(OOP)が中心でした。取り上げた内容を次に列挙します。受け入れ条件デザインパターンSOLID原則CREATE(コードの内部品質について)テスト駆動開発(TDD)ユニットテストのテクニックまた、座学での講義だけでなく、次のような実践的なワークも行いました顧客の要求を元にユーザーストーリーと受け入れ条件を作成する次々に変化していく顧客の要求から、デザインパターンを使いながらクラス設計を行う(それによって変更を受け入れやすい設計を実感する)ペアプログラミングでTDDをしながら、複数の連続したユーザーストーリーを実装していく特に3つ目のTDDのワークはもっともボリュームがあり、全体の4割弱には達していたかと思います。細かい内容を逐一説明することはできないので、私が特に印象に残った内容や気づいたことを中心にご説明していきたいと思います。TDDユニットテストの「ユニット」とは一番印象に残った内容は、TDDにおけるユニットテストの「ユニット」とは何か?という話です。私は、ユニットテストはクラスに対して書くものであり、TDDは全てのクラスに対するユニットテストを先に書いていくプラクティスだと思っていました。そのため、クラスを小さく分割しモジュール化していくほどユニットテストも単純なロジックだけをテストすることになり、意味のないテストになっていくのではないかと感じていました。今回の研修の中でDavidは、「ユニット」とは「振る舞い」の単位である、と説明していました。実際TDDのワーク中、ユニットテストはユーザーストーリーで定義された受け入れ条件に対して書いていきました。このやり方をしていくことで感じたメリットが、「リファクタリングをするときの方が、自由にプログラムを書くことができる」というものでしたリファクタリングの方が自由にプログラムできるTDDを実践すると、上記「振る舞い」のインターフェース、メソッドシグネチャを決めるところに一番気を使います。受け入れ条件の複数のパターンについて、RedとGreenを慎重に繰り返していくことで実装を形作っていきます。そんな中、モジュール化やデザインパターンを適用してリファクタリングしていく場面では、開発者の自由度が高くなっています。事前にGreenにしたテストがあるので、安心感もあります。そこが、TDDをしていて一番気持ちのいいところだと感じました。Refactoringの順で説明されます。今回TDDのワークをしていて、リファクタリングを行うのは新しいユーザーストーリーの実装に取りかかる前がよいということを感じました。今までのユーザーストーリーでは必要のなかった概念を取り込むためには、その余地を作る必要があります。その余地を作るために先にリファクタリングをして、そこに新しい概念をシンプルに実装する、というのがよりよい設計を見つけていく道なのかな、と感じました。デザインパターン研修の2日目は、ほぼ1日デザインパターンについての話でした。パターンとは何かという話に始まり、12のデザインパターンの意図を解説、最後にパターンを使った設計のワークショップを行いました。その中で印象的だったことをいくつか紹介しますパターンは共通言語なぜデザインパターンを学ぶのか、という理由の一つとして、Davidは共通言語、ということを挙げていました。パターンには、どんな問題に対してどんな意図で適用するのか、という情報が集約されています。開発者同士がパターンを知ることで、「ここはStrategyパターンを使ったほうがいいと思うよ」など、一言により多くの情報を込め、より意図を正確に伝えあうことができる、という説明がされていました。これをさらに考えていくと、GoFなど一般に知られたデザインパターンだけでなく、それぞれのチームで出てくる「よくあるやり方」をパターンとして名付けし、共通理解を育てていくのもよいプラクティスになるのでは、と思いました。研修のなかで、Davidは「デザインパターンの本質は意図である」と繰り返し述べていたのが印象に残っています。デザインパターンはクラス図で表現されることが多いですが、クラスの関係性は本質ではなく、意図を表現した結果に過ぎない、と話していました。パターンを使う際は、どんな問題を解決するために、何をカプセル化しようとしているのか、という意図を基準に考えなくてはならない、ということです。コードの内部品質コードの利用者はだれか印象に残った問いとして、開発者の書くコードにとって「ユーザー」は誰なのか、というものがありました。ソフトウェアのエンドユーザーとは別に、コード自体の直接のユーザーは開発者自身である、という話でした。この表現は個人的にとてもしっくりくるものでした。ユーザーの一つとして開発者を想定することで、内部品質(保守性)とエンドユーザーに向けた外部品質(機能性など)を同じ土俵で考えていくきっかけになるのではないかと感じました。CREATEその内部品質の指標として講師のDavidは次の6つの要素をあげていました。凝集性(Cohesive)非冗長(non-Redundant)カプセル化(Encapsulated)自己表現的(Assertive)テスト可能(Testable)明示的(Explicit)それぞれの頭文字をとって「CREATE」と呼んでいます。3の指標を選んで意識するといいよ、という話でした。David自身は、特にTestableが第一原理である、と話していました。テスト可能であることが、他の5つを高めていくためにリファクタリングする足がかりとなるからです。今回の研修でも、いたるところで「カプセル化」という表現が使われていました。クラスの凝集性を高めるために関連する情報をカプセル化する。デザインパターンの説明においても、各パターンの意図として「カプセル化」、という表現が使われていました。Methodの「オブジェクト生成のカプセル化」などです。適切なレベルで詳細をカプセル化し、それぞれの部品の抽象度を揃えてコントロールしていくことが、内部品質を高めることに繋がっていくのだろう、と感じました最後に最終日に、スクラムデベロッパーとしての認定を受けるにあたって、以下のような内容に同意を求められました。このことを忘れず、これからも認定開発者としてさらに高みを目指していきたいと思います。最後になりましたが、今回の研修の中でDavidが何度か言及していた本がありますので、それらをご紹介して終わりにしたいと思います。CodeはDavid自身の書いた本で、日本語訳が今夏に発売されるそうです。2019古い記事DXはシステム開発の問題ではなく、ビジネスの。