Skip to content

Frontier Blog

for more efficient software development!!

本エントリは「TDD Advent Calendar 2013」の参加エントリです。

@t-wadaさんの最近行ったTDDの講演や寄稿についてに引き続きの記事を書かせて頂きます。

僕がTDDを実践しようと思い始めてからの日は浅く、ちょうど1年くらい前からになります。
そのきっかけとなったのが、Certified Scrum Developerの研修でした。
この1年、TDDの実践を1つのテーマとして仕事をしてきましたが、一度、初心に帰って見つめなおす意味も含めて、Certified Scrum Developer研修におけるTDDで印象に残っていることをまとめてみます。

テストは1秒以内に実行可能にする

頻繁にテストを実行するため、時間のかかるテストは開発中にテストを実行しなくなる。
実行しないテストを開発者は記述しなくなる。

テストを書く領域にもよるとは思いますが、意識しないで書くと、少し時間のかかるテストを書いてしまっていることはあるかなと思います。そして、これを実現するためには、

テストでは外部アクセスしない

テストはデータベース、ネットワーク、ファイルシステムなどにはアクセスしない。

話を最初に聞いた際には、かなり強力な制約と感じました。
しかし、この1年、なるべくこの原則に沿うように試行錯誤した感想としては、理想論を言うのであれば、この原則を守るにこしたことはないと感じています。

Webシステムのフレームワークなどでテストの仕組みをサポートしているものでは、実際にフィクスチャとして、データベースにデータを格納して、それを利用したテストを書くものも少なくないと思います。
このような仕組みでテストを書いてもよいのですが、テストのセットアップが煩雑になったり、テストコードと別の場所にフィクスチャを管理する必要があったりとで、テストコードだけを見た際の表現力が下がりがちなのが、その理由です。

じゃあ、どうするということで登場するのが、

Mockを効率的に使う

研修では、JMock2やJMockitを使いました。
慣れるのにも時間がいるとは思いますが、これが非常に強力ということを強く感じました。

Mockを効率的に使うことで、テストがシンプルになり、自己完結するようになります。
また、こちらの和田卓人さんのCodeIQの記事において、「現在時刻へのアクセスを行うインターフェイスを抽出」というところで自分が書いたコードを取り上げて頂いたのですが、Mockを意識することで、オブジェクトの責務がより明確で単純になるという設計技法としてのTDDの効果も促せるのではないかなと思います。

次に、よく自分がやってしまうことへの自戒として、

熟練のクライマーは手と足を同時に動かさない

僕自身、「テストコード実装」→「プロダクトコード実装」→「リファクタリング」というサイクルの中で、リファクタリングの際に、よくテストコードとプロダクトコードを同時に修正してしまいます。
そして、よく意識が発散して、破綻します。

今は現状のテストコードで、プロダクトコードのリファクタリングをしているのか、あるいは、プロダクトコードが完成したから、テストコードのリファクタリングをしているのか、それを明確に意識すべきですね。

また、これと関連して、

プロダクトコードとテストコードではリファクタリングの意識が少し違う

基本的には質の高いコードを保つという意味では、プロダクトコードとテストコードにリファクタリングの違いはないです。ただし、目的が違うコードなので、質の意味が違います。

実際に研修では、ある日にコードの重複があるから、リファクタリングしなきゃいけないよという指摘を受け、それを踏まえて、コードの重複をどんどん削除しました。テストコードにも、複数のテストケースで共通するような初期化のコードがあったので、それを一箇所にまとめました。
すると、翌日、頑張って重複を除去してくれたのは分かる。でも、このテストの初期化の部分のテストコードは、結果の検証と対応しているから、の敢えて重複を許容することで、テストコードの意図が明確になるという指摘をもらいました。

以上、研修のテキストを見ながら、思い出しつつまとめてみました。
どれも基本的なことだとは思いますが、何かの参考になれば幸いです。

次は、blacさんのMSTest‐Windows ストア アプリ開発の暗黒大陸になります。

C++のコードを書いていて嵌ったので、備忘録を兼ねて書いて置きます。

HTMLのパースするようなコードを書いていて、

