ざっくりWebpack入門 Vol.1

こんにちは。TECH DRIVEの小笠原です。
今回は、昨今話題のWebpackについて、自分が学習時に苦労した点などを踏まえ、ご紹介したいと思います。

Vol1の本記事ではWebpackを使ってJavaScriptファイルのモジュール化と依存関係を管理する方法をご紹介します。

Webpackって何者?

モジュールバンドラーと言われるものらしいです。 モジュールをバンドルする(束ねる)ツール。
Webpackにおけるモジュールとは、Webサイトを構成するおおよそ全てのファイル(JSはもちろんHTML/CSS/画像ファイルまで)を指します。

f:id:kabaneshi:20170214155041p:plain

何やら壮大なことができそうですが、壮大すぎてよくわからない。
「全てがモジュール?」「画像ファイルもモジュールなの?」等、Webpackに出会った当初この辺りの感覚が中々掴めずに頭を悩ませました。

この辺りの詳細を含めると話が複雑になるので、本連載では少し話を小さくして、毎回Webpackで行える一部の機能をピックアップしながら、少しずつご紹介していきたいと思います。

本記事でやること

冒頭でも触れた通り、Vol1の今回はWebpackでJavaScriptファイルのモジュール化と依存関係を管理する方法について触れていきます。
環境はnpmが導入済みのMac OSを想定しておりますので、予めご了承くださいませ。

モジュール化について

Webpackの話に入る前に少しモジュールについても触れておきます。
複数の処理が無秩序に書かれたコードは可読性が悪かったり、バグの温床になりがちです。
解決策の一つとして、コードを機能単位で分割(部品化)し、名前をつけて管理する方法があります。
上記を実現するための方法の一つがモジュール化です。 (少々乱暴な言い方ですが)

モジュール化を行うメリットとしては、以下のようなことがあります。

  • どこに何が書いてあるのかが把握しやすい
  • 一度書いたコードを再利用しやすい

JSではモジュールをどう実装すべきかを定義したガイドブックのようなものが複数存在します。(CommonJSやAMDなどがこれに当たります)
しかし、現状ブラウザで動作するJSではガイドブックのルールに従い実装されたモジュールを取り扱う機能がないため、Webpack等のツールを導入しこれを実現します。

依存関係の管理について

JSファイルの依存関係についても少し触れておきます。

依存関係の考慮が必要な例として、jQuery等の外部ライブラリの利用が挙げられます。
当然ですが、jQueryの機能を使用して書かれたコードは、jQuery本体のファイルが先に読み込まれている状態でなければ動作しません。
依存関係とはこのように「あるファイルに書かれたコード」が「別のファイルのコード」に依存している状態を指します。

依存関係は、大抵以下のようにHTMLに記載するscriptタグの順番で管理を行います。

<!DOCTYPE html>
<html lang="ja">
<head>
   <meta charset="UTF-8">
   <title>webpack sample</title>

   <script src="./js/common/hoge.js"></script>
   <script src="./js/common/huge.js"></script>
   <script src="./js/main.js"></script>
</head>

scriptタグはasync等の属性を指定しないかぎり、頭から順番に実行が行われ、先頭の処理が完了するまで次のファイルが実行されることはありません。
そのためjQuery等の「依存されるファイル」は頭の方に書きます。

しかし、依存関係の考慮が必要なファイルが増えてきたりHTMLファイルが多い場合等は、scriptタグでの依存関係管理は煩わしさがあります。
以下では、この煩わしさを解消する方法をご紹介します。

Webpackの導入

前置きが長くなってしまいましたが、ここからは実際のコードを用いて説明をしていきたいと思います。
今回はプロダクトが以下のディレクトリ構造であることを前提に進めます。

├── dist  // HTMLから呼び出されるJSファイル   
├── index.html  
├── src  
   └── js // モジュール化されたJSファイル群  
       ├── entry.js  
       ├── main.js  
       └── sub.js  

まずは、ディレクトリ直下で以下のコマンドを実行し、package.jsonファイルを作成しましょう。

npm init

いくつかの質問が続いた後に、package.jsonが作成されていれば成功です。 つづけてWebpackのインストールを行います。

