第3回社内勉強会

本日第3回目の社内勉強会を開催しました。

今回は弊社の若手2人にプレゼンをしてもらいました。

以下が今回のアジェンダです。

  • SQL performance tuning (Oba 15mins)
  • Software testing (Denmark 30mins)
  • Break time (5mins)
  • Functional programming (Hideshi 20mins)
  • How to create test data (Hideshi 20mins)
  • Quiz (Hideshi 10mins)
  • Next topics (5mins)

 

一人目は弊社最年少のオバです。彼は初めは研修生という形で3ヶ月ほど弊社でWeb開発に必要な技術を学び、その後社員として働くことになりました。理解力や質問力など技術者としての基礎的な能力が高く、素直な性格も相まって入社して間もないにもかかわらず多数のプロジェクトで活躍してくれています。

彼は以前にMySQLのパフォーマンスチューニングのプロジェクトに関わった経験があるため、SQLのチューニングをテーマにプレゼンをしてくれました。

study_meeting_oba

内容としては無駄にデータを取得しないようページングをうまく使いましょうというものと、N+1問題についてでした。

N+1問題の原因としてはSQLのJOINの理解不足になりますので、今回は実際にPHPのコードを書いて違いを見せてくれました。最後にはN+1問題があるかどうかでどの程度パフォーマンスに違いが出るのかをデモで実演してくれました。以下がその資料です。

開発の初期段階からこのような形でパフォーマンスにも注意を払いつつ実装することで、運用中にだんだん遅くなるといったトラブルを事前に回避できるようになるかと思います。また弊社では日常的にコードレビューを行っており、そういった問題の早期の発見ができるような仕組みづくりも行っています。

 

次にプレゼンしてくれたのはデンマークです。彼は現役の大学院生で先のオバと同じ時期に研修生から社員として入社しました。彼の担当は主にQA(Quality Assurance: 品質保証)で弊社で開発したシステムを日々テストしてくれています。仕様を正しく理解し、それに基づいてしっかりとテストをしようという姿勢は我々を安心させてくれます。

今回は単体テストと結合テストのセオリーについてプレゼンをしてくれました。

study_meeting_denmark

以下がそのプレゼン資料になりますが、まずは単体テストと結合テストの違いをVモデルを絡めて説明し、その後各テスト工程の方法論について説明してくれました。

 

単体テストでは画面上のフォームに入力する入力値のパターンを同値分割と境界値分析を用いて、効率的に洗い出す方法を紹介してくれました。

用語について簡単に説明しますと、同値分割は入力値の下限と上限を境界として、入力値の集合を3つのグループに分割します。各グループからそれぞれ代表値を一つ選び出し、それを入力値として用いるものです。

境界値分析については、入力値の下限と上限の境界周辺の値を入力値として選び出す手法で、例えば1から10の値を受け付ける場合の境界値は0, 1, 10, 11になります。

実際にはこれらが複合的に用いられ、場合によっては複数の入力フィールドを組み合わせでテストするようなケースもあったりします。今回の例では時間と分という組み合わせに対して、時間を縦軸とし分を横軸とするような図から同値グループを洗い出し、その中からどのグループの値を用いてテストすると効率が良いかといった応用的な内容も披露してくれました。

結合テストについては状態遷移図を用いて画面とサーバサイドの処理の関連を視覚化し、そこからどのように画面遷移のパターンを洗い出して漏れなくテストするかという話をしてくれました。この状態遷移図を使うと正常系だけでなく異常系も見える化できるため、開発者はもとよりQA担当にとっても有用と感じました。

単体テストは開発者も行うことになっていますので、今回のプレゼンをきっかけに全体的な品質がより一層向上することを期待したいと思います。

 

次は私の番で、関数型プログラミングに関して手ほどきをしました。というのも最近の流れとして、テスト駆動開発が品質を担保するための一つの重要な要素になってきていることと、継続的インテグレーションにより自動化テストをデプロイの度に実行し、修正によるデグレードを抑えることで安定的な品質を担保することがより重要になってきていることが挙げられます。

テスト駆動開発を行うためには副作用を局所化し、処理をなるべく小さい単位で実装し、テストプログラムを実装しやすくする必要があり、そのためには関数型プログラミングから得られるものが多いと考えたからです。実際のところ弊社ではJenkinsを導入しほぼ全てのプロジェクトで自動デプロイを行っていますが、幾つかの制約によりテスト駆動開発については社内で検討をしている状況となります。今後のためにも、少しづつこういった形の付加価値をご提供できるような体制作りをしていけたらと思っています。

またJavaScript界隈ではリアクティブプログラミングが話題になっていますが、その便益を享受するための予備知識として必要になると感じています。最近はReact.jsの案件の引き合いなども来ていることから、そういった案件にも対応できるよう技術的な基礎体力の向上にも寄与できればと思っています。

study_meeting_hideshi2

以下がプレゼン資料になりますが、パラダイムシフトって何、関数って何というところから始まり、手続き型プログラミングと関数型プログラミングの違い、関数が第一級の値であるということ、イミュータビリティとミュータビリティ、参照透明と副作用、再帰、クロージャ、遅延評価と正格評価といった関数型プログラミングの主要な用語を簡単な例を交えつつ紹介してみました。

ちなみに関数型プログラミングをするには関数型プログラミング言語を使わなければいけないということはなく、PHPやRubyといった副作用を許すような言語でも関数型を意識して書くことは、ちょっとしたコツがいるかもしれませんが十分可能だと思っています。関数の役割を明確にし、副作用を局所化し、必ず値を返すようにする、これだけで十分メンテナンスしやすいものになるかと思います。そして皆が、どうしたら保守性の高いプログラムを書けるようになるかについて考えるきっかけになれば幸いに思います。

 