のようなコードを書いてみたのですが、複数行にマッチするオプションがないので、少し探してみて、この記事を見つけて、

 

 

のように書いてみました。

うまくマッチしていると一瞬思ったのですが、少し長い文字列を入れると、Stack Overflowを投げるようになってしまいました。「regex_search stack overflow」というキーワードで検索しても、Stack Overflowの記事が引っかかるばかり。

結局、こちらの記事を参考に次のように修正して解決しました。考えてみれば当たり前なんですけどね。

 

 

コピペそのままはダメだよという教訓でした。

 

ついに最終日。

とても興味深い5日間だった。そして、色々とやりたいことが見つかった5日間だった。

1つ言いたいことは、Scrumを使った開発をやりたいと思いつつ、うまくできないと思っている人には、是非、受けてみて欲しい。

英語力とか、そんなことを気にせず、受ける価値のあるものだと思う。

 

 

大分、開発がメインの内容になってきていて、ようやくインフラからも解放されて、何かを作っているという感じがする1日だった。

プロダクトコードの変更はそんなに大きくないけれども、TDDのリズムに乗って、うまくリズムに乗れないことも経験できたし、コミットのタイミングについても色々と考えるところがあった。

 

ここまでScrumで取り組んで感じたいくつかの疑問点をBasに確認してみた。

 

・ペア作業をしている際に、複数のペアがごちゃごちゃになって作業することはよいか?

よく見られる状態なのだそうだ。

スタックするよりも流動的に動いていた方が良い部分もあるのだろう。

 

・ペア作業をしたときに、Daily Scrumは重複した内容を告げる必要があるのでは?

It depends on the team.

重複しているので、ペアごとに告げてもいいけれども、ペアをスイッチしたりと状況は色々ある。

これを書きながら、Daily Scrumの目的は何かを考えれば、それまでなのかなとは思った。

 

・ファイル名を変える、メソッド名を変えるなどのリファクタリングを行うと、リファクタリング中にテストが失敗するようになるが?

リファクタリングはテストコードとプロダクトコードの両方に行うべきことで、間違っていない。

 

ただ、これは今日の経験からだが、1つずつやらないと面倒を引き起こすことも。

プロダクトコードを1つ修正したら、テストコードが期待する形で失敗する。

テストコードでデザインを1つ変更したら、期待する形でプロダクトコードが失敗する。

これの繰り返しなのだろうなぁと。

 

後1日で、Mr. POにコミットしたところまで終わるかは・・・。

 

3日目からは、研修の内容が大分開発に集中するようになってきている。

とはいうものの、Jenkins、Jetty、Tomcat、Mavenと戦っていたと言えるかもしれない。

何より、今日はテストがパスしない状態でいることの苦痛をすごく感じた。

 

赤い画面を常に見せつけられて、パニック!パニック!と言われると、焦りますね。

 

同時に、グリーンに戻ったときの安堵感というか、居心地の良さは大きいですね。

グリーンが当たり前なのかもしれませんが。

 

そんなこともあって、今日はペア作業といいつつも、ペアを超えてガヤガヤやっていた気がする。

 

あとは、スプリントプランニングパート2というか、タスクの管理のやり方は工夫の余地があるかもしれない。

言葉で各タスクの内容で合意はとっていたつもりでも、実際にやってみると、それに関する小さなタスクが出てくることが多い。

そのタスクで行うか、新しいタスクで行うか。

 

今日、はまったのは、複数のTestSuitesで、Start Selenium Serverを実行すると、うまく行かない。

ブラウザを使ったテストは、1つのTest Suiteにまとめるのが一番なようだ。

CSDコースの2日目。

 

今日はRobot FrameworkとSeleniumとの連携だけに開発は時間を使ったような感じがする。

インフラの整備は大変。

BasがTDDのデモをしてくれたのだけれども、IDEとショートカットを使いこなした上での操作は魔法のように見える。

このくらいIDEを使いこなせると効率は全然違うだろうなと思う。

特にリファクタリングは迅速にかつ安全にできると思う。

 

今回の参加者は、中国人1人、タイ人1、日本人1人(自分)を含む7人でした。

 