npm install --save-dev webpack

これでWebpackを利用するための準備ができました。

必要なファイルの準備

次にモジュールファイルの準備を行っていきます。
今回は上記で少し触れたCommonJSのルールに従いモジュールの定義や呼び出しを行います。
まずはsrc/js直下に以下の2つのファイルを用意します。

  • src/js/main.js
    main.jsの中身は実行時にアラートダイアログを表示するだけのシンプルな処理です。 module.exportsに代入をしている関数がモジュールとなります。
module.exports = function() {
  alert('Hello world');
}
  • src/js/sub.js
    sub.jeの処理は実行から2秒後にアラートダイアログを表示します。
module.exports = function() {
   setTimeout(function(){ alert('Hello webpack'); }, 2000);
}

次に作成したモジュールを呼び出し、実行するためのファイルを作成します。
CommonJSではrequireという仕組みを通し、exportsに追加したモジュールにアクセスを行いますので、そのように書きます。
src/js/entry.js

// モジュールファイルの呼び出し
var main = require("./main"),
    sub = require("./sub");

// モジュールの実行
main();
sub();

先ほど、依存関係について触れましたが、ここではentry.js内のコードが依存する処理をrequireを使って呼び出しています。
呼び出し元や呼び出し方が違うだけで、これはHTMLから外部のJSファイルを呼び出すのとよく似ています。
Webpackを使用することで、このようにJSファイル内で依存関係を管理できるようになります。

Webpackで使用するファイルについて

ここで、これまで作成をしてきたファイルについて少し整理をしてみたいと思います。

f:id:kabaneshi:20170214173314p:plain

  • 1. モジュール郡
    機能単位で分割されたファイル。
  • 2. エントリーポイント
    分割したモジュールファイルの呼び出しや実行処理を記載するファイル。
    このファイルをビルドすることで、複数のJSファイルが一つに結合される。
  • 3. 実行ファイル
    2のビルド結果。HTMLから呼び出されるファイル。

JSファイルの結合と実行

最後にentry.jsをビルドし、dist直下に出力してみたいと思います。

今回のルートディレクトリ直下で以下のコマンドを実行してください。
webpackコマンドの第一引数にエントリーポイントのファイル情報、第二引数に結合されたファイルの出力情報を渡します。

webpack src/js/entry.js dist/build.js

コマンド実行後、dist直下にbuild.jsが作成されたことを確認してみましょう。

結合ファイルの実行

作成したbuild.jsをHTMLファイルから読み込んだ際に期待した結果になることを確認してみましょう。 ルート直下にindex.htmlファイルを作成します。

index.html

<!DOCTYPE html>
<html lang="en">
<head>
   <meta charset="UTF-8">
   <title>Document</title>
</head>
<body>

<script src='./dist/build.js'></script>
</body>
</html>

index.htmlをブラウザで開いた際に、アラートダイアログとして「Hello world」が表示され、それを閉じた2秒後に「Hello webpack」が表示されれば成功です。

設定ファイルの作成

webpackコマンド実行時にいちいち引数でファイル名を渡すのは、面倒かと思います。
これは、設定ファイルを作成することで解決できます。
ルートディレクトリ直下にwebpack.config.jsというファイルを作成し、以下の内容を記載してください。

webpack.config.js

module.exports = {
     entry: './src/js/entry.js', // ビルド対象のファイル情報
     output: {
          filename: "./dist/build.js" // 出力先のファイル情報
     }
};

上記のようにentoryにエントリーポイントのファイル情報、outputに出力情報を記載することでwebpackコマンドのみでファイルの結合/出力が実行できます。

まとめ

いかがでしょうか?本記事を通して少しでもWebpackの輪郭をつかんで頂けたのなら幸いです。

Vol2ではWebpackのloaderという機能を使いES6のトランスパイルをする方法をご紹介したいと思います。

初心者向けにできるだけ噛み砕いてみるオブジェクト指向 vol.1 規格化されることの威力を知る

はじめに

vol.0 にて長い前置きがありましたが、オブジェクト指向の目的や、広く受け入れられる背景を知っていただいた上で読んでいただきたいと思ったので書いてみました。

