対象読者

・何らかの理由でGitを使う事になったが、コマンドが多くてよくわからない方。
・コマンドごとの意味は何となく理解しているけど、イマイチピンと来ない方。
(※「そもそも何故Gitを使う必要があるのか」「バージョン管理とは何か」といった点については ノンプログラマ向けの連載企画として後日記載させていただければ幸いです)

解説するコマンド

git init, git add, git commit, git status, git log, git branch, git checkout, git merge, git clone, git pull, git push, git fetch

他にも remote, cherry-pick, rebase, reset 等 色々ありますが 本記事ではまず 最もよく使うであろう上記コマンドに絞って解説します。

進め方

何かを学ぶ上で 適切な比喩となるものを想起して イメージを持たせる事はとても大事だというのが個人的な考えです。
ので、今回は Gitを「工場」に見立てて、一人の工場管理者を主体にお話を進めていければと思います。

それでは早速見ていくことにしましょう。

1. 自社工場を建てる

git init: 自社工場を建てる

「git init」という呪文と共に 魔法の杖を一振りすると工場が現れました( 「どうみても爆破しているようにしか見えない」とか言わないで下さい )。

これで製品を開発するための環境が整いました(ただし工場の中身はまだ空っぽです)。この工場の下で 製品の開発を行います。

git add: 開発・修正を行った点の届出

製品をつくる上で、工場ではどの部分を修正・追加・削除したかを届出する必要があります。これが git add にあたります。届出をしないと 出荷用の製品を工場内で登録する際に 変更分が登録されないので注意が必要です。

届出後の製品登録は 責任者であるコミットおじさんにお願いをします。コミットおじさんは git add で上がって来た変更分を出荷用製品として登録する役目を担います。

git commit: 出荷用製品の登録

変更の届出も一通りできたので、今度はコミットおじさんにお願いをして 変更した製品を出荷用に登録します。
これで 変更履歴が正式に工場に記録され、今後製品を自社工場から出荷する際は 変更分を加えた製品が出荷されることになります。

git status: 現状の確認

addによる届出忘れを確認したり、どこまで届出したかを確認したりするために使用します。

git log: 製品を変更してきた履歴を見る

これまで工場内でどういう製品の変更をしてきたかを問い合わせます。
git logでは コミットおじさんに登録してもらった製品登録の履歴が残っており、各履歴には特有のIDがついています。
これにより、「あ、ID番号○○の所まで戻したいのでよろしく」というような事が可能になります。

2. 複数の製造ラインをつくる

製造ラインが一つの場合…

工場内でロボットをつくる際、もしも製造ラインが一つの場合 何が起こるか確かめてみましょう。
早速オーダーがきました。どうやら今回のオーダーはロボットに対して角と羽根をつくるオーダーのようです。実際に作り進めていきましょう。

「ぎゃー不具合がでた！」
「一体羽根と角のどっちの変更でこうなっちゃったんだ？？」
「と、とりあえず羽根を一旦元に戻そう」
「ああ、これ羽根じゃなくて角をつくる時にいじった場所だった！」
「もうこんがらがってわけがわからん！」

ということで、複数機能を同時に並行して開発する場合は 機能ごとに製造ラインを増やした方が良さそうです。そこで…

git branch: 製造ラインを増やす・確認する

「角」用の製造ライン
「羽根」用の製造ライン

二つを分ければ 不具合が出た時に どちらが原因か分かりやすいですね。

git branch では、現在いる製造ラインにおける製品をベースにして 別の製造ラインをつくります。
git では、一般的には「master」という名前の製造ラインがデフォルトで使用されます。色々な製造ラインの分け方がありますが、一例を下に示しておきます。

1. master
2. 角・羽根統合用の製造ライン ( masterからつくる )
3. 角用の製造ライン
4. 羽根用の製造ライン

2をつくるのは、角と羽根の製造ラインを再度がっちゃんこした際に問題が発生した場合、統合用の製造ラインがあると問題が発生した際のトラブルに対応しやすいためです。メインの製造ラインでいきなりがっちゃんこしてしまうと 後々問題が発生した際に面倒な事態に陥ったりすることがあります。

新しい製造ラインをつくる場合は「git branch 製造ラインの名前」を使用しますが、「git branch」のみを入力すると 現在の製造ラインの状況を確認することが可能です。

なお、製造ラインを分けた後の作業は、一つの製造ラインでしていた事と一緒で、基本的には開発作業 → add → commit のサイクルとなります。

