コミュニケーションの敷居を下げてプロジェクトの雰囲気をよくする

最近よく思うのは、コミュニケーションの敷居が低くなるとプロジェクトの雰囲気がよくなる、ということ。

ここで言う『敷居が低い』には2つあって、コミュニケーションが簡単にとれることと、その内容に親近感 (安心感？) があること。

ここ数年、Slack などのコラボレーションツールが広く使われるようになり、メールを使う機会は以前よりずっと少なくなりました。

一般的にチャット上のテキストは口語的なものが多いと思われます。また、絵文字や顔文字を使うことで表現豊かなコミュニケーションが手軽にできます。メール時代にあったような挨拶文 (「お疲れ様です、○○です。」のような前置き) を書く必要はありません。チャットはメールよりリアルタイム性に優れているため、コミュニケーションのサイクルが格段に早く感じます。

たまには雑談を交わすのも OK です。ノイズが気になるなら専用のチャンネルやルームを用意すればいいわけです。

お堅い現場ではそうはいかないかもですし、モノによりますが、このようなツールを使う環境を用意するのはそれほど難しくはありません。とはいえ、ゆるい雰囲気で使えるかどうかはメンバーの性格やノリによるところが大きいと思います。そんなときは誰かが率先してゆるい雰囲気を作る必要があります。

自分は決してそういうキャラではないのですが (たぶん)、ゆるい雰囲気を作るために、日々、顔文字や絵文字、おもしろ画像を率先してポストする役目をこなすわけです。

de:code 2017 テスト駆動開発の動画の鑑賞会をやってみた

今さらではあるのですが、先日、昨年の de:code 2017 で t_wada さんが公演されていたテスト駆動開発の動画をみんなで鑑賞するという会をやってみました。

今日は de:code2017 のテスト駆動開発の動画をみんなで鑑賞してわいわい意見を述べ合う場をやってみたけど、なかなか有意義な時間になってよかった https://t.co/wOrLq0vUZQ

— kntmr (@knt_mr) September 7, 2018

とはいえ、実際、de:code 2017 には参加しておらず、この動画も今年の春くらいに初めて見たのですが、内容がとてもよかったので「他のひとたちにも観てもらおう」と思ったのがきっかけです。

内容としては基本的なものかと思います。が、観たことがないという方はぜひ一度ご覧いただければと思います。途中、ライブコーディングのデモで TDD を紹介していますが、時間がない方は前半の概要と最後のまとめだけでも。(ライブコーディングのデモも非常に学びがあります)

大事なポイントとしては以下ですかね。

• 動作するきれいなコードには2つの道がある
• TDD のサイクル (Red-Green-Refactor)
• テストが予想通り落ちることを確かめる
• 仮実装、三角測量

(ちなみに書籍はこちら > テスト駆動開発)

特に、この 仮実装 や 三角測量 はよく使う手法ですが、TDD に限った話ではないだろうと思います。

例えば、新しいフレームワークやライブラリを試すときに小さいサンプルアプリを作ったりすることがありますが、ゼロからすべてを一気に作るのは難しいので、モックのデータを返したりして、範囲を絞りながら調査を進めると思います。これは TDD の『仮実装』と同じアプローチです。

あと、デバッグするときに、あるパラメータを渡すとこう動作する、別のパラメータを渡すとこう動作する、ということはこのパラメータを渡せばこう動作するだろう、と再現パターンを調べることがあると思います。これは TDD の『三角測量』と同じアプローチです。

おそらく、テスト駆動開発の中で実践している細かいプラクティスは普段からすでにやっていることなのかもしれません。

まとめ

自分も手探りながら テスト駆動開発モドキ を実践してみた中で大事だと考えているのは、テストから考え始めること (テストファースト) です。

テストから考え始めることで、仕様に対してどのように動作するべきか、ということを整理できてシンプルな観点として落とし込めるようになります。テストがシンプルになると、それに対する実装もシンプルになり易いです。これは実践してみて初めて気が付いたことです。

いきなり実装から書き始めるといろいろな条件を1箇所のロジックに詰め込みがちで、あっという間に複雑になります。当然、その実装に対するテストも複雑になります。そして誰もメンテできなくなるわけです。

ちなみに、鑑賞会のあとに参加者で意見交換したところ、やはり気になるのは既存のアプリにテストコードがないときはどうするか、ということ。正直、あとからテストコードを追加するのは非常に難しいと考えています。というか、かけるコストに対して得られるメリットが少ないんではないかと。

