Permalink
Find file
Fetching contributors…
Cannot retrieve contributors at this time
185 lines (137 sloc) 11.4 KB

メンターのインターンシップメモ: 2013-06-18

2日目。以下を実施した。

  • 1日目に書いたEPUBから情報を抽出するスクリプトの整理
  • Emacsとzshの設定を紹介
  • コミットへのコメントサービスの研修
  • テストを書く
  • Travis CIを使う

1日目に書いたEPUBから情報を抽出するスクリプトの整理

1日目は、EPUBから必要な情報を取得するために使えそうなライブラリーを調査 し、実際に見つけたライブラリーを使って必要な情報を取得するライブラリー を使ってスクリプトを作ってもらった。これは、自分で調べてやってもらった。

スクリプトを確認したところ、よりよいコードにするためにクリアコードのノ ウハウを使えそうだったので、まずは1日目に書いたスクリプトを整理するとこ ろから始めた。

1日目のスクリプト

まず、コメントを書いているところに注目した。クリアコードでは、コメント を書かないといけないところは本当にコメントが必要なのかを考えるようにし ている。もし、コードに書いていることを重複して書いているのであれば、余 計なので削除する。もし、コードだけではわからないことが書いているのであ れば、コメントに書かれている内容をコードで表現できないか考える。コード で表現することが難しいのであれば、それは必要なコメントなので残す。

show_html_contentの中のコメントは削除 した。これは、コメントではコードで書いていることと同じことを書いていた からである。

XHTMLのURIを取得している処理の塊へのコメントは削除 した。このコメントはコードだけではわかりにくいことだった。ただ、処理の 塊をメソッドとして切り出すことでコメントで書いていることをコードで表現 できるようになったので削除した。

XHTMLのURIを取得している処理の塊へのコメントを削除しているとき、複数の URIを入れている配列の変数名についても考えた。元は uri_array となって いたが、これを uris にした方がよいかどうかである。どちらの名前でも複 数のURIが入っていることは伝わる。では、どちらの方が適切だろうか。違いは 配列であることが重要かどうかである。配列であることが重要であれば uri_array がよい。これは、名前を見れば配列であることがわかるからであ る。しかし、複数のURIが入ったコレクションであり、それが配列だろうがなん だろうが each で順番に処理できれば問題ないということであれば uris がよい。これは、名前を見れば複数のURIが入っていることがわかるからである。 特に考慮する必要のない配列かどうかは気にしていない。

今回のケースでは配列である必要はなかったため、 一般的なコレクションであることがわかりやすくなる uris を使う ようにした。

他のコメントについても同様に検討し、必要であればメソッドに切り出してコ メントに書かれていることをコードで表現するようにした。最終的にはコメン トをすべてコードで表現するようになり、コメントがなくなった。

メソッドに切り出すときのやり方についてもクリアコードでのやり方を伝えた。 メソッドに切り出す場合はコードの移動だけを行いインデントも含めてなるべく変更せずインデントの調整は別コミットにする というやり方である。こうすることにより、メソッドを切り出すときに本当に 切り出しているだけで他のことをしていないということがわかりやすいdiffに なるというメリットがある。

参考資料として クリアなコードの作り方: 意図が伝わるコミットのしかた を紹介した。

また、上記の作業中にコミットメッセージの書き方について以下の参考資料を紹介した。

なお、この作業はいくつか一緒にやった後は一人で考えて、疑問に思うところ は随時聞いてもらうやり方でやってもらった。何度か聞いてもらったし、より よい名前を出してくれたりしていた(例えば spineを使う など)ので、伝えたことは伝わっていたようだ。また、それはコミットを見る ことでも確認できた。

Emacsとzshの設定を紹介

作業をしている間、Emacsとzshで大文字小文字を区別せずに補完していたので、 大文字小文字を区別しないで補完するようにすると便利だということを伝えた。