git checkout: 作業を行う製造ラインの移動

僕達は人間なので、一般的に一度の時間で一つの作業にしか着手できません(言い換えれば、右手でタスクAを進めながら左手でタスクBを進めるようなことは一般的にできません)。

つまり、一度に一つの製造ラインにしかつけない事になります。
ここで、製造ラインを分けた際、別の製造ラインに移動する方法が必要になります。

git merge: 別の製造ラインの変更をがっちゃんこ

「角」も「羽根」もできたので、あとはくっつけるだけです。こういう時には git merge を使用します。git merge では、ある製造ラインの製品に別の製造ラインの製品をがっちゃんこすることができます。

修正箇所が衝突した場合

例えば、もし角がこんな感じで背中にくっついている…という仕様だった場合どうでしょう。

角の部分と羽根の部分がもろ被りです。
このままではがっちゃんこできない…こういう状態を「衝突(コンフリクト)」と言い、お互いの製造ラインが話し合いをしてうまくがっちゃんこできるようにすることを「衝突(コンフリクト)を解消する」と言ったりします。

コンフリクトの解消に関しては本記事の題意を越えてしまうため割愛させていただきます。

3. 複数の支社間で連携する

規模が大きくなってくると自社工場だけでは生産・開発のサイクルを回すのが難しくなってきます。
そこで、いよいよ複数の工場を立てて連携する必要が出てきました。

こんな感じで、異なる開発作業を支社ごとに分けて それぞれで 開発を進めて 本社で変更分を統合する形にしましょう。

git clone: 本社から工場の環境をそのまま引っ張ってくる

「git clone」という呪文を唱えると、clone元(この場合本社工場)の環境(製造ライン・製品)がそのまま再現された新たな工場が建ちます。
git init では中身が空っぽの状態の工場が建ちましたが、これが git init と git clone との違いです。

引っ張ってきたら あとは個人で作業していた時と基本的には一緒です。
建設した支社工場の中で製品の追加機能をいじったり 製造ラインをがっちゃんこしたりします。

git pull: 本社の製造ラインから最新の製品を取り寄せがっちゃんこ

本社の特定の製造ラインから最新の状態の製品を取り寄せます。さらにその上で自分の工場にある特定の同様の製造ラインの製品にがっちゃんこ(つまり merge)します。
複数の工場で分担して作業をする場合、本社の一つの製造ラインに必ずしも一人だけしかつかないとは限りません。
つまり、あなたが支社工場の特定の製造ライン(Aとしましょう)で作業している最中にも、誰か他のメンバーが本社工場の製造ラインAに最新の製品を登録しないとは限らないということです。
そこで、基本的には 自分の工場で製品を開発した後は 一度 pull して本社の最新の状態の製品とがっちゃんこする必要があります( なお、この際も勿論 衝突が発生することがあります )。

なお、ただ闇雲にがっちゃんこするのではなく「どの機能をいつ開発したか」など順番を意識してがっちゃんこする際には git pullに加えて「--rebase」という重要なオプションがありますが、こちらでは本記事の範囲を超えてしまうため 触れるのみに留めておきます。

git push: 本社の特定の製造ラインに 自社で開発した製品を出荷

git pushを行う事で自分の工場の特定の製造ラインでつくった出荷用製品を本社に送ります。基本的に、宛先となる工場の場所と製造ラインを指定して送ります。

git fetch: 本社の製造ラインから最新の製品を取り寄せる

本社から最新の状態の製品を取り寄せます。ただし、がっちゃんこはしません。( 言わば、git pullは fetch + merge を同時に行うコマンドということになります )

—

これで一通りコマンドの解説が終わりました。ここまで読んで下さりありがとうございました。間違っている点・アドバイスなどございましたらどしどしご指摘いただければ幸いです。よろしくお願いいたします。

最後に、それぞれの作業工程における比喩の意味を解説して本記事を終えたいと思います。

比喩の意味

1. 自社工場を建てる

自分の開発環境でバージョン管理を始めること。

2. 複数の製造ラインをつくる

複数の機能を並行してつくること。実際、Webサービスを運用する場合、つくるものが同じ時期に1つの機能だけとは限りません。
そういう時に、作業内容がこんがらがらないような仕組みが必要です。

3. 複数の支社間で連携する

これは実際のチーム開発に他なりません。
開発メンバーは各自の開発環境で機能の開発を進めていき、自分の環境で機能がうまく動く状態をつくったらそれを一箇所に集めます。
こうして複数のメンバがそれぞれ異なる開発をしても規律の取れた開発体制が実現できるようになります。

