Ruby on Railsを主に使用して開発をしている石黒です。

開発に携わっておよそ1年が経ちますが、私は元々、プログラミングが得意なほうではありませんでした。といってもプログラミングの入門本は読めば一通り理解できますし、概念が分からないというほどではないのです。しかし入門本というのは文法や機能は教えてくれますが、どんな書き方がベターなのか？という問いには答えてくれないのです。

私の場合、めげずに1年間作り続けたところ、入門本には無いノウハウがついてきました。現在は1年前に書いたコードを少しずつ書き換えています。今日は、Rails開発で右も左も分からなかった頃から改善したところを紹介します。プログラミングに慣れている人にとっては些細なことかもしれませんが、私にとってはHello worldからやっと一皮むけたという進歩です。

仕様をきちんとつめる

まずは紙とペンを持ちましょう。ロジックに問題が無いか確認します。ハッカー的な開発手法として”とにかく先にプロトタイプを作る”という話がありますが、それはある程度熟練したプログラマーが行うから成り立つものだと思います。彼らは瞬時に設計を行っているだけなのです。初心者はルールを覚えるだけで精一杯ですから、ある程度構造が分かった段階で仕様や論理を再び考えるとよいと思います。

テストを先に書く

私はRSpecを使いはじめました(Railsにおいては最近だと、Test::UnitよりもRSpecのほうが、情報が充実している印象です)。

RSpecはプログラムの”振る舞い”を記述することでテストとする仕組みです。よって、仕様をきちんと詰めていないと、このステップにたどり着けません。また、後述するModelとControllerの分離も、テストを書くようになれば自然とよくなります。逆に、実コードを先に書いてしまうと、あとから非常にテストしづらい、分離の悪い構造になってしまうのです。

RSpec の入門とその一歩先へ – t-wadaの日記

テスト駆動開発について僕は誤解していた – 偏見プログラマの語り！

デバッグのやり方を工夫する

なにも分からないうちは、指針無くコードを変更していって目的に近づけるような行動をとってしまいます。できればステップ実行ができるデバッガがあればそれを用いたり、Railsであればサーバログを冷静に読む、rails consoleで再現してみる、logger.debugでデバッグプリントをするなどで心理に近づきたいです。独りよがりなデバッグはやめて、プログラムと対話していく方法を取るような感覚です。

テストが通らない部分を見つけ、そこから部分的にデバッグしていくという指針です。実装しながらなんかおかしいなーと無用なデバッグプリントばかり増えていったのが初心者のころのやり方でした。

Railsでデバッグをする７つの方法 – Hello, world! – s21g

ModelやHelperに処理をなるべく移す

慣れないうちはControllerになにもかも書いてしまいがちで、それでも動いてしまいます。始めのうち、Modelにはアソシエーションの記述しかないという事態でした。RailsのMVCの実装は、Modelが薄くなりがちであまりよくないという話もありますから、重複しそうなコードはどんどんModelに移していってます。Viewも同様に、似た記述が増えそうならHelperに書いていくべきでしょう。

Ruby on Railsの「えせMVC」の弊害

the { buckblogs :here }: Skinny Controller, Fat Model

Ruby流のやりかたや、オブジェクト指向に親しむ

以前はgetter, setterの実装や命名を、Java風に行っていたため、Railsの他の文と非常に釣り合いのとれないコードになっていました。Rubyのgetter, setterは特に独特のようで、Ruby流に書けばとても簡潔にできます。

また、Model内部での機能の隠蔽をきちんと考えて作ることで、Controller, Viewの実装が楽になります。

Rubyを仕事に使うべし！ – Part1　なぜ仕事で使うとうれしいのか：ITpro

Rubyのsetterメソッドは特別扱いされる。 – こせきの技術日記

公式ドキュメントを読む

最後に最も有効なものは、公式ドキュメントです。Railsの場合、入り口はとても丁寧に用意されています。本家Rails Guildesに大抵のことは載っています。また、Devise等のライブラリも導入方法やTipsが公式サイトに存在します。いちいちネット検索の古い情報に振り回されるのはやめましょう。まずはオフィシャルです。

Ruby on Rails Guides

これから読みたい書籍

バグを出さないプログラミング

大学の図書館でたまたま見つけました。実践的であまり難しくないです。コード規約のことや、複雑さはバグの温床になるという話などが載っていました。プログラミングの初心者にもおすすめできます。

リーダブルコード――より良いコードを書くためのシンプルで実践的なテクニック

まだ読んでないんですが、出てからかなり売れてるみたいです。上と似てますが、オライリーなので、分量がありそうですね。

さいごに

今回は、入門本レベルから持続可能なプロジェクトに発展させるという観点で書きました。設計の部分が苦手な人はとにかくプログラミングに沢山の時間を費やしましょう。考えてみれば、苦手だからと言ってプログラミングのチャンスを避けてきたような気がします。学生であれば競技プログラミングに触れてみるのもいいかもしれません。私の場合、隙なく短時間で設計をする訓練になりました。並行して、テストや良いコードの知識もつけていくと効率がよさそうです。