概要

• モブプログラミング（以下、モブプロ）とTDDの２つを勉強会にてやってみたので、その所感などを記載します。

モブプログラミングって？

• ドライバーとナビゲータで役割を分け、一つの画面で一緒にプログラミングを行うこと。
  • ドライバー：コーディングを行う人
  • ナビゲータ： 実装を手助けする人

TDDって？

• テスト駆動開発（Test Driven Development）の略
• 実装の前にテストコードを書き、テストに適するかたちで実装を行うことを指す。

勉強会で両方やってみた

どんな勉強会？

• モブプロでTDDしようという勉強会でした。

• TDDは、レッド（テストで失敗させる）
  → グリーン（テストを成功させる）
  →リファクタリング（コードをきれいにする）
  の流れで開発のサイクルをまわします。

上図のように、

1. まず失敗するテストをコーディングする
2. とにもかくにもテストを通す（成功させる）
3. 実装をきれいにする

のサイクルをまわして要件を一つずつ実装していきます。

• その際にサイクルの一つでも成功するたびにしっかりと褒めあって称え合って雰囲気を盛り上げながらTDDをしていきました。

• サイクルの一つを完了するたびにドライバーとナビゲータを交代して、全員がどちらの役割も経験しました。

• 言語はRUSTで参加者の全員が1ミリも触れたことのない言語でTDDを行いました。だからこそ型の定義の違いなどについてみんなで調べて最適解をはやく見つけようとしていきました。

やってみた感想

モブプロの感想

• モブプロは盛り上げるの超大事。個々人の積極的な意見を出すためにも、場の雰囲気を良くすることが必要。

• モブプロは変数名一つについてもナビゲータたちと議論をして最適解を導き出すので、開発後の保守や運用においても対応が遅れるなどの問題が発生しにくいのではと思った。
  例）仕様を一人のエンジニアしか理解しておらず、機能を追加する際に考慮漏れが発生するなど。

• 人によってコーディングの方針（どの関数を選ぶかなど）が異なるため、議論を重ねることで独りよがりのコーディングになりにくくなる。

TDDの感想

• コーディングする前に、なにを実装するのかについてTODOをリストアップすることが非常に大事。それが要件定義になる。

  • 今回はFizzBuzzでTDDを行いましたが、「①1の入れたとき、数字の1を返す。②3を入れたとき、Fizzを返す。」のように、自分たちが何を実装するのかをまず日本語で並べることで先の実装を含めイメージをすることができた。

• RustでTDDを行ったが、自分の知らない言語を知る際の障壁が下がる。（TDDの良いところですね）

  • 知らない言語について勉強をする際にはTDDでとりあえず書いてみるというのはありだと思いました。

• 今後追加で実装するにあたって、テストを通すだけで既存の実装に影響が出ていないかをチェックできるのは強い。

参考資料

テスト駆動開発

laravel.shibuyaって？

IRT(Interactive Round Table)をメインとした勉強会

そのため、持ち寄ったテーマの中からトピックを決めて相談・議論をすることが目的になります。

今回私が参加した回では、2つのトピックについて議論をしました。

Q1. 自分の職場はテストを書く文化がないんですが、テストやCIといったツールを会社に広めて導入につなげていったような体験談とか、うかがってみたいです。

質問の背景：上に話してみるが、工数がかかったり、変更が多く仕様が明確でないため承認されない。

• テストを書くと安心できるが、それを全体に伝えることが難しい。（ただのコストと思われがち）

• 新しい文化を根付かせていくためにどうやればいいのか？

などの意見があがりました。

アプローチの仕方として出た意見は、

• テストコードはプッシュせず、自分のローカルで確認できればよいのでは。
  • これに関しては、テストの目的はバグを減らすだけではなく、仕様書としても機能するので、自分だけではなく他の人に広める意味はあるのでは、という意見も。
• テストにも色々あるので、部分的に導入をしていくのもあり。（一気にやると）

まとめとして、

• 自分が快適に開発させるだけなら、ローカルにだけやるのはあり。

• TDDで開発サイクルを早くするためにといったテストをやる目的を改めて整理して、目的を再確認する。

というものになりました。

Q2. 命名規則を定めるにはどのような観点から考えるべきか？

質問背景：社内にコーディング規約はあるが、命名にルールがなくコードの意味が人によって異なる可能性がある。

ルールの具体的な内容については以下のような意見がありました。

• リポジトリクラスにはリポジトリとつけるとか。

• SET GETはつけないとか。

• 多少冗長でも誤解のないようにする。

  • 何を使って何を呼び出すのかを長くなってもつける。

• 関数に副作用があるかどうかで命名を具体化する。

• ドメイン辞書を作って、対応する英語を決めている。辞書を作る。
  • 共通認識を作り上げている。
  • メンテナンスが大変だけど、間違っても良いから辞書をつくる
  • BackLogで作ったりする（履歴管理ができるものがよい）。

まとめとして、

• サイトを使ったり、話し合って使う単語の方向性を議論して決める。
• すでにあるコードをみて、これを使っていこうなどの合意を持つ。

というものになりました。

終わりに

持ち寄ったテーマについての議論は非常に有意義でした。

これは社外でのコミュニケーションの中で、かなり有意義なものだったんじゃないかと思います。