The post 【Git入門者向け】イメージで理解するGitコマンド事始め appeared first on きのこる庭.

「一緒に働いている以上、プログラマのことを理解して仕事をしたい」そう考えている企画・ディレクションの方は経験則的に少なくない。
ノンプログラマから見て、プログラマの仕事はイメージが湧きづらく、何故その工程にそこまでのコストをかける必要があるのかわからない事が多い。
プログラマは作業の必要性を説明してくれるかもしれないけれど、専門用語も多いしイマイチピンとこなかったりする。

ここで重要なのはまさに「イメージ」だと思う。すなわちイメージを提供するための良質なメタファーだと思う。メタファーが良質であれば より直感的に理解できる。
実際メタファーの力はバカにならない。「Chef」も「Jenkins」も それぞれ 統一的な世界観が学習者の直感的な理解を後押ししてくれる。

というわけで、今回から数回に分けて なるべく「技術的な話」をせずに イメージを想起しやすいストーリーを導入することで プログラマの具体的な仕事の内容についての説明を試みる。

対象読者

・企画、ディレクター等 プログラマと直接コミュニケーションを取る機会の多い人達
・プログラミング初学者

現時点での執筆予定

< 具体的な作業工程 >
・「テスト」について (今回)
・「アジャイル開発」について
・「TDD(テスト駆動開発)」について
・「バージョン管理(Git / SVN)」について
・「CI(継続的インテグレーション)」について
< スタンス・文化 >
・「プログラマのスタンス／経営者のスタンス」の重要な違い、ハッカー文化について
・「プログラマがよく使用する用語」について
・「自社で採用するべき言語」について(人事向け)
・「炎上」について

※ ニーズにより目次は前後・変更する可能性があります。
また、若干 宗教論争になりそうな所は テーマ・対象を厳密に熟考した上で できるだけ主観が入らないよう注意します。
※ 最近は企画の方もGitをいじられるそうなので、そのうちGit詳解編もつくる予定です。
(11/16 21:50 追記) ※ ↑ブコメにて「いわゆる”ハッカー文化”を語るのはWeb系に多く、他分野ではそうではない」という重要なコメントを頂きました。確かにWeb系を中心に考えすぎており他分野に対して盲目的でした。申し訳ございません。文化的な部分を語る際は 認識の誤りが無いよう、対象を限定するように注意いたします。
(2015.04/09 追記) ※ 私都合により少々執筆の目処が立たないため シリーズとのたまったものの一時休止させていただいております、申し訳ございません。

長くなりましたが、それではこれからテストをめぐるAくんのストーリーを見ていくことにします。

——————————

オープニング

20XX年――― ある小さな町に A君 という若者がいました。
A君は 自宅で自作のロボットを設計しては組み立てて売ることで 生計を立てていました。

最初は友達に小さなロボットを見せたりして、細々とロボットをつくっていたA君でしたが、
次第にA君のつくったロボットの評判は町中に広がり、ロボットを買いに来てくれる人が多くなりました。

ロボットを買ってくれる人が多くなるにつれて、買ってくれる人から色々な意見を貰うようになりました。

「手足が動くようになればもっといいね」
「装飾としてアンテナをつけた方が格好良いと思う」

できるだけ多くの人を満足させたいA君は、貰った意見を基に ロボットに対して色々な機能をつけながらロボットの改善を重ねていきました。

こうして、最初はシンプルだった ロボットには色んな機能がつきました。
それでも買ってくれる人からの要求は絶えません。A君にとっては常に改善の日々です。

そんなある日、A君は あるお客さんからいただいたアドバイスを基に部品の追加をしようとした所…。
部品を追加したい場所に、結構前につけた別の部品がくっついています。
この部品がクセモノで、他の沢山の部品と接続されているため なかなか取り外しづらそうです…。

「困ったなあ・・・。でもお客さんの要望にこたえなきゃいけないしなあ」

暫く悩んだA君は、元々くっついていた部品を改造した上で 新しい部品をつけてみました。

「うん、何とか動きそう」

部品が動く事を確認したA君は さっそく追加した機能をお客さんに見せます。
お客さんは非常に満足して、ロボットを買って帰っていきました。

数日後、A君のもとにぽつりぽつりとクレームが届き始めます。

「なんかアンテナのランプが光らなくなったんだけど・・・」