改めて「新たな要望を短時間で実現する」をどうやったら実現しやすいかなと考えた時、一つの回答として規格化するとやりやすいということがあると思います。今回はそのイメージをお伝えすることをゴールにしてお送りします。

規格化のメリットを知る

コードをあまり書いたことが無い人にもある程度伝わるように考えると、何かにたとえることが必要になってきそうです。何かシステムっぽいものがあると話がわかりやすいと思うので、下記のようなスマホを使った簡単なステレオのシステムがあると思ってください。

f:id:ms2sato:20161203194903p:plain

これから様々な要望が出てきた場合と、その対応について一緒に考えましょう。

交換可能なので嬉しい

「本体から遠くで鳴らしたいのだけど…。」という要望があったとしましょう。

皆さんはすぐに 「今使っているのは1mの長さだから、5mのUSBケーブルを買ってきて付け替える」 のように行動すると思います。簡単ですよね。

これが実現できるのはなぜでしょうか。 「USBという規格に合わせて様々なケーブルが作られているから」 に他なりません。

また、USBケーブルのメーカーは沢山あります。規格化されているので、作る人が誰でも大丈夫です。また、ケーブルに使われる金属や太さなどもマチマチです。これができるのもUSBという規格があるお陰ですね。

f:id:ms2sato:20161203194909p:plain

もしもUSBという規格なしにこれをやろうとすると、まずコネクタの形状を調べるところから始めて、どんな風に電気を通せば良いのかを確かめてなどしてから形状に合わせた設計図を書いて発注し…となってしまい、完全オーダーメイド。とても時間がかかってしまいます。

一体型のステレオで同じことをやろうとするとまず分解するところから始めそうです。これはもっと時間がかかります(今はイヤフォンジャックで外部スピーカー繋ぐとか、オーディオ端子で…とかは忘れてくださいごめんなさい)。

f:id:ms2sato:20161203194914p:plain

使い方さえ知っていれば中の複雑さを知らなくていいので嬉しい

規格化されているので、USBケーブルの中身がどうなっていて、具体的にどんな通信を行うものかを知る必要はありません。必要なのは「両者をつなげれば動く」という性質だけです。このおかげで、たくさん勉強する必要なくシステムを完成させることができます。

f:id:ms2sato:20161203194918p:plain

再利用できて嬉しい

USBケーブルをお友達に貸してあげることができます。お友達はPCとタブレットをつなぐという全く違うシステムを作る為に使うのかもしれません。このように同じUSB規格を利用できるところに、一度作られたケーブルを使いまわせます。

貸してあげるところまでいかなくても、スマホの部分を本格的なステレオ機器に付け替えることも、逆にスピーカーをもっと携帯性の高いものに付け替えることも簡単です。

f:id:ms2sato:20161203194922p:plain

全ての完成品がなくても試験できて嬉しい

特にソフトウェアで面白いのは、作っている途中での活用です。ケーブルを作っている工場を想像しましょう。スマホは既存の製品があるけれど、作っている最中にスピーカーで音を立てると周りの人に迷惑なので「スピーカーらしきもの」で代用しています。例えば鳴っている音をビジュアル化して表現したりして「USB規格を実現したスピーカーを繋いだらきっと鳴るよ」ということをテストしているんですね。テストに合格したら、ちゃんとしたスピーカーに繋いで音を鳴らしてみなさんに聞いてもらうんです。ソフトウェアのテストでもこれと同じようなことをしています。

f:id:ms2sato:20161203194925p:plain

オブジェクト指向と規格化

前回出てきた「技術者の心の声」のうちの何点かを規格化に絡めた例にして挙げてみました。他にも考えられるかもしれませんが、概ねポイントは押さえられたと思っています。こういったことを実現できるようにソフトウェアを作る人は努力しています。ひとえに新たな要望を素早く実現するためですね。

そしてオブジェクト指向は、このような「部品化して規格化する」ということにとても近いです。そのメリットも上記のような「規格化されたUSBケーブルを差し替える仕組みにすれば扱いやすいし、要望をより短時間に実現できる」ということと、とてもよく似ています。部品化して規格化することで実際の工業製品のような作り方をしましょう、という感じかもしれません。