次も私のプレゼンで、テストデータをなるべく品質を損なわず効率的に作る方法を紹介しました。

テストデータの作成は仕様を満たしているかどうかを確認するための重要な作業で、これの出来次第でソフトウェアの品質が大きく変わってきます。仕様が複雑になればなるほどそれを検証するためのより多くのデータが必要になってくるのですが、かといってあまりやり過ぎてしまうと納期に間に合わなくなると言うジレンマがあります。そのため単体テストレベルではなるべく最小限の手間で仕様を満たすことができるよう効率的にデータを作る必要があるのですが、そのコツについて少しお話をしました。

テストデータのサンプル

前回とはまた違った趣でしたが、これはこれで面白い会になったのではないかと思います。

ゴッドフリーもご満悦の様子です。

godfrey

広告

オフショア開発における国際化機能の活用による開発効率および品質向上対策について

いわゆるフルスタックと呼ばれるWebアプリケーションフレームワークには国際化(i18n)や地域化(L10N)という機能が付いていて、一般的にはグローバル展開するようなWebサービス等でユーザの言語設定に合わせて表示する言語を切り替えるというような使われ方をします。

今回はこの機能(以下国際化という表現を使います)を使ってオフショア開発で品質や開発効率を上げるための方法についてお話ししようと思います。

フィリピンでのオフショア開発を通じて、いわゆる言葉の壁というものを感じているというのがそもそもの動機としてありました。弊社では日本のクライアント様が大半のため、クライアント様とのコミュニケーションには日本語を用います。当然開発するWebサイトやアプリも日本語オンリーというものが多いです。

一方で社内では基本的に英語を用います。そのため開発時には日本語を英語に翻訳や通訳をするという必要性が出てきます。開発者からの問い合わせも例えば、「このHTMLや画像に書いてある文言の意味を教えてください」とか「エラーメッセージにはどのような文言を表示すればよいか」といったものが多かったりします。

ブリッジSEという役割はそのためにあるのですが、とは言うもののある程度の規模の開発になると開発者の数も増え、同じような質問を受けることもままあったりします。開発者はよくWebブラウザ上の画面をGoogle翻訳して理解に努めたりしているのですが、語彙があまりにも特殊な場合は翻訳が正確でなかったり、翻訳に一手間かかるという事情もあったりしますのであまりいい方法ではないように感じています。また、これはシステムの規模や要件の複雑さにもよるかもしれませんが、システム内で用いられる語彙は用途が限定されていることが望ましいと思っていまして、それをGoogle翻訳に一任してしまうともしかしたら誤解を生み出すことになるかもしれません。

そこで国際化の機能を使って、クライアント様やブリッジSEの画面には日本語を表示し、開発者の画面には英語表示するようにすれば、開発者は文言やエラーメッセージの内容を正しく理解できるようになり、本来やるべき機能の開発に集中することができるようになります。

先日とあるプロジェクトでこの国際化の機能を導入したところ、開発者からは思いのほか好評でしたので、まずはそのスクリーンショットをお見せしようと思います。

こちらがブラウザの言語を英語にした場合で

eng

こちらが日本語の場合です。

jpn

画面上の文言だけでなく、アラートやエラーメッセージなども言語設定に合わせて可変にしています。

弊社ではCakePHPというWebフレームワークを主に使用していますので、これをベースにご説明しようと思いますが、これは他のフレームワークにも応用が利くかと思います。

まず全てのHTML上の文言、アラートのメッセージ、バリデーションエラーメッセージをpoファイルに記述していきます。

CakePHPではapp/Localeというディレクトリに各言語ファイルが格納されることになっており、英語と日本語のファイルは以下のファイルに記述します。

app/Locale/eng/LC_MESSAGES/default.po
app/Locale/jpn/LC_MESSAGES/default.po

以下のようにmsgidとmsgstrを対で書いていきます。msgidには一意かつ任意の文字列、msgstrには実際に出力される文字列を記入します。英語と日本語のmsgidが一致する必要があることにご注意ください。

msgid "title_is_required"
msgstr "Title is required"

msgid "title_is_required"
msgstr "タイトルは必須です。"

使い方としてはModelにあるバリデーションメッセージに以下のようにmessageの部分にmsgidを指定します。

model

HTMLテンプレートのctpファイル内では以下のように__(‘article_title’)のような形で使います。

ctp

また、国際化を行うにあたってもう一つ重要な点としてボタンなどのUI部品になるべく画像を使わないというが挙げられます。

これまでボタンなどのUI部品には画像を使うことが一般的だったかと思いますが、最近はフラットデザインの普及によりUI部品に過度な装飾が求められなくなってきていることと、CSS3を使うことで画像を使わなくても見た目の良いUI部品を作ることができるようになってきたということもあり、画像の利用頻度は以前と比べると減ってきているように感じます。

画像の代わりにCSSを使うことで、ボタン上に表示される文言をテキストとしてHTML上に配置することができるようになりますので、Webフレームワークの国際化機能をこれらのUI部品にも適用することができるようになります。

ボタンは画面遷移や処理を実行するための重要な部品の一つですので、このボタンの振る舞いを正しく理解することが品質を左右することになります。

今後オフショア開発をご検討される際はこれらの点をご留意されると、お互いにより良い形で開発が進められるようになるのではないかと思います。

参考:

Wikipedia 国際化と地域化:https://ja.wikipedia.org/wiki/%E5%9B%BD%E9%9A%9B%E5%8C%96%E3%81%A8%E5%9C%B0%E5%9F%9F%E5%8C%96

CakePHP 国際化と地域化:http://book.cakephp.org/2.0/ja/core-libraries/internationalization-and-localization.html