Emacsの使い方を見ていたら、リージョンを指定してから置換していた。今まで は、リージョンを指定するのが面倒で使っていなかったが、後で使い勝手を試 してみようと思った。

コミットへのコメントサービスの研修

コミットへのコメントサービスの導入研修を実施した。

ゴールを理解してもらうために、コミットへのコメントサービス自体の説明か ら実施した。これは、今後の導入研修でもやった方がよりよくなると思った。 導入研修は シナリオ に沿って実施した。

よかった点は以下の通り。

  • 以前の導入研修のときよりも質問時間の回数を増やしたこと
  • よいコミットとよくないコミットの具体例を説明したこと
  • コードを実際に読んで議論する時間を設けたこと

今後改善したい点は以下の通り。

  • 一部よくないコミットの具体例を用意できなかったこと
  • コードを読むときに、初見のコードだと導入研修を受ける人が動作を理解す るので精一杯になることがあるので、サポートできるようにしておく

感想を聞いてみたところ、コードのよいところを探すのは難しそうだった。特 にそのドメインの知識やそのプロダクトが前提としている知識が不足している と動作を理解するのに時間がかかり、そのように感じるようだ。

研修を受ける人が持っている知識を事前にヒアリングできると適切な題材を選 ぶヒントになるかもしれない。

導入研修自体は、予定時間内で完了し、質問も活発で反応もよかったのでうま くいったと思う。

テストを書く

クリアコードでの開発方法を体験するために、ここからはテストを書きながら 開発する。

テスティングフレームワークは名前は知っているが使ったことはないというこ とだったので、RSpecとminitestとtest-unitについて簡単に説明し、その上で Rubyらしくかけるしオススメをしたtest-unitを使うことにした。

テストを書くにあたり、機能をライブラリーとして実装することにした。1日目 に書いたスクリプトのように単体で実行ファイルとして使うスクリプトだとテ ストしづらいからである。

どうして実行ファイルがテストしづらいかについては、入力と出力という観点 から説明した。テストとは指定した入力に対して期待した出力を返すかを確認 することである。実行ファイルをテストする場合は入力が引数・標準入力にな り、出力は標準出力になる。標準出力が正しいかを確認するには文字列として 比較する必要がある。これは、たとえ、結果が数値であっても、である。数値 の「3」を出力するかを確認するために文字列の「"3"」であるかを確認しない といけない。

一方、ライブラリーとした場合はRubyのオブジェクトとして比較できる。数値 の「3」かどうかを確認するには数値の「3」と比較すればよい。

入力についても同様である。実行ファイルの場合は文字列で渡さなければいけ ないが、ライブラリーならRubyのオブジェクトをそのまま渡せる。

テストを書くにあたり、テスト対象とする機能を選んだ。選ぶ基準は一番簡単 な機能とした。

入力はEPUBなのでフィクスチャーについても説明した。フィクスチャーとはテ スト用の環境を準備する仕組みおよびそのときに使うデータである。今回は EPUBファイルがテスト用に使うデータである。

こうして、 EPUBからタイトルを抽出するテストを追加 した。

Travis CIを使う

CI(継続的インテグレーション)を実現するために Travis CIを使う。これはGitHubにリポジトリーを 置いているフリーソフトウェアでは簡単に使えるからである。

CIについては知っているということだったので簡単に説明するにとどめた。動 かなくなったら早めに動かなくなったことがわかったほうが修正が容易である こと、手元の開発環境以外でのテストが失敗することに気づきやすくするため にCIが有用であることを説明した。

Travis CIは使ったことがないということだったので、Travis CIのアカウント を作って、GitHubにコミットしたらテストを実行するようにhookを設定した。

その後、 .travis.yml を追加し、Travis CI上でテストが実行されることを確認した。

この後、一緒にAsakusa.rbに参加した。Asakusa.rbでは一人でテストを追加し ていた。既存のテストと同じようなテストの追加方法はわかったのではないか と思う。