# 導入と基本的な知識

ここでは、このドキュメントを進める上での前提と、知っておいて欲しい知識を記載する。

# 今回の開発内容

今回は、"タスク管理システム"を作る。

最初は、シンプルに「やること(タスクのタイトル)」を"一覧表示"する機能を作り、 そこから”詳細表示"、"追加"、"削除"、、と機能を増やしていく。

その後、発展として、"ユーザ認証機能"、"Vue.jsを使ったタスク完了機能"、 "期限つきタスク"、"期限に応じたリマインダー(メール、Slack)"、と拡張を重ねていく。

# 開発環境

筆者は下記の環境で、本ドキュメントの動作を確認している。 実際には、PHPの7.0以上、MySQLの5.6以上で動作確認できれば、問題無いと思われる。

# コーディング環境

分類	名前	バージョン
PC	MacBook Air	13-inch, Mid 2012
OS	macOS	High Sierra 10.13.4
IDE	IntelliJ IDEA	2018.1
Lang	PHP	7.2.4
Package Manager	Composer	1.6.4
Framework	Laravel	5.5.40
Browser	Google Chrome	66.0.3359.139

PHPとComposerはHomebrewを利用してインストールしている。

LaravelはComposerを使ってインストールしている。インストール手順はLaravelの公式ドキュメントを参照して欲しい。

Browserについては、Laravel Duskというブラウザテスト用パッケージの設定の関係上Google Chromeとしている。 WebDriverを利用したものなので、その辺りの設定を行なえるのであれば、他のブラウザも利用可能なはずである。

# 実行環境

実行環境については、Docker(Docker-Compose)を使っている。 詳細については、下記リポジトリの各ファイルを参照して欲しい。

GitHub: tacck/task-manager

分類	名前	バージョン
PC	MacBook Air	13-inch, Mid 2012
Container Engine	Docker Community Edition	18.03.1-ce-mac65 (24312)
Container Image(Web)	Apache HTTP Server + PHP	php:7.2-apache (カスタマイズ有り)
Container Image(DB)	MariaDB	mariadb:10.2

# Laravel

• Laravel
• Laravel (日本語版)

The PHP Framework For Web Artisans (Web職人のためのPHPフレームワーク)という謳い文句の通り、 色々と気の利いた機能が標準で提供されている。(または、簡単に追加できるようになっている。)

いわゆる"MVC"をベースとしたフレームワークだが、特にModel部分は縛りが緩く、拡張をしやすくなっている。 もちろん、O/Rマッパーを利用したシンプルなModelでの開発も簡単にできるので、 規模に合わせた書き方が可能だ。

また、フロントエンドのコードを書く際に、Laravel Mixというパッケージを利用することで、 簡単にVue.jsとWebpackを利用できるようになっている。

具体的な使い方は、これからの本文で確認していくことになる。

# TDD (Test-driven Development / テスト駆動開発)

名前どおり「テスト」によって開発を駆動する(進める)手法だ。 ただし、ここでいう「テスト」は一般的なテストと少し意味が異なる。

一般的な「テスト」は、開発工程の最後でテスター・テストエンジニアが行なう品質の保証活動だ。 端的に言えば「いかにバグを出すか」というアプローチになる。

TDDでいう「テスト」は開発を始める前に、「これから書くコードはこういう動きになる」という設計をテストコードで表現したものになる。 つまり、コーディングした内容をその場で「チェック」するためのアプローチであり、テストコードを使った設計、と捉えた方が良い。

TDDは「テストファースト(テストコードからかき始めること)」による開発手法ではあるが、 今回のドキュメントではあまりそこは強く求めないようにしている。

そもそも、なぜテストを書くかというと、「リファクタリングを、心理面も含めて安全に行なえるようにする。」という効果を得やすいから、 と、筆者は理解している。 「リファクタリング」によってより良いコードへ安心して変更できる、ということが重要で、 その安心を得るための指標として「テスト」を利用している、のである。

一方で、普段テストコードを書いていないと、特にテストによる「心理的な安全性」をなかなか理解してもらえない。 「テストファースト」という言葉に囚われて、「コーディング前にテストを考えるなんて無理だ！」となっている人を周囲で見かける。 また、利用する言語やフレームワークといった知識を十分に持ってない場合コーディングもままならないため、 「どうやってテストをするか」ということを想像しづらい、ということもある。

そのため、このドキュメントでは「テストファースト」には強くこだわらないようにする。 ただし、プロダクトコードとテストコードは必ずセットにする、という点には注意を払って進めていく。