Misoca開発で日々使う知識とその情報ソースまとめ

9月末に涸沢の紅葉を堪能してきた@RKTMです。ちょっとピークが過ぎていた&日差しが弱かったのですが、パノラマコースからのパノラマに大興奮でした!
f:id:RKTM:20150930091639j:plain

開発メンバーの知識のばらつき

この記事を書くことになったきっかけはあるPull Requestでのレビュー指摘から。


レビューア「このXxxControllerのインスタンス変数@documentって、view側で使われていないし、ローカル変数documentにしたほうが良いのでは」

実装者「なるほどー。あ、このメソッド内のlambda式でdocumentという名前を使っているので、区別するために@documentのままにしておきます」

レビューア「えっ。変数のスコープは必要ない限り狭くすべきだよ。スコープが広いと、意図しないところから参照されたり、値が変更されたりするので、変数名を変えてでもスコープは狭くしたほうが良いよ」


上記は、実装面での知識不足の事例ですが、 この他にも、

といった、知識のばらつきが顕著になってきました。 その対策として、

  • Misocaの開発で基本的に使う知識
  • Misocaの開発をうまくやるための知識

を明文化することで、

  • Misoca開発チームの共通知識の明確化
  • メンバーの不足している知識の習得

を図ることがこの記事の狙いです。

また、このブログを読んでくださる方はMisocaで働くことに興味もあるかと思いますが (なんと偶然にもMisocaは開発メンバーを募集しています)、 そういった方にMisoca開発チームはどういった知識を使って仕事しているのか、ということを知っていただければと思います。

Misocaの開発で基本的に使う知識

毎日のように必要となる知識です。このあたりを押さえられれば、駆け出しMisoca開発者です。

Ruby on Rails

MisocaはRailsで作られています。

railstutorial.jp これをひと通りやっておくと基礎としては問題ないでしょう。

JavaScript/CoffeeScript/ES6

RailsなのでCoffeeScriptで書くのですが、その前提としてのJavaScriptの知識が必要です。

JavaScript ガイド - JavaScript | MDN JavaScriptを全然しらない人は、このあたりはざっと眺めておきましょう。

CoffeeScript CoffeeScriptついてはここをざっと眺めると理解できます。

Haml/SCSS

haml.info

昔はERBを書いていましたが、「閉じタグを書くには人生はあまりに短い」ということでHamlへ移行しました。上記を読むと大体分かりますが、ERBからの変換を考えるなら、Convert HTML to HAMLを使うと良いです。

sass-lang.com SCSS使っています。凝ったデザインはデザイナーにお願いしますが、最低限のUIは開発者が実装できる必要があります。marginだとかfloatだとかは理解しておきたいです。

RDBMS

MySQL/PostgreSQL使ってます。文書はRDBではなくNoSQLがマッチするよなぁ、という話はしていますが、まだしばらくはRDBMSベースです。

シンプルなCRUDを書けて、Railsの裏側で発行されるSQLを想像できて、あとはトランザクションを張るべきケースが理解できていればOKです。 1週間で学ぶIT基礎の基礎 - 忙しいあなたのためのSQL入門---目次:ITpro

rspec

betterspecs.org

自動化されたテストコードを書いています。ここに記載されている内容はJOINして日が浅いとよく指摘されます。

アジャイルプロセス

KanbanスタイルにScrumのフレームワークを取り入れて試行錯誤を続けています。開発チームの文化として、週次のリズムがしっくりくるため、開発プロセスのイベントサイクルは1週間で運用しています。

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

アジャイルサムライ――達人開発者への道

さくさく読める平易な文章でありながら、実践的なことが書いてあります。 Misocaでの日々の開発における意思決定には、この本で書かれていることが活きています。必読。

スクラムガイド

スクラムガイド * PDF

先日、技術フェローである角谷さんにオフィスに訪問していただく機会があり、スクラムガイドをもとにスクラムの基本について話してもらいました。特に、スクラムガイドと照らしあわせて「Misocaは今どうなのか」という説明をして頂いたのは他では得難い経験でした!

Git/GitHub

GitとGitHubは毎日使います。
clone/pull/commit/push/resetぐらいできれば良いと思います。rebaseはそのうち学んでいきましょう。

www.atlassian.com Git - Book

Misocaの開発をうまくやるための知識

ここまでは日々使うような基本的な知識でした。
しかし継続的なサービスの発展と提供にはよりよい設計・実装が必要です。そんな設計・実装を行うために必要な知識をピックアップしました。

プログラミング

リーダブルコード

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

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

自分が書いたコードはチームメンバーにレビューしてもらいます。読みづらいコードは、レビューしづらく、その後の変更もしづらいものです。読みやすいコードを書くために「リーダブルコード」はオススメです!

Ruby on Rails

Ruby on Rails Guides

Ruby on Rails Guides このあたりをひと通り読めばだいぶ詳しくなれます。困ったらここを読みましょう。

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

RailsによるアジャイルWebアプリケーション開発 第4版

テスト駆動開発で、ショッピングサイトを作りながら、Rails の基本を学ぶことができる本です。

Crafting Rails Applications

pragprog.com 元はモジュール化で設計の整理がされたRails3をベースに、Railsそのものを拡張するにはどうするか、という本で、そのRails4版。著者は最近Rails coreチームを卒業した、Elixirの作者でもあるJosé Valim。RubyKaigi 2013ではkeynote speakerとして登壇しました。

設計

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES)

リファクタリングといえばこれ。コードのもやもやしているところが「なぜもやもやするのか」「どう直せば良いのか」という指針を与えてくれます。たまに「これ、動き変わっているし、リファクタリングじゃないよね?」というツッコミを入れたくなるのも、この本のおかげです。

エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

DDD!書かれていることは「当たり前だよね」「そりゃそうだよね。そうあるべきだよね」と思うのだけど、いざ実践しようとすると手続型きっぽくなってしまったり、ドメインの知識が境界やレイヤーを超えて漏れだしたりと難しいです。
設計する時にはよく(脳内含めて)参照しています。この書籍の内容がチームメンバーの共通認識になると、変化に対してより適応的なコードベースを育めそうです。 これを読むと「RailsActiveRecordパターンって、良いんだけど、永続化の役割を持ったクラスがapp/modelの下にあるのってもやもやするよね…」という感想を持ったりして、開発チーム内で議論が起こりました。

DDDをもっと具体的に学ぶには「実践ドメイン駆動設計」もどうぞ。

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計 (Object Oriented Selection)

アジャイル

エクストリームプログラミング

エクストリームプログラミング

エクストリームプログラミング

XPについては開発チームは副読本としてFury Roadを観て学んでいます 角さんの資料も合わせてどうぞ。 www.slideshare.net

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技

デメテルの法則 (Law of Demeter) などの SOLID原則 や幾つかのデザインパターンC++での実装例から学ぶできる本です。

アジャイルソフトウェア開発の奥義、という割には設計や実装寄りなんですねー」という感想に対し、Misoca技術フェローの角谷さん曰く、

ソフトウェアをちゃんとつくれないとアジャイルには開発できないので圧倒的に正しい

とのこと。

最後に

今回の記事を書く過程で「これもオススメ」「あ、自分これ読んでないや」という会話ができたので、チームメンバー、および、自分自身についての知識レベルについて改めて考える良い経験になりました。 「この本もオススメだよ!」などありましたらぜひはてブなどでコメントください!