何ということでしょう。
今回A君が追加した部品とは違う部分で問題が起きていました。

A君は 追加した部品が動くかどうかだけに気ををとられてアンテナのランプが光らなくなっていた事を見落としていたのです。
(これは余談ですが、人間別の事に集中していると 他の事に対する注意力が落ちるものです。例えば「何回パスが渡されたか数えて下さい」と指示があり、バスケットの試合が映し出される動画(こちら)があるのですが、皆パスの回数を数えるのに夢中になるあまり、途中でゴリラが乱入しても全く気が付きません。是非友達に試してみて下さい)

アンテナは 今回追加した部品と直接繋がってはいないものの 間接的に別の部品を経由して動いている部分でした。
大切なお客さんに対して 不具合のあるロボットを渡してしまったことで A君はひどく落ち込んでしまいました。

——————————

そこで「テスト」の工程を導入

これだけ複雑なロボットになってしまったわけなので、そろそろ 目視や何となく動くかチェックするだけでは先ほどのような抜け落ちが出てきてしまうことに気がついたA君は、ロボットをお客さんに出す前に「この部分の機能がちゃんと動いているかどうか」という項目を上げて かならずテスト作業をすることにしました。項目は以下のようなものです。

「ボタンを押した時に 手足が正常に動くか」
「胸元のランプを押した時に 胸元のランプが光るか」
「ロボットの電源を起動した時に アンテナのランプが光るか」

毎回 部品を追加した後にテスト工程を含めることで お客さんに新しいロボットを提供するスピードは以前より落ちてしまいましたが、これで 大きな不具合を出して沢山のお客さんを困らせてしまうことはなくなりました。

——————————

解説

・ロボット
Webアプリケーションやソフトウェアなどの「システム」そのものです。
一般的に規模が大きくなるにつれて、お客さんの要求によってどんどん色んな機能がついていって構造が複雑になります(一見サービスとしてはシンプルなシステムに見えてもです)。

・お客さん
企画の方や、顧客のことです。
内部構造がいかに複雑で 機能の変更が難しいかは彼らには関係ありません。
彼らは色んな要求をしてきますが、本当は何が欲しいのかを自分たち自身が気づいていないケースもあるため あらゆる要求を飲む事はせず しっかりとコミュニケーションをとることが大切です。

・アンテナのランプが光らなくなった
開発現場ではこのように「既存機能に変更を加えた結果として 元々の部分に予期しない変更が起きる」ことを「デグレ(デグレード・デグレーション)」と言います。
(例) 「●●の部分デグレってる」

(11.17 追記) 「デグレーション」という言葉も一応存在するみたいですが、正しくは デグレード、またはデグラデーション(degradation) のようで、こちらの言葉が一般に使用されるみたいです。ブコメにてご指摘下さった方、ありがとうございます )

——————————

以上です。テストを導入することで確かにロボットを提供するスピードは少し落ちてしまいますが( とはいえ、実はテストを書いた方が 導入時こそ大変なものの後からスピードが速くなるのですが )、「テスト」という作業がどれだけ大切な作業かご理解いただけたら幸いです。

「テスト作業」について

ここからは ちょっと踏み込んだ部分になりますので、より詳細に技術者の仕事を理解したい！という有志のみご覧下さい。

概要

「●●をした時、●●という結果が返ってくるか」という形でテスト項目をつくっておき、機能の追加・修正が発生した段階で項目にしたがってテストを行います。

種類

単体テスト・ユニットテスト
プログラマの作成したシステムの断片的な機能を、テスト用のコードを書いてテストします。
部品を組み合わせる前に、その部品が本当に正常に動いているかを見るわけです。
例) square関数(二乗のための関数) のテスト
「数字 4 を渡した時に 16 という結果を返すか」
「数字 0 を渡した時に 0 という結果を返すか」
「数字 -5 を渡した時に 25 という結果を返すか」
「文字列 を渡した時に エラー “数字を入力して下さい” を返すか」

統合テスト(インテグレーションテスト)
システムについて、複数の機能をそれぞれ何人かで分けて開発している場合、どこかの時点で「部品を組み合わせる作業」が必要です。
その際、個々の部品が不具合無くしっかり動いていたとしても、組み合わせた時点で不具合が発生しないとは限りません。
そのため、部品がしっかり組み合わせられているかを保証するために 部品を組み合わせた状態でのテスト作業を行います。

