第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

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中