このたとえ話をもう少しソフトウェアの実情に合わせてみると、

  • USBのような「規格を決めること」がインターフェースを決める(もしくはダックタイピングのためのメソッド群を決める)
  • 「USBケーブルを作る」がクラスを実装する
  • スマホとスピーカーを実際に繋いだものが出来上がったシステム全体

のように当てはめることができます。

「新たな要望を短時間で実現する」という目的を達成するために、このような規格化によって対応しているのですね。USBケーブルを簡単に入れ替えていたように、ソフトウェアも入れ替えやすさを意識して作ると良いソフトウェアに近づくと思います。

次からはコード出していきますね。 と、思っていたんですけどこのネタで会話してたら別の内容を一回挟みたくなったのでもう一回イメージの話になりました

【インフラ初心者向け】Dockerで作るRuby on Rails 開発環境 第1回『 Docker概要、メリットをざっくりと 』

こんにちは。TECH DRIVEの齋藤です。

今回の連載では流行りのDockerを使ってRuby on Railsの開発環境を構築していきます。 この連載記事は「インフラ初級者の方」を対象にしています。

私自身アプリケーションエンジニアでインフラに関してはまだまだということもありますので、 読者の方々の目線に立ちつつも試行錯誤しながら環境作りをしていきます。 なるべく簡単な説明で書いていきたいと思っていますので、一緒に頑張っていきましょう!

連載の章立てはこちら(後々章立ては変更される可能性があります)。

  • 第1回 Docker概要、メリットをざっくりと。
  • 第2回 DockerfileでRailsの開発環境を作ってみよう(準備編)。
  • 第3回 DockerfileでRailsの開発環境を作ってみよう。
  • 第4回 Docker-ComposeでRailsの開発環境を作ってみよう。
  • 第5回 データやソースコードをVolumeで管理してみよう。
  • 第6回 Dockerの使えるコマンド編

Dockerの概要、メリットは何?

Dockerの仕組みはいろんなページに載っていると思うので 「インフラ初級者にとってのDockerのメリット」という視点で書きたいと思います。 使用した感じから、本当にざっくり言うと

「他人の作った『環境』を自分の手元でもお手軽に構築することのできるサービス(仮想化のためのソフトウェア)」です。

他人の作った『環境』を自分の手元でもお手軽に構築するって?

MAMPあるいはXAMPPはご存知ですか? 例えばMAMPは、Mac 上でApache、MySQL、PHPの環境を簡単ダウンロードして使えるサービスです*1。 よくLAMP環境と言われたりしますね*2。 PHPで開発をするときにLAMP環境をいちから構築するのって大変だと思います。

そんなときMAMPを使えばインフラをよく知らなくても簡単にLAMP環境を利用できちゃう、そんな代物なのです。 Dockerを使えば同じように簡単にLAMP環境を利用できてしまいます。

「じゃあMAMPでよくない?」

というのはもっともな疑問ですね。

ただしDockerはMAMPだけではなく、Ruby on Railsの環境や、Wordpressの環境など様々な他人が構築した環境を利用できるのです! 他人が構築した環境ということは、例えば典型的なWordpress環境だけでなく、もしアップロードされていれば「超高速で動く」Wordpress環境だって簡単に利用できてしまうのです。 もちろん、仲間が作った環境も利用できるので開発環境も共有できます。

f:id:shoheis:20170104235404j:plain

もう一つの大きな違いは、OSから構築するか、しないかということです。 MAMPはMacOSのようにすでに存在しているOS上にダウンロードして使います。 DockerはOSから丸ごと構築して使います。 つまりは他と同じOSの環境で動かすことができます。 このことにより「開発環境のOS上では動いたのに本番環境の別OS上だと動かない」なんてトラブルとはオサラバです。

仮想化のためのソフトウェアって?

Dockerを使えばPCの中に「コンテナ」と呼ばれる仮想的なマシンが構築できます。 コンテナによってPCの中にもう一つPCが作られるイメージです。 Dockerは他人が作った環境をこのコンテナ単位でダウンロードして使います*3。 このダウンロードの仕組みや他人が作った環境をアップロードする仕組み、その他一連の仮想化のための仕組みをDockerは提供しています。

