弥生開発者ブログ弥生開発者ブログ2015-10-30Misoca開発で日々使う知識とその情報ソースまとめ9月末に涸沢の紅葉を堪能してきた@RKTMです。Requestでのレビュー指摘から。あ、このメソッド内のlambda式でdocumentという名前を使っているので、区別するために@documentのままにしておきます」レビューア「えっ。変数のスコープは必要ない限り狭くすべきだよ。「sprintとは?」といった、知識のばらつきが顕著になってきました。その対策として、Misocaの開発で基本的に使う知識Misocaの開発をうまくやるための知識を明文化することで、Misoca開発チームの共通知識の明確化メンバーの不足している知識の習得を図ることがこの記事の狙いです。いった方にMisoca開発チームはどういった知識を使って仕事しているのか、ということを知っていただければと思います。毎日のように必要となる知識です。このあたりを押さえられれば、駆け出しMisoca開発者です。RailsMisocaはRailsで作られています。これをひと通りやっておくと基礎としては問題ないでしょう。JavaScript/CoffeeScript/ES6RailsなのでCoffeeScriptで書くのですが、その前提としてのJavaScriptの知識が必要です。JavaScriptを全然しらない人は、このあたりはざっと眺めておきましょう。CoffeeScriptついてはここをざっと眺めると理解できます。Haml/SCSShaml.info昔はERBを書いていましたが、「閉じタグを書くには人生はあまりに短い」ということでHamlへ移行しました。HAMLを使うと良いです。SCSS使っています。凝ったデザインはデザイナーにお願いしますが、最低限のUIは開発者が実装できる必要があります。marginだとかfloatだとかは理解しておきたいです。RDBMSMySQL/PostgreSQL使ってます。文書はRDBではなくNoSQLがマッチするよなぁ、という話はしていますが、まだしばらくはRDBMSベースです。シンプルなCRUDを書けて、Railsの裏側で発行されるSQLを想像できて、あとはトランザクションを張るべきケースが理解できていればOKです。忙しいあなたのためのSQL入門---目次:ITprorspecbetterspecs.org自動化されたテストコードを書いています。ここに記載されている内容はJOINして日が浅いとよく指摘されます。アジャイルプロセスKanbanスタイルにScrumのフレームワークを取り入れて試行錯誤を続けています。開発チームの文化として、週次のリズムがしっくりくるため、開発プロセスのイベントサイクルは1週間で運用しています。見るさくさく読める平易な文章でありながら、実践的なことが書いてあります。Misocaでの日々の開発における意思決定には、この本で書かれていることが活きています。PDF先日、技術フェローである角谷さんにオフィスに訪問していただく機会があり、スクラムガイドをもとにスクラムの基本について話してもらいました。スクラムガイドと照らしあわせて「Misocaは今どうなのか」という説明をして頂いたのは他では得難い経験でした!Git/GitHubGitとGitHubは毎日使います。clone/pull/commit/push/resetぐらいできれば良いと思います。rebaseはそのうち学んでいきましょう。BookMisocaの開発をうまくやるための知識ここまでは日々使うような基本的な知識でした。継続的なサービスの発展と提供にはよりよい設計・実装が必要です。そんな設計・実装を行うために必要な知識をピックアップしました。見る自分が書いたコードはチームメンバーにレビューしてもらいます。読みづらいコードは、レビューしづらく、その後の変更もしづらいものです。このあたりをひと通り読めばだいぶ詳しくなれます。困ったらここを読みましょう。基本を学ぶことができる本です。元はモジュール化で設計の整理がされたRails3をベースに、Railsそのものを拡張するにはどうするか、という本で、そのRails4版。speakerとして登壇しました。見るリファクタリングといえばこれ。コードのもやもやしているところが「なぜもやもやするのか」「どう直せば良いのか」という指針を与えてくれます。「これ、動き変わっているし、リファクタリングじゃないよね?」というツッコミを入れたくなるのも、この本のおかげです。見るDDD!書かれていることは「当たり前だよね」「そりゃそうだよね。あるべきだよね」と思うのだけど、いざ実践しようとすると手続型きっぽくなってしまったり、ドメインの知識が境界やレイヤーを超えて漏れだしたりと難しいです。設計する時にはよく(脳内含めて)参照しています。この書籍の内容がチームメンバーの共通認識になると、変化に対してより適応的なコードベースを育めそうです。これを読むと「RailsのActiveRecordパターンって、良いんだけど、永続化の役割を持ったクラスがapp/modelの下にあるのってもやもやするよね...」という感想を持ったりして、開発チーム内で議論が起こりました。DDDをもっと具体的に学ぶには「実践ドメイン駆動設計」もどうぞ。見る角さんの資料も合わせてどうぞ。幾つかのデザインパターンをC++での実装例から学ぶできる本です。「アジャイルソフトウェア開発の奥義、という割には設計や実装寄りなんですねー」という感想に対し、Misoca技術フェローの角谷さん曰く、ソフトウェアをちゃんとつくれないとアジャイルには開発できないので圧倒的に正しいとのこと。最後に今回の記事を書く過程で「これもオススメ」「あ、自分これ読んでないや」という会話ができたので、チームメンバー、および、自分自身についての知識レベルについて改めて考える良い経験になりました。