エンドツーエンドテスト(E2Eテスト/受け入れテスト)
単体テスト・ユニットテスト・統合テストは主に不具合が無いかを保証するための「プログラマ」寄りのテストでしたが、こちらのテストは技術的な話を抜きにして「追加・変更した仕様がしっかりと要望通りに動くか」をテストするためのものです。
こちらのテストは 実際に要望を出す 企画・ディレクション の方がつくるのが一般的です(認識のずれによって間違った物を開発してしまわないためにも、企画の方は どんな要望なのかを間違いなくプログラマに伝える必要があります)。

例) ECサイトの購入確認ページ かごの中の商品を表示するようにシステムを変更した場合のテスト例(飽くまで一例。実際はもっとテスト項目が多いので注意)
テスト1・単数条件
「1. テスト用のURLに遷移し、『テスト本』を買い物かごに入れる
　2. “購入”ボタンを押し、確認ページに遷移する
　期待する結果: 確認ページに『テスト本』の情報が表示されている」

テスト2・複数条件
「1. テスト用のURLに遷移し、『テスト本』『テスト本2』をそれぞれ買い物かごに入れる
　2. “購入”ボタンを押し、確認ページに遷移する
　期待する結果: 確認ページに『テスト本』『テスト本2』の情報がそれぞれ表示されている」

テスト3・購入する商品がない場合
「1. テスト用のURLに遷移し、”購入”ボタンを押し、確認ページに遷移する
　期待する結果: “かごの中に何も入っていません”と表示されている」

そもそもテスト項目の結果が変わるような変更が起きた時は？

テスト項目自体を変更します。
これが「ユニットテストでどこまでの範囲をテストするのか」という問いにも繋がってきます。
( 100%全てのシステムを網羅してテストコードを書いても、仕様変更の度にテストコードを沢山書き換えなければいけないようであれば コストがかかりますから )
なので、ソースコード全体のうちどれくらいの範囲のテストを書くのか(「カバレッジ」ともいいます)は そのサービスの規模によって変化させるべきです。
ただし、システムの規模が小規模であれ大規模であれ、コアな機能(その機能に不具合があればサービスが成り立たないような機能)に関しては必ずテストを行うべきです。
スピードを大事にしすぎるあまり本当にテストが必要なコア機能すらしっかりテストしないとかそれサバンナでも同じ事言えんの？

テストの方法

単体テスト、ユニットテスト、統合テスト の場合
テスト用の便利なフレームワークが世の中には沢山存在します( xUnit と呼ばれるものが有名です )。
このフレームワークの規則に沿ってテスト用のコードを書くのが一般的です。
元々テストを導入してこなかった場合: 急にテストを全て書くのは至難の業なので長い年月が必要になりますが、そのあたりは僕よりもテストに詳しい方が 昔からよく議論されている部分なのでそちらを参考に。

エンドツーエンドテストの場合
意見が分かれる所だと思います。
最近の技術体系だと E2Eテストですらソースコードで導入できるようになってきてはいますが、
まだまだ Excelが多い印象です。
理由としては、企画・ディレクション職のノンプログラマに E2Eテスト用のコードを書くための若干の学習コストを強いることになる点、部署をまたいだ組織的な取り決めのプロセスにコストがかかる点等が挙げられると思います。

テストを導入することの難しさ

(11/16 21:50 追記) ブコメにて貴重なコメントを頂きました。ありがとうございます。
ここまでを見ると、「ああ、じゃあテストを導入すれば品質が上がるんだな」となりますが、テストの工数に関しても触れないわけにはいきません。
テストは導入してしまえば終わりではなく、追加・変更にもそれなりのコストがかかります( 特に開発初期に関しては 導入にかなりの時間を要します )。そのコストは実際にテストを設計し、落とし込む作業が入るため、開発作業と同等のコスト・もしくはそれ以上の工数が発生する可能性を考慮しておく必要があります。
( とはいえテストを導入しない場合は導入しない場合で、どのみち開発工程の多くの時間を 正体不明のバグの対応で埋めることになりますので、長期的に品質、不具合の規模・頻度、不具合対応の速さを考慮するのであれば テストの導入は不可欠となります )

——————————

以上です。
ここまで読んで下さりありがとうございました。
僕もまだまだひよっこなので、「ここ間違ってるよ」という部分がございましたら是非ご指摘・アドバイスいただければ幸いです！

The post 【ノンプログラマ向け】プログラマの仕事内容を理解する ～「テスト」という工程が必要な理由 appeared first on きのこる庭.