f:id:shoheis:20170124183115j:plain

他人の作った「環境」はどこに集まっているの?

一般的に私たちが利用できるダウンロード元で一番有名なものはDocker社が提供する「Docker Hub 」が考えられます。 なんとすでに30万以上のアプリの環境がアップロードされています。 公式のリポジトリもありますので欲しい環境がないか探してみるのもありですね!

https://hub.docker.com/explore/

ダウンロードの仕方については、これから掲載する第2回、第3回、第4回で紹介させていただく予定です。

自分で環境を構築することはできるの?

もちろんできます。ただインフラ初心者の方にとって完全に自力でやるのはハードルが高いかもしれません。 ですので次回から説明を交えつつ数回に分けて環境の構築の仕方を説明していこうと思っています。 その中で他の仮想化のためのソフトウェア「Virtual Box」との違いも簡単に触れていけたらいいと思ってます。

では次回は、環境構築編として、DockerfileでRailsの開発環境を作ってみよう。に取り掛かろうと思います。

*1: 最近はWindowsでも使えます

*2:LAMPのLはLinuxのことです。

*3:厳密にはダウンロードするのは「イメージ」というコンテナの雛形です。ここは想像しやすいようにコンテナとしています。

フロント開発初心者向け 〜 jQueryが何を提供してくれているのかを考えてみる 〜

こんにちは。TECH DRIVEの小笠原です。
自分がよく参加させていただいているもくもく会でフロント開発初心者の方から、jQueryについての質問をいただくことが多く、その中で↓の様な悩みを抱えてる方って多いのでは?と感じたので、フロント開発初心者の方に向けて、この記事を書くことにしました。

  1. JavaScriptとjQueryの違いが曖昧
  2. jQueryを独立した開発言語だと思っている(ライブラリと言われてもしっくりこない)
  3. jQueryを使うと何が嬉しいのかがいまいちわからない

jQueryを使用する上で、ライブラリが包含してくれている処理やメリット/デメリットを意識することは、開発効率にも影響を及ぼします。
この記事が少しても上記の様なお悩みを持っている方のお役に立てればと思います。

jQueryが提供してくれているもの

まずはじめにjQueryとは何者かをおさらいしたいと思います。 jQueryとはざっくり言うとJavaScriptが提供している機能をより扱いやすくしてくれるためのライブラリです。
jQueryを使用することにより、JavaScriptが提供してくれている一部の機能が簡潔に書ける様になります。

f:id:kabaneshi:20170105025307p:plain

ではjQueryはJavaScriptのどの様な処理を扱いやすくしてくれているのでしょうか?
jQueryが提供してくれる機能で頻繁に使用されるものを以下に記載していきたいと思います。

DOM操作

DOM(Document Object Model)とはHTMLやXML文書を取り扱うためのAPIです。 小難しく書きましたが、JavaScriptにおいてDOMとはHTMLで記載された文章を操作するためのインターフェース(仲介役)です。

例えば、以下の様にprofileというidを持ったHTML要素のテキスト情報を取得する場合を考えてみます。

HTML

<p id="profile">僕はエンジニア</p>

JavaScript

// ネイティブのJavaScriptで書いた場合
document.getElementById('profile').innerHTML; // "僕はエンジニア"

// jQueryで書いた場合
$('#profile').text(); // "僕はエンジニア"

上記はどちらともDOMを介して、HTMLの要素 id="profile" が持つテキスト情報を取得しています。 しかし、jQueryで書いたコードの方がより簡潔であることが分かるかと思います。

また、この手のDOM操作を行うメソッドをネイティブのJavaScriptで書く場合、古いブラウザ(IE8以下のMS製ブラウザ等)において、挙動がおかしかったり、そもそもHTML要素の取得を行うメソッド名が違っていたりするケースが存在します。
※ class名から要素を取得するgetElementByClassはIE8以下のブラウザでは実装されていなかったりします。

jQueryでは、この様な複数のブラウザ間における差異も吸収(クロスブラウザ対応)してくれるメリットもあります。

イベント処理

イベント処理とはブラウザ上で何かイベントが発生したタイミングで実行される処理を指します。

f:id:kabaneshi:20170105025629p:plain