こういうときはテストコードは諦めてドキュメントベースでテスト観点を管理する、というのが最近の自分の見解です。

決してテストコードを書くことはマストではないと思います。メンバーのスキルを考慮する必要もあります。大事なのは実装のあるべき姿を最初に整理して何かしらの形で残すことだと思います。もちろんそれが設計の成果物にあたるのかもしれませんが、そのあたりは現場によってさまざまなのかな。

プログラムの複雑さをレゴブロックで例えてみる

上司に説明するときに何かいい例えはないだろうかと考えて、なんとなくレゴブロックの例を思い付きました。主観的な内容ですのであしからず...。

---

レゴで遊んだことがあるひとには説明不要かと思いますが、レゴにはいろいろな形や色のブロックがあります。例えば、顧客から「とある形のブロックを別の色に変えて欲しい」という要求があったとします。

きちんと設計されていない、いわゆるスパゲッティ状態のプログラムをレゴで例えると、以下のように雑多にブロックが集められているようなイメージです。

(https://www.toysrus.co.jp/s/dsg-489487100)

顧客の要求に応えるには、この雑多なブロックの集まりをガサガサとかき分けて特定の形のブロックを探し出す必要があります。実際、このようなプログラムに手を入れるときも感覚としては近いものがあるような気がします。レゴで遊んだことがあるひとには分かるかもしれませんが、狙った形のブロックを探すのって意外と難しいものです。

一方で、割としっかり作ってはあるが、必要以上にかっちり作り過ぎて複雑になっているプログラムをレゴで例えると、以下のようなイメージです。(あくまでも例えです、この画像の建物はきちんと考えられて作られたものと思われます)

(https://www.gizmodo.jp/2017/05/lego-minecraft-the-mountain-cave.html)

顧客の要求に応えるには、同じようにガサガサとかき分けるわけにはいかず、まずどのような構造になっているか把握する必要があります。で、目星が付いたら、もとの形を崩さないように手を入れていく必要があります。もしかしたら屋根の部分や外壁の部分をごそっと取り外して中に手を突っ込むこともあるかもしれません。(※ここではリファクタリングの話とかはしません)
実際、このようなプログラムに手を入れるとき、現状を把握するのにとても苦労します。しかも、こういうときに限ってドキュメントがなかったりします...。

まとめ

シンプルがいちばん。シンプルを保つのは簡単ではないが、できる限りシンプルさを保てるように継続的に改善しよう。

Vue.js の日本語ガイドに PR したら英語の勉強になった

v-for に key 属性を指定するときとしないときの違いの一例 - kntmr-blog

これの余談なんですが、v-for と key の仕様を確認しようと思って公式ガイドを読んでたら、なんとなく誤訳かなと思われるものを見つけたので Pull Request を投げてみました。

当初の翻訳はこう。

可能なときはいつでも v-for に key を与えることが推奨されます。これは、繰り返される DOM の内容が単純でない、または性能向上を標準の動作に意図的に頼っていない場合に限ります。

で、原文はこちら。

It is recommended to provide a key with v-for whenever possible, unless the iterated DOM content is simple, or you are intentionally relying on the default behavior for performance gains.

最初、この unless が接続詞なのかなと思って、それに続く the iterated DOM content is simple と you are intentionally relying on the default behavior for performance gains を否定してこれらを 除く ものと解釈しました。

可能なときはいつでも v-for に key を与えることが推奨されます。ただし、繰り返される DOM の内容が単純でない、または性能向上のための標準の動作に意図的に頼らない場合を除きます。

が、この解釈は誤っているとコメントがあり、再度 Pull Request を投げることに。あと、前後の文章を入れ替えてみた。

繰り返される DOM の内容が単純でない場合、または性能向上のための標準の動作に意図的に頼る場合を除いて、可能なときはいつでも v-for に key を与えることが推奨されます。

ただ、これも意味的には誤っていて、最終的にはこの Pull Request で修正していただきました。

繰り返される DOM の内容が単純な場合や、性能向上のために標準の動作に意図的に頼る場合を除いて、可能なときはいつでも v-for に key を与えることが推奨されます。

ようするに、この unless は接続詞ではなく、単純に the iterated DOM content is simple を否定するための前置詞なんですね。確かに DOM が複雑というか処理が重くなりそうなら key を付けずに性能向上を図る方がいいのかもしれません。

結局、話をややこしくするだけになってしまって申し訳ない感じに...。一応、当初の内容から変わるきっかけにはなったので少しは役に立っただろうか。いろいろと勉強になりました。

v-for に key 属性を指定するときとしないときの違いの一例

先日、v-for に key 属性を指定しないことが原因で生じる不具合に遭遇しました。別にたいしたものではなんですが、v-for と key 属性の確認を兼ねて簡単にまとめます。

今日は v-for に :key を指定しないせいで起こる不具合に遭遇した

— kntmr (@knt_mr) 2018年8月7日

ただ、2.2.0 以降のバージョンでは key は必須なんですね。

2.2.0 以降で、コンポーネントで v-for を使用するとき、key は必須です

リストレンダリング #コンポーネントと v-for - Vue.js

雑なサンプルコードはこちら。

kntmr/playground - GitHub

---

v-for に key を指定しない状態でリストを描画する。で、リスト内のある要素をクリックするとスタイル (文字色とか) が変わるものとする。

<div>
  <ul>
    <li v-for="item in items">
      <p class="item" @click="select">{{ item.name }}</p>
    </li>
  </ul>
  <button @click="toggle">Toggle Data</button>
</div>

ここで、いずれかの要素をクリックしてスタイルを変更した状態で、リストの要素をすべて入れ替える。(サンプルコードの中ではボタンクリックで items の中身をすべて入れ替えるようにしてあります)

すると、リストの内容は書き変わるが、先ほど変更したスタイルがそのまま残る。これは v-for が DOM を使い回しているため と思われる。

で、v-for に key を付ける。

<li v-for="item in items" :key="item.id">

こうすると、DOM の使い回しが回避できるため、あるべきスタイルで描画されるようになる。ちなみに、公式ガイドの key の項には以下のように記載されている。

この標準のモードは効率がいいです。しかしこれは、描画されたリストが子コンポーネントの状態や、一時的な DOM の状態に依存していないときにだけ適しています (例: フォームのインプットの値)。

リストレンダリング #key - Vue.js

というわけで、基本的には性能向上を目的として DOM を使い回す動作になっているようです。(が、安全な方に倒すのであれば、key を付けるのが無難な気がする...)

動的にデータを取得する Vue.js のツリーコンポーネント

これを探してた / Tree View Example https://t.co/vv3JakWbTQ

— kntmr (@knt_mr) 2018年7月25日

ツリー表示する方法を調べてたら Vue.js の公式サイトにいい感じのサンプルがありました。このサンプルではコンポーネントを再帰することでツリーを実現しています。とても学びがありますね。

ただ、今回はツリーを開くタイミングで動的にデータを取得するようにしたかったのですが、このサンプルは初期表示の時点でツリーのデータをすべて持っています。

というわけで、サンプルをカスタマイズしてみました。

github.com

構成は公式サイトのサンプルとほぼ同じですが、今回必要のなかった箇所は移植していません。

ツリーを開くときに呼ばれる toggle メソッド内でツリーの子要素を取得します。また、2回目以降ツリーを開くたびにリクエストが飛ばないように m-loaded 属性で制御しています。

あと、ローカルで動作確認するために JSON Server を使っています。

> npm install -g json-server
> json-server --watch db/db.json

スタディサプリ ENGLISH で英語の勉強を始めました

2018年の目標に「英語の勉強」を挙げてましたが、進捗ゼロのまま半年以上が過ぎてしまいました...。

2017年のふりかえりと2018年のこと - kntmr-blog

このままではよろしくないので、とりあえず通勤時間を利用して英語の勉強をしてみようかと。とはいえ、本や単語帳アプリでは長続きしなさそうなので、以下のアプリを試してみました。

eigosapuri.jp

で、1週間ほど無料コンテンツを試してみたところ、なかなかいい感じ。

• ストーリー仕立てで飽きない
• 文法やリスニングのポイントなどを動画で解説してくれる
• 自分の弱点を評価してくれる

というわけで、プレミアム会員に登録してみました。月額1080円。頑張ります。

プレミアム会員課金駆動学習をキメた

— kntmr (@knt_mr) 2018年7月24日

ちなみに英語を勉強するモチベーションですが、特にかっこいいものではなくて、映画を字幕なしで観たいとか、海外ミュージシャンのMCを理解したいとかそんな程度です。