private-works
ライブラリを作る事でプログラミングスキルは本当に向上するのか。
Posted by Miki Ishijima on .デザイナーのわたしがプログラムの基礎をだいたい3日で覚えた1つの方法で、Minecraftとプラグインを使ってのプログラミングの楽しさについて書きました。
あれから、いまだに飽きもせず休みの日などにコードを書いています。
まだまだ微妙なこともあるのですが、いくつかプログラムを作ってみて良く使う機能をライブラリにしておきたいなと思ったので作ってみました。
他の人にも使ってもらえるといいな。
ライブラリ作成の実際の流れ
いきなり作るのは無理でした。何が良く使うものなのか、汎用性を高められそうなコードはどれか。などを最初から考えるのはわたしには難しいです。
けっきょくは
1.作りたいプログラムをいくつか書く。 2.良く使うものをピックアップ 3.ライブラリにコピペ 4.変数や値を置き換え 5.作ったプログラムに逆輸入 6.動作確認
と、いう流れになりました。
プログラム力は向上するのか
答えはイエスです。
実際、本当に初心者ですし設計の考え方もうまくはありません。
- もっと分かりやすい名前にできないか
- どのようにコメントをいれていけば他者が分かるコードになるのか
- 決め打ちで書いていた部分を引数で処理できるようにできないか
- 同じような処理をひとつの関数でまとめられないか
を強く意識するようになりました。
ひとりで使うコードであれば、その場で動けば良いのでかなり汚いです。 何回も書いていると、ここはライブラリに実装してしまった方が「自分が」ラクになるので、良く使うものをまとめだします。
一度自分の書いたコードの読みづらさを感じると、次に書くときにはもっとキレイに書けるように。
こんなサイクルが回り出します。 プログラムをたくさん書いていけば自ずと上がるものだと思いますが、何度も使えるようにライブラリ化する。というサブクエストのおかげで、漫然とコードを書くことが少なくなったように思います。
もっと分かりやすい名前にできないか
例えばx,y,zなんかの変数は良く使うだけに被りやすいです。関数もいくつも定義しているとあっという間にボキャブラリを使いつくしてしまいます。
placeTourchという「松明を一定感覚に置く」という処理の関数でした。実際は松明じゃなくてもアイテムなら他のも置けるので、placeItemに変更してみたり。
変数に名詞を使うようにしたのですが、これはこれで長くなると面倒ですし…。 一文字で良い変数と、ちゃんと分かりやすい名前にしておいた方が良い変数。
スコープが小さい場合には、短くて使いやすい変数の方が良く、逆にいろんな箇所で参照されるような変数は長くても分かりやすい名前の方が安全でしょう。
まだまだ「出来る！」というレベルには及ばないけど、なるべくそれに沿う努力ができるようになりました。
スコープ
変数や関数が参照される範囲のこと。 何も考えずに変数を定義したり、いろんなところで使っちゃうと、思わぬところで書き変わってたりしてバグのもとになりますよ！
どのようにコメントをいれていけば他者が分かるコードになるのか
HTMLは見ればなんとなく分かることが多いと思いますが、CSSや他のプログラム言語だと、変数を初期化して、関数を定義して、実行部分が〜と書いたりする必要がでてきます。(全ての言語ではありませんが)
実行部分で関数を呼び出していると、どの関数か見るためにスクロールを繰り返すのもちょっと面倒ですよね。
また、定義された関数を上から読んでいくのも疲れます。
ですので、なるべく「これはどんな処理をしているのか」が分かるようなコメントがあると分かりやすいなぁと思いました。
CSSのフレームワークであるBootstrapなどは丁寧にコメントされていて、何故そのコードが定義されているかが分かりやすいので、カスタマイズも容易ですしドキュメントを読まずとも理解することができます。
コメントが丁寧なので、ドキュメントなしでも意図が分かる。
決め打ちで書いていた部分を引数で処理できるようにできないか
繰り返す回数や、関数内で処理する変数、ComputerCraftで言えば操作する向きなど、そういったものを決め打ちで入れていた箇所が変わっても動くようにするのはとても面白かったです。
左はチェストを置いてアイテムを格納する処理。右側は汎用性を持たせるため、アイテムを収納する部分だけを抜き出して関数にしたもの。forで繰り返す回数や、turtle.dropDownなどで決定されるアイテムを落とす方向を引数で処理できるようにしている。
みるみる便利になりますし、ライブラリとして別ファイルに移設すると、アプリケーション本体が非常にスリムになっていきます。
そういった様子を見るとキレイにコードが書けた気がして一番楽しかったです。
同じような処理をひとつの関数でまとめられないか
例えば、前を向いてアイテムを回収する処理。上を向く場合、下を向く場合で関数を3つ作っていました。
左側が古い方、方向によって3つの関数が定義されている。右側のように引数で方向を渡し、文字列で結合するようにして、テーブルのキーとして渡すことでひとつの関数で処理するようにしている。
プログラムの師匠に教わりLuaのテーブルが少しだけ分かったので、これもひとつの関数でまとめられるようになりました。
これがもう大活躍で、多くの処理がこれでまとめられるようになり、一気にスリム化することができました。
Read Meを書くってカッコいい！
githubなどで良く見るreadme.mdown。自分でも書くときが来るなんて！とちょっとワクワクしました。
change logの重要性
いままでは、見向きもしていなかったchage logですが、何が変わったのかはスゴく重要ですよね。例えば以前から使っていた関数名が変更になったり、処理の仕方が変わったりしていたら。
そんなときに必要なんだと、作ってみるまで分からなかったです。(そういう使い方しかしていなかった自分がアレなんですが…。)
コミットログを抜き出して整形したり編集して、change logをカンタンに作れるものってないのでしょうか？
バージョンの付け方
同時にバージョンの付け方も勉強になりました。0.0.0みたいなカタチ。多いですよね。
あれは、左からメジャーアップデート、新機能追加、それ以外の細かいアップデートなんだそうです。これって常識だったのかしら…。
長くなっちゃった…。
解説やサンプルコードを入れたり、上記のchange log、さらに付属ファイルの使い方なども入れていくとread meが膨大になっていきます。誰も読まないのでは？というレベルです。
ここまでくると、それっぽいサイトのひとつでも作った方がいいのでしょうか？
最後に
今回はMinecraftというゲームのMOD(プラグインのようなもの)のライブラリでしたので、国内では非常に少なく作る意義のあるものだった。というのは非常についていたなと思います。
jsなどの言語だとあらかたあって、何を作ったらいいのやら？となりそうですもんね。
ただjQueryプラグイン系も非常に似たカタチで実装するものですので、良く使うのだけれど決定版がない！というものは実装してみると面白いかもしれません。
ぜひ、一緒にMinecraftやりましょー！！！