例えば、Webページ読み込み時に発生するイベントで何かしらの処理を実行したい場合(※)のコードをJS/jQueryそれぞれで書くと以下の様になります。 ※ DOM構築完了時に処理を実行する場合

// ネイティブのJavaScriptで書いた場合
document.addEventListener('DOMContentLoaded', function() {
  実行したい処理
});

// jQueryで書いた場合
$(function(){
  実行したい処理
});

やはり、jQueryのコードの方が簡潔です。
またjQueryを使用する際、よく上記の様なコードを見ることはありませんか?
このコードの正体は、DOM構築が完了したら処理を実行してねという命令文だったんですね。

また、JavaScriptを書いているとブラウザ上で何かしらのユーザーイベントが発生したタイミングで処理を実行したいケースがあります。

例えば、サイト上のボタンがクリックされたら何か処理を実行した場合等です。

下記にWebサイト上のボタンクリック時にイベント処理を行うためのコード(※)を書いてみます。
※ 下記のコードは、JS/jQueryでユーザーイベント処理を設定する場合の一例です

HTML

<button id="event_btn">イベントボタン</button>

JavaScript

// ネイティブのJavaScriptで書いた場合
var btn = document.getElementById('event_btn'); // ボタン要素の取得
btn.addEventListener('click', function(){ // イベント処理登録
  実行したい処理
});

// jQueryで書いた場合
var btn = $('#event_btn'); // ボタン要素の取得
btn.on('click', function(){ // イベント処理登録
  実行したい処理
});

やはりjQueryを介して書かれたコードの方が簡潔に見えます。

先ほどの「DOM操作」の項でも記載しましたが、ここでもjQueryはクロスブラウザ対応をしてくれています。
ネイティブのJavaScriptの場合、IE8以下ではaddEventListenerが存在していないので、代わりにattachEventメソッドを使用し同等の処理をおこないます。

いかがでしょうか?ここまで読んだいただくとjQueryが何者でどの様なメリットを提供してくれているかが少し見えてきたのではないでしょうか。
また、既にご存知の方もいるかと思いますが、どのコードにもjQueryを使用する際に必ず$マークが存在しています。
実はこの$こそがjQueryの正体であり、jQueryの機能は全てこの$を通して提供されます。

jQueryのデメリット

ここまでjQueryのメリットばかりを記載してきましたが、デメリットについても少し紹介をさせていただきます。

1. 読み込みを行うファイルが増える

jQueryの機能を使用するためには、jQueryファイルを読み込む必要があります。読み込むファイルが増えるということはサーバとの通信が増えるということになり、その分Webページを表示するスピードは遅延します。
※ jQueryの読み込みだけでは、ユーザーに影響を及ぼす程の遅延は発生しませんが、HTML上から読み込むファイルが増えれば、それだけサーバとの通信が増えるということは意識しておくといいかもしれません。

2. 処理が遅くなる場合がある

上記で挙げたクロスブラウザ対応等をしてくれているため、jQuery内部では複雑なJavaScript処理が行われています。書き方や処理内容によってユーザーの体感速度を落としてしまう場合もあります。 for文等の繰り返し処理の中で、不要にjQueryメソッドを使用してしまっているケースなどが例として挙げられますが、この部分はコードが合ったほうがわかりやすいかと思いますので、そちらに関しては別途記事を書こうと思っています。

まとめ

昨今は、フロント環境の変化に伴い脱jQueryの傾向も強まってきています。
上記であげたデメリット以外でも最近のJSフレームワークとの相性問題やモダンブラウザにおいてクロスブラウザ対応をあまり気にする必要がなくなってきたということもあり、jQueryの導入に推敲が必要な時代になってきています。

しかし、僕個人の感想としては、やはりjQueryが提供してくれているインターフェースは素晴らしいもので、もうしばらくはjQueryをお世話になることが多い様に感じているため、この記事を書かせていただきました。
この記事が少してもフロント開発初心者の方のお役に立てたのなら幸いです。

初心者向けにできるだけ噛み砕いてみるオブジェクト指向 vol.0 プログラマーはどのようにソフトを作りたいのか

はじめに

TECH DRIVEの佐藤正志です。こんにちは。