スキルや知識がまちまちの状態で、コンセンサスをとることはとても難しいと感じた1日でもありました。

また、自分の英語のスキルがもどかしく感じた1日でもありました。

 

思い返してみると、今日は何をしたのだろうという感じでもあるのですが、きっとスクラムチームを立ち上げた際に陥りがちな問題をいくつも経験できた気がします。

一言で言うならば、今日はとてもよい素振りが出来たという気がします。

Splunkを使った仕事に関わらせてもらっています。

Splunk自体は中々作り込まれていて、画面をカスタマイズしたり、外部からRESTのAPIで操作する分には色々とでき、ドキュメントもそれなりにあります。

ただ、Splunkの上で動くSplunk Appという形で開発をする場合、ドキュメントが足りず、他のアプリの実装を見たり、試行錯誤するしかない部分も多いと感じました。

 

そんなわけで調べて見て分かったことを少しまとめておこうと思います。

Splunk Appの作成は、Splunkの管理画面から行うことができます。細かな手順は画面に従って行えばよいので省略しますが、作成すると、

$SPLUNK_HOME/etc/apps/<アプリ名>

というディレクトリが作成され、この中にSplunk Appのファイルが格納されます。

また、このディレクトリを手動で作成してもSplunk Appと認識します。

ただし、Splunk Appの中身を変えた場合は、Splunkの再起動を行う必要があります。行わないと、変更前のものとなるので、注意してください。

 

では、Splunk Appの中身は、次のディレクトリから構成されます。

  • default アプリケーションの設定を格納
  • local 個々の環境ごとの設定を格納
  • static 画像やHTMLファイル、JavaScriptライブラリなどの静的なリソースを格納
  • bin スクリプトを格納
  • appserver サーバサイドで動作するものを格納します。
そして、開発時はSplunkで提供される部品の組み合わせだけで開発できる場合は、defaultディレクトリの中のファイルを編集することになります。defaultディレクトリは次のようなものから構成されます。
  • app.conf アプリに関する情報を設定する
  • data/ui/nav アプリのメニューに関する設定ファイルを格納する
  • data/ui/views アプリのビューに関する設定ファイルを格納する
この他、Manuals for Splunk Administratorに記載のある設定ファイルが必要がある場合もあるかと思います。

DevLoveのAdvent Calendarに触発されて、自分にとってのProfessionalとは何かを考えてみました。

DevLOVE Advent Calendar 2012 “Professional” 20日目です。

Web開発に関する幅の広い情報を公開されている@kaji_3さんからバトンを受け取りました。

僕の情報はオンライン上にほとんどないので、僕にバトンを渡すコメントを書くのに苦労されたたのではないかと思います。

 

自己紹介

土肥(@takuo_doi)と言います。

学生時代に開発プロセスなどに興味を持っていて、就職後、医療ソフトウェアの開発会社に勤務しておりました。
今年に入ってから色々とアジャイル開発などに触れる機会があり、もっとやりたい、自分で実践してみたいと思い立ち、年内で退社して、1月からこれからアジャイル開発に取り組もうという会社でがんばることにしました。

11月にCertified Scrum Masterの研修を受け、丁度、今週は、Certified Scrum Developerの研修を受けにシンガポールに来ています。

 

僕にとってのProfessionalとは?

Professionalを辞書的に日本語にすれば「職業的」となるのだと思いますが、あくまで、僕の個人的な解釈では、Professionalと職業的という言葉は、同等でありながら別な要素を持っていると感じています。

職業的というと、契約に基づき、その契約に従って、行うべきことを、きっちりと遂行する。非の打ちどころがないイメージを持っています。ちょっと機械的といってもいいかもしれません。ちょうど、デューク東郷のような感じでしょうか。

そして、Professionalというと、もちろん、行うべきことはきっちり遂行するということは前提になるのですが、その考え方、姿勢に、ある種の思想が絡んでくるのかなと思います。デューク東郷に対比させるのであれば、僕の中では、ジェド郷士のイメージなのです。ストイックである世界に、金銭だけでない、どこか人間的な理想が入ってくるのです。