共同開発などでブランチ名をコミットメッセージに入れたい場合があったのでGitHookを使って自動的に入力されるようにしました。

※今回は、ブランチ名に共通した文字列が含むことを前提としています。

GitHookとは？

• Gitで、特定のアクション（git branchなど）が実行されたときに、スクリプトを実行する機能です。

やり方

肝心のスクリプトを実行するファイル群は、 .git/hooks ディレクトリにあります。

1

cd [gitディレクトリ]/.git/hooks

今回はコミットメッセージを編集することが目的なので、hooksディレクトリにあるcommit-msg.sampleを編集します。

まず、ファイル名を編集します。

1

mv commit-msg.sample commit-msg

編集後、

1

vi commit-msg

でファイル閲覧モードに切り替えてください。

編集モードに変更したら、

1
2
3
4
5

if git branch | grep '*' | grep 'xxx';
then
    NAME=$(git branch | grep '*' | sed 's/* //' | sed 's/xxx_//')
    echo '【'"$NAME"'】'$(cat "$1") > "$1"
fi

を挿入しEscキーをクリック後、:wqで保存してください。

保存後、ブランチ名がxxx_testのようなもので検証してみましょう。

ブランチ名がxxx_hogeのとき、【hoge】テストといったコミットメッセージを自動的に作成することができます。

解説

commit-msgファイルに挿入した一行目のif条件の1つ目git branchで、該当プロジェクトでローカルで作成したブランチの一覧を取得しています。

2つ目grep '*'で現在のブランチを取得。

3つ目grep 'xxx'で現在のブランチの名前にxxxが含まれているかチェックしています。

チェックを通過すると、最初のthen以下が読み込まれます。

NAME変数に該当ブランチの必要な箇所の格納をしています。

git branch | grep '*'で同様に現在のブランチを取得し、二回のsed(PHPでいうstr_replace)で必要な、共通箇所以外の部分を抜き出しています。

参考

• Gitフックとは

初投稿。

きっかけは、世の中のエンジニアの方々がブログやQiitaを通してアウトプットする姿にかっこよさを感じ、真似すればかっこよいエンジニアなれると信じブログをはじめました。
なれなかったら恨みます

最初の投稿はこのブログの作り方ついて書こうと思います。

経緯

最初ははてなブログで作ろうと思っていました。理由は非常に簡単にブログを作成できそうだったからです。
（はてブをやってるので…）

けどもいまいちモチベーションが上がらず、挙句の果て、どんなことを書けばよいのかわからなくなっていました。

そんな中、GitHubPagesを教えてもらい、草はやせてモチベアップするやん！と思い一念発起してブログを始めました。

やり方

ここでは、Hexoの登録からデプロイまでの流れを説明します。

それ以外のGitHubの登録とインストール、node.jsのインストールの方法については参考に上げた記事をご確認ください。

※以下はGitHubPages・node.jsインストールしてある前提で話が進みます。

まずHexoをインストールします。

1

npm install -g hexo

インストール後、Hexoブログの新規プロジェクトを立ち上げます。

※Hexoインストール後、 hexo コマンドが利用できるようになります。

1

hexo init [プロジェクト名]

作成後、作成したフォルダ内に必要なモジュールを入れます。

1
2
3

cd [プロジェクト名]

npm install

上記まで行うと、ローカルサーバで、作成したプロジェクトを確認できるようになります。

そのためにHexoサーバを起動してください。

1

hexo server

コマンドを実行すると、

[info] Hexo is running at http://localhost:4000/. Press Ctrl+C to stop.

といったテキストが表示されるので、http://localhost:4000/にアクセスすれば、ローカルで確認ができます。

次に、Hexoで作成したファイルをGitHubPagesで公開します。

1

vi _config.yml

でYmlファイルを表示します。

1
2
3
4
5

# Deployment
## Docs: http://hexo.io/docs/deployment.html
deploy:
  type:

と書いてある箇所を確認してください。

編集モードにして、

1
2
3
4
5
6

# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
  type: git
  repo: git@github.com:hoge/hoge.github.io.git
  branch: master

に書き換えてください。

※hogeはご自身のユーザー名が入ります

編集後、escキーで表示モードに戻り、:wqで編集を保存してください。

この状態でデプロイをしてもエラーが出てしまいます。

1

npm install hexo-deployer-git --save

でGitHubにデプロイできるようにするプラグインをインストールしてください。

インストール後、

1

hexo deploy -g

でGitHubPagesへHexoでの変更を反映してください。

反映後、自身のGitHubPagesのURLにアクセスしてください。

変更内容が反映されていたらデプロイ完了です。

所感

• Markdownでブロクの作成ができCUIでデプロイができるのが非常に便利。

• コマンドでのデプロイ後、２〜３分程度の反映ラグを感じた。（ブログなので、あんまり気にしなくて良いところかも）

• Markdownについて業務で親しみがないなど利用機会がないが勉強がしたい場合は、Hexoなどの静的アプリを使うのはあり。

• GitHubPagesを使うメリット→コード、ブログをGit管理できる。

参考

• Hexo公式サイト

• node.jsのインストール

• GitHubPagesのリポジトリ作成方法

• npmとは？

• HitHubPagesで構築可能な静的サイトジェネレータ一覧

• この一年間、自分がGitHubで取り組んできたことを紹介してみる