この文章やそれに繋がる一連の連載は、プログラミングを少しやってみたけどまだこれからの人たちへ「オブジェクト指向ってこんなもの?」というのを伝えられないかと思って頑張って書いてみているものです。そのため専門的な言葉やニュアンスが多少実情と違っている可能性をご理解ください。

書いてる私としては、結構繊細な内容でもあるので多少の緊張もありますね。お手柔らかにお願いします。 最初はコードの話が出てきませんが、回を追うごとにだんだん出てくる想定で進めています。

そして今回は vol.0 ということで、まだオブジェクトの話は出てきません。期待してくださった方、vol.1 以降を楽しみにしていてください。

「新たな要望を短時間で実現する」という目標のために

物事を考える時に、目指している理想の姿や目標を知ることは理解する手助けになるはずです。そこでまずは「より良いソフトウェアを開発しようとする際にどんなことを目標にしているのか」について、意識を合わせさせてください。

ソフトウェアの世界にはオブジェクト指向に限らず多くの考え方・方法論がありますが、大きな目標としては「新たな要望を短時間で実現する」ということに集約されると考えて良いと思います。

要望は大きく分けると新規開発、追加開発、保守対応などあると思います。「短時間で実現」という言葉から新規開発でのリリースまでの時間をイメージした方がいるかもしれませんが、その後の追加や保守の時間も減らすべき目標になっていると理解してください(ぐちゃぐちゃなソフトをとっととリリースすると、その後の追加開発や保守がとても遅くなります。これでは目標を達成できません)。

f:id:ms2sato:20161128154456p:plain

そしてよく聞く「品質」という言葉はこの目標の達成しやすさの度合いを表していると思います。「品質の高いソフトウェア」は新規開発のみならず、追加や保守への要望に素早く対応できるものと言っても良いのではないでしょうか。

目標を達成するには何を心がけたら良いのか

目標を達成したい技術者の心の声を要望として分解して示してみます。私は下記のような感じです。おそらくある程度の技術者が賛同してくれるのではないかと思っています(性能等についても考えていますが、主題と外れるので外しました)。

f:id:ms2sato:20161128152142p:plain

これは要望をまとめたものですが、逆に考えると、広く受け入れられている方法論はこういう要望を実現しやすいもののはずです。今回話題にしたいオブジェクト指向も上記のような多くの要望を実現するための「道具の一つ」であると考えて良いでしょう。

実際にやるのは「わかりやすくまとめて分割する」だけ

前項で見たような様々な要望があるにもかかわらず、ソースコードの扱いという切り口から考えると「わかりやすくまとめて分割する」ということしかしていないように思います。例えば下記のようなまとめ方があったりします。

  • 関数を作る: ある処理に名前をつけてまとめてしまうことで、名前を呼ぶだけで一連の処理を呼べるようになります。呪文を作る、のような感じですね。
  • ファイルを分ける: 一つのファイルにたくさんのことが書いてあるとわかりにくくなっていきます。ある一定の単位でファイルを分けるということをします。長くなってしまった呪文の書を章ごとに複数の本に分けたりするようなイメージですね。
  • モジュール化する: 複数の関連するファイルをまとめて、コードの関連をわかりやすくします(言語や環境によってモジュールという言葉の指す意味が違ったりしますが、設計で広く知られていそうな表現で示しました)。呪文の書が増えてきた時に、「xx編」のようなまとまりを作るような感じでしょうか。

オブジェクト指向でよく出てくるクラスもこの「ソースコードのまとめ方」の一つです。また「何をどのようにまとめるか」の上手下手で、ソフトウェアの品質はかなり変わってしまいます。整理整頓が上手であれば、ソフトウェアは素早く変更に対応しやすくなる、というイメージが伝われば幸いです。

上手なまとめ方の強い武器であるオブジェクト指向について、これから少しずつお送りしていきたいと思います。 続きはこちら

TECH DRIVEについて

TECH DRIVEは「技術者の成長を加速させる」をキーワードに都内で活動をしているコミュニティです。
TwitterやFacebookにて技術ネタやイベント情報の発信を行っていますので、ご興味があれば、いいねやフォローをお願いいたします。