つまり、あくまで僕個人の考えですが、

 

Professional = 職業的 + 理想

 

なのです。

さて、僕自身エンジニアリングでお金をもらっているわけで、職業的エンジニア・Professionalなエンジニアではないとは言いませんが、上記の定義でいえば、エンジニアとして、職業的でも、Professionalでもない部分はあると思っています。たぶんゴールはないでしょうし、よりProfessionalであろうとしない限り、Professionalではいられないのでしょう。

 

よりProfessionalな自分 = 今の自分 + 更に職業的 + 更なる理想

 

を目指し続けることが必要だと思っています。

 

職業的であるために

では、まず、更に職業的であるためにはどうすべきか?

僕の場合は、「教えを乞うことをためらわないこと」だと思っています。自分で努力しないという意味ではないですが、自分の持っていない何かを持っている人がいるのであれば、その人に教えを乞うことは非常に大事だと思っています。

例を挙げると、10年前からアジャイルを実践してきている人たちがいる中で、僕はまだまだ日が浅く、実践としての経験が浅いです。そんな状況で、アジャイルのコミュニティなどに参加するのは非常に躊躇したこともあったのですが、思い切って飛び込んでみて、得るものは非常に多くありました。多分、一人で考えていては、到底行着つけなかったところを見ることが出来ました。同時に、自分が足りていない部分も見えました。

得るものを得て、足りていないことを知る、これは更に職業的であるため、そして、更なる理想を持つためにも大事なことだと思っています。

Certified Scrum Developerの研修は、シンガポール開催なので、当然、英語なのですが、僕の英語力で大丈夫なのだろうか?という不安は非常にありました。でも、きっと得られるものがあるはずと思い、無茶を承知で挑戦することにしました。

 

理想を持ち続けるために

次に、更なる理想を持つにはどうしたらいいか?

個人的に気にかけていることは、エンジニアとしてだけでなく、人間的に好かれる人でいたいということです。そして、そのために、「笑顔」でいることを特に気にしています。

理想を追い求めることは、通常の場合苦痛です。そんな中でも、笑っていることで、どこか心の余裕を持てると思っています。そして、笑顔の人とは僕自身、これからも一緒に何かやりたいなと思います。苦痛なことを一人で乗り切るのはとても大変ですが、苦痛を乗り越えようというときに、それを見守っていてくれたり、支えてくれる人がいることはとても大きな力になります。

また、笑顔でいることで、色々な人と接する機会が増えれば、それだけ多くの人の理想と現実を知ることができます。その中から、自分が自分の理想に近づくためのヒント、自分の理想をもっと大きな理想にするヒントが得られると思っています。

 

まとめ

最後に、自分がProfessionalだと感じる人とお会いすると、その人を見てすごい!と感じ、その人のようになりたいと憧れます。その入口は職業的に優れているからであって、その根底に理想がしっかりあるから一層魅かれるのだと思います。
自分の周りの人たちが、僕の仕事をやりたい!僕のように働きたい!そう思ってくれれば、僕もProfessionalな仕事をしていると思えるのかもしれません。

そんな理想を持ちながら、人に教えを乞うことをためらわず、笑顔で仕事をしていきたいと思います。

自分の働く姿を見て、自分の子供がエンジニアになりたいと思ってくれたら、うれしいですね。

 

バトンタッチ!

21日目は@kent4989 さんです。

ソフトウェア開発に関する書評とともに、その思想的な部分をブログで書かれています。「勘と経験と読経」というタイトルの「読経」という言葉が印象的です。

@kent4989 さん、よろしくお願いします!

CSM研修

11月 14

念願だったCertified Scrum Master研修を受講しています。

朝9時から夕方18時までの長丁場と思っていたのですが、驚くほどあっという間に時間が過ぎてしまいました。

 

Agile関連の集まりに顔を出させてもらう時によくあることですが、頭では分かっているつもりになっていることを、改めて目の前に用意されて分かっていなかったことに気付かされる。そんな内容でした。

今日の内容を一言で表すのであれば、

「プロフェッショナルなソフトウェアには勇気が必要」

ということでしょうか。