世の中には、色々なコーディングスタイルがあると思います。
この記事は、始めてプログラミングに取り組んでいる方向けに、こうった書き方がおすすめなのではないかというプラクティスです。
[目次] コーディングの全体の流れ
- HTML Mockup(View)を作り、確認する
- ロジックを作る
- 脳内 / メモ帳プログラミング
- コーディング開始
- コメントをソースコードファイルに書く
- コメントの内容を実装する
- 実装内容をログで表示する
- Viewに適応出来る範囲まで作れたらViewを見て、想定していた値が表示されるかを確認する
- 以降、TODO:コメントが尽きるまでループ
- テストを行う(思いつく限りの正しい値、遷移など)
- 思いつく限りの変な値、挙動をしてみるテストを行う
- おわりに
[1] HTML Mockup(View)を作り、確認する
- マークアップエンジニアなどがいる場合は除く
- iOSアプリのInterfaceBuilder、AndroidアプリのLayout Editorなどの場合も除く
- でも、どちらも、先に画面を作ったほうが分かりやすいと思います
[2] ロジックを作る
1. 脳内 / メモ帳プログラミング
脳内でプログラミングを行い、そののちに、実際にキーボードを叩きましょうというスタイルです。
こちらの記事をお読み下さい。
[脳内プログラミングのススメ 1/2] 「キータッチの速さ？無意味だ」UEIの水野CTOが断じるワケ
実際のところ、私はここまで脳内プログラミングが出来るとは思っていません。しかしながら、脳内でロジックを考え、メモ帳に書き出し、メモ帳の中でロジックの順番を入れ替える、などは十分誰でも出来ると考えています。
たとえば、Qiita.comのAPIを利用して、Qiitaに存在している「sumyapp」さんが書いた記事の最新(最も新しい記事)のタイトルを取得して表示したい場合、下記のようなロジックになります。
- Qiita.com API の「特定ユーザーの投稿取得」するAPIを利用、GETリクエストを行う
- GETリクエストして得られたJSONファイルを扱うことが可能な形式にパース(分析/変換)する
- パース結果の配列の1番目を取得して、名前をつける(変数に入れる)
- 変数に入れた内容を表示する
これだけなら、脳内で考える、メモ帳に書き記す事が出来るのではないでしょうか？
これを事前に行なっておくと、コーディングに移った際に、高速に実装することが出来ます。
脳内プログラミングなら電車の中でもご飯を食べながらでも、いつでもどこでも何もなくても行うことができます。
(もちろん、脳は必要です。)
2. コメントをソースコードファイルに書く
# Qiita.comのAPIを利用して、Qiitaに存在している「sumyapp」さんが書いた記事の最新(最も新しい記事)のタイトルを取得して表示する
def show
# TODO: Qiita.com API の「特定ユーザーの投稿取得」するAPIを利用、GETリクエストを行う
# TODO: GETリクエストして得られたJSONファイルを扱うことが可能な形式にパース(分析/変換)する
# TODO: パース結果の配列の1番目を取得して、名前をつける(変数に入れる)
# TODO: 変数に入れた内容を表示する
end
show('sumyapp')
といった形に、先にコメントでロジックを書いてしまいます。
TODO: といった形で書いておくのは、「未完了作業」であることを明示するためです。
3. コメントの内容を実装する
# Qiita.comのAPIを利用して、Qiitaに存在している「sumyapp」さんが書いた記事の最新(最も新しい記事)のタイトルを取得して表示する
def show(url_name)
# TODO: Qiita.com API の「特定ユーザーの投稿取得」するAPIを利用、GETリクエストを行う
html = open('https://qiita.com/api/v1/users/sumyapp/items').read
# TODO: GETリクエストして得られたJSONファイルを扱うことが可能な形式にパース(分析/変換)する
# TODO: パース結果の配列の1番目を取得して、名前をつける(変数に入れる)
# TODO: 変数に入れた内容を表示する
end
show('sumyapp')
このように、1個目のTODOに対応する形でコードを書いてみます。
TODO内容でGoogleで検索するとたいていどんぴしゃなコードが出てきます。
4. 実装内容をログで表示する
html = open('https://qiita.com/api/v1/users/sumyapp/items').read
p html # デバッグログ出力
実装した内容を入れた変数はデバッグログなどで出力して、正しいことを確認しましょう
実は、上記のコードでは動きませんでした。
ロジック上の漏れではないですが、コード上での実装漏れです。
よくあることです。実行すればすぐにエラーの原因が分かります。
$ ruby users_latest_post.rb
users_latest_post.rb:2:in `initialize': No such file or directory - https://qiita.com/api/v1/users/sumyapp/items (Errno::ENOENT)
from users_latest_post.rb:3:in `open'
from users_latest_post.rb:3:in `show'
from users_latest_post.rb:7:in `<main>'
URLをopen出来るopenメソッドが見つからなかったわけですね。
なので、URLをopen出来るopenメソッドを見つけられるようにします。
# open
require 'open-uri'
# Qiita.comのAPIを利用して、Qiitaに存在している「sumyapp」さんが書いた記事の最新(最も新しい記事)のタイトルを取得して表示する
def show(url_name)
# TODO: Qiita.com API の「特定ユーザーの投稿取得」するAPIを利用、GETリクエストを行う
html = open('https://qiita.com/api/v1/users/sumyapp/items').read
# TODO: GETリクエストして得られたJSONファイルを扱うことが可能な形式にパース(分析/変換)する
# TODO: パース結果の配列の1番目を取得して、名前をつける(変数に入れる)
# TODO: 変数に入れた内容を表示する
end
show('sumyapp')
ちなみに、open-uriは
http/ftp に簡単にアクセスするためのクラスです。 Kernel.#open を再定義します。
http://doc.ruby-lang.org/ja/1.9.3/library/open=2duri.html
といった機能を持ったライブラリです。
これで1個目のTODOは完了です。
5. Viewに適応出来る範囲まで作れたらViewを見て、想定していた値が表示されるかを確認する
TODO内容がViewに表示できる内容の場合であれば、表示させてみたほうがよいでしょう。
早めにユーザーインターフェースの問題などに気づきやすくなります。
今回のコードはViewの作り方を伝える内容ではないため、View部分は割愛させて頂きます。
6. 以降、TODO:コメントが尽きるまでループ
全部のTODOを実施、"TODO: " の部分は消して行きましょう。
今回のコードの場合は最終的にはこういった形になります。
# GET/POSTリクエストでデータを取得出来るライブラリ
require 'open-uri'
# JSONのパースを行うライブラリ
require 'json'
# Qiita.comのAPIを利用して、Qiitaに存在している「sumyapp」さんが書いた記事の最新(最も新しい記事)のタイトルを取得して表示する
def show(url_name)
# Qiita.com API の「特定ユーザーの投稿取得」するAPIを利用、GETリクエストを行う
html = open('https://qiita.com/api/v1/users/sumyapp/items').read
# GETリクエストして得られたJSONファイルを扱うことが可能な形式にパース(分析/変換)する
items = JSON.parse(html)
# パース結果の配列の1番目を取得して、名前をつける(変数に入れる)
latest_item = items.first
# 変数に入れた内容を表示する
return latest_item['title']
end
p show('sumyapp')
[3] テストを行う(思いつく限りの正しい値、遷移など)
プログラミングにはほぼ必ずバグがあります。
正しいと思われる値や操作をあちこちから実施、エラー(正しくない値)にならないか確認しましょう。
問題があれば即時修正しましょう。
[4] 思いつく限りの変な値、挙動をしてみるテストを行う
プログラミングにはほぼ必ずバグがあります。
変なURLを無理やり実行してみるとか、SQL文を入力してみるとか、htmlやjavascriptを入力してみるとか、中国語を入力してみるとか。可能な限りの変な値を入力、結果を確認しましょう。
問題があれば即時修正しましょう。
[5] おわりに
コーディング方法のベストプラクティスとタイトルを付けましたが、実際にこれがデファクトスタンダード(事実上の標準)なベストプラクティスかというと、そうでもないと思います。皆さんそれぞれのコーディングスタイル、開発スタイルがあると思います。
伝えたかったのは、
- コードを書き始めてはいけない
- まずはユーザーへの体験(UI)を考えよう
- そしたらロジックを考えよう
- ロジックを考えたら技術調査を行おう(使えるライブラリはないか？など)
- そしたらやっとコーディング開始しても大丈夫
- コーディングが終わったら必ずテストをしよう
- テストは製品のアップデート毎(たとえばVer1.0.1から1.1.0にアップデート)のタイミングではなく、機能(ユーザ体験、ユーザストーリー)毎にしよう
ということだけです。
"プログラミング=コードを書くこと"と思われがちですが、これは大きな誤りです。
コードを書かないために、頭をつかう、既存の資産を使う、それがプログラミングかと思います。
それでは。
記事を読んでいただきありがとうございました。