スピード感のために品質を落とすということはチームの成長を諦めるということ
サービスを開発していると、スピードが重視される。 そのこと自体にはまったく問題はなくて正当なことだと思っている。 ユーザーに対して一刻も早く価値を届けるためには必要なことだ。
そもそも、自分がいる Web 界隈ではこの点について異論のあるサービス開発者はあまりいないんじゃないかと思っている。
ただ、それを達成するための方法になると途端に意見が分かれはじめて、人によって重視することが全然違ってくる。
ある人は「スピード感が大事」と言い、ある人は「ちゃんと作ったほうがトータルでは速い」と主張する。
しかし、こういうときに意識される品質と速度についてのトレードオフは、実際には完全なトレードオフではないと思っている。
技術力のある人はある程度急いで作ったとしても一定以上の品質のコードを書くし、意図的に品質を落としたとしても速度はあまり上がらない。 逆に、技術力が高くない人が時間をかけて作ったとしてもその人の技術力以上の品質のコードは書けない。
では、品質と速度についてのトレードオフが意識されるとき、実際には何と何が秤にかけられているのか。
それは各個人ではなくプロダクト全体の品質と速度が秤にかけられているのではないか。 言い換えれば、プロダクトの品質を支えるために必要なメンバーの成長とその成長のために必要なフィードバックや学習の時間が秤にかけられているのではないかと思う。
先述の通り、個々人の速度は品質を上下させたところで大きくは変えられない。 しかし、レビューの工数を削減したり受けたフィードバックを反映する時間を削ったりすれば、PR をマージするまでの時間は大きく短縮できる。そして、結果として短期的な開発速度は向上する。
一方でレビューやフィードバックの時間やそれらを実際に適用してみるために考えて手を動かす時間を削ると、メンバー同士がお互いを高めあっていくことができなくなる。 すると、プロダクト全体の品質はいつまでたっても上がらず、チームも成長しないままになる。
現実世界はつらくきびしいので、チームの成長のために無限に時間を使うことはできない。しかし、価値を素早く届けるためには、それを可能にするチームを作っていくことも間違いなく必要なのではないか。 そんなお話。
2016年振り返り
Twitter を見ていたら、いろんな人が今年のまとめを書いていたので僕も書いてみます。
実家に帰る近鉄特急の中で書いています。完全にチラ裏な感じです。
Timeline
卒論
多くの人に心配&迷惑をかけていた僕ですが、とうとう大学を卒業しました。
卒論のタイトルは『ビルドアップ法によるフェロセン微粒子の作製と消火性能評価』でした。
フェロセンというのは五員環と鉄イオンでできたハンバーガーで、それ自体は可燃性があるのに適切な濃度で水に分散させてやると負触媒として働いて消火に寄与s(ry
卒業 & 卒業旅行
(卒業に必要な最低単位数 + 1) 単位で無事卒業できることになったので、卒業旅行と称して旅行に行ってきました。一緒に行く人がいないので一人旅です。
海外に一人で行ったことがなかったので練習の意味も兼ねて台湾へ2日間、その後、一番行きたかったイタリアへ11日間くらい。生まれてはじめてヨーロッパに行ったわけですが、ヨーロッパは遠いですね。逆に言えば、日本はヨーロッパから遠いわけで自分が極東の島国の人間なんだなーと思ったりもしました。あと中国人めっちゃいる。
インターネットで航空券を取って、宿泊先は Airbnb で確保して、現地では Google でいろいろ調べられる。便利な世の中です。インターネット最高。
あと、帰りのトランジット待ちでドバイにも寄ってきました。オイルマネーすごい。ガシャを回して運営に貢献して欲しい。
就職
シャカイジンになりました。
入社1年前(内定をもらったタイミング)から今の会社でバイトしていたので、そういう意味では新生活感は薄かったです。 やっていることも大きくは変わらないんですが、自分の中での変化としてはコミット感とかオーナーシップみたいなものが大きくなった気がしています。
あと、就職にともなって横浜から目黒に引っ越したんですが、目黒めっちゃ便利ですね。山手線最高。徒歩通勤最高。
シンデレラ 4th(全日程 LV 😭)
最高だった。
感想とか
少しだけ真面目なことも書いておくと、なんか無難に過ごしてしまったなーというのが一番大きい。 特に大きい失敗はしていないし一定の成果はあげているけど、目立った成功もないという感じ。
失敗をしていないというのは挑戦をしていないということと高確率で同義なので、もっと挑戦しないといけない。
今年一年、半分冗談半分本気で「新卒特権主張しますっ!」とか言って失敗や無知のエクスキューズをしていたけど、それでもなお挑戦できていないのは問題。
僕は失敗することも質問することも万人に許されていると信じているので、3ヶ月後に「新卒」の肩書を失うとしても、そんなことは気にせずに挑戦しないといけない。
失敗を避け続けた先にあるのは、きっと穏やかな死。
今年1年間ありがとうございました。
gemをあまり使わずにFat Modelを整理するための本「Growing Rails Applications in Practice」
タイトルの通りで、 Growing Rails Applications in Practiceを読みました。
Fat controllerやFat modelに代表されるように、少し気を抜くとカオスになりがちなRailsアプリケーションの整理方法についての本です。
表紙とか目次も含めてPDFで88ページしかなくて比較的読みやすかったです。*1
全体的な構成
章立ては次のようになっています。
- Introduction
- Beautiful controllers
- Relearning ActiveRecord
- User interactions without a database
- Dealing with fat models
- A home for interaction-specific code
- Extracting service objects
- Organizing large codebases with namespaces
- Taming stylesheets
- On following fashions
- Surviving the upgrade pace of Rails
- Owning your stack
- The value of tests
- Closing thoughts
このうち、2章から4章が「New rules for Rails」、5章から9章が「Creating a system for growth」、10章から14章が「Building applications to last」という節に含められています。
各章について
各章の内容について簡単に触れてみます。
1. Introduction
基本的に https://leanpub.com/growing-rails に書かれている「About the Book」の内容です。 ここでDCI、CQRS、SOAなどに一瞬触れられていますが、その後の本文中で対比されることはありませんでした。
2. Beautiful controllers
はじめに「Controllerでいろんなことをせずに他のオブジェクトに適切に委譲しよう、Skinny controllerだ!」みたいなことを言った上で、そのための新しいルールを紹介してサンプルコードが提示されるんですが、そのサンプルコードが独特で面食らいます。 このときはちょっとした違和感を覚えるくらいでしたが、この独特なコードが第4章で思わぬ形で再登場します。
3. Relearning ActiveRecord
ActiveRecord継承モデルが仕事をしすぎている話が語られます。
ARモデルはupdate_attributes
やhoge=
のようなメソッドでいろいろなところからattributeを変更されうるので、attributeや他のモデルとの関係の整合性が損なわれる可能性に触れて、validationとcallbackを使って整合性を保つ方法が紹介されます。
4. User interactions without a database
ログイン画面を例にとって、ActiveTypeを使ったフォームが紹介されます。
validationをフォームに切り出すというのはオーソドックスで良いと思うのですが、入力されたメールアドレスとパスワードが正しいかどうかを検証するために@sign_in.save
するというインターフェイスになっていて、saveとはなんだったのかみたいな気持ちになりました。
あと、本筋とは関係ないですがログイン失敗時に「User not found」とか「Incorrect password」といったエラーを返していてセキュリティ的に厳しい気持ちにもなりました。
5. Dealing with fat models
Fat modelが生まれる理由について語られます。
いろいろなコンテキストにおいてUser
クラスに求められる責務が例示され、その責務を分割していくという方針が語られます。
例として挙がっているUser
クラスの責務が具体的で「なるほど。たしかにこれはFatにならざるを得ない……」みたいな気持ちになれるのでオススメです。
6. A home for interaction-specific code
ARモデルが持つべき責務を
- データ整合性担保のためのvalidation
- associationの管理
- レコードを探したり操作するための汎用的なメソッド
のみであるとし、それ以外のユーザーとやりとりするためのロジックをform modelに抽出しなければならないとのこと。
そのためのモデルとして、User
を継承してUser::AsSignUp
を作るという考えが紹介され、そのままだとクラス名が変わったことによりform_for
などが動かなくなるため、User
ではなくActiveType[User]
を継承する方法なども紹介されます。
これは便利そうな気がすると同時に、どこが引っかかっているのかはわかりませんが、ちょっとびみょい感じもしています。
7. Extracting service objects
controllerにベタで書いているロジックをservice objectに切り出そうという話がされます。テストしやすくなる点などにも触れられている。
「ロジックを別の場所に移しただけだよね?「うんそうだよ」的なことが書かれていて良い。
8. Organizing large codebases with namespaces
Invoice
の子リソースであるItem
をInvoice::Item
にするといった感じで、app/models/
直下を整理する試みが実例とともに語られます。
昔、自分でやってみていろいろハマった記憶があるんですが、ちゃんとやればうまくできるものなんだろうか……というのが正直な感想。 (試してみたのがかなり前なので僕がRailsをよくわかってなかっただけという説もある)
9. Taming stylesheets
アプリケーションコードだけではなく(もっとカオスになりがちな)CSSを整理する方法についても触れています。
といっても、基本的にはBEMを紹介しているだけなので、ここは飛ばしてWebを漁っても良さそう。
10. On following fashions
流行っているgemを採用するかどうかの基準について。
導入に際して書き換えるコードが多いgemは捨てるときにもコストがいるし、銀の弾丸はないんだから簡単に飛びつかないように注意が必要とのこと。
また、イケてるgemは裏でごにょごにょやってたりしてつらみを生むこともあるし、開発者が飽きてメンテされなくなることも多いから気をつけないといけないといったことも語られている。
11. Surviving the upgrade pace of Rails
Railsのバージョンを上げていくときに、gemが意外と足を引っ張るから注意してねといった話。
12. Owning your stack
gemを採用するならちゃんと責任をもってやれよといった内容。
言っていることは至極真っ当だとは思うんですが、前の2章と合わせて若干くどいというか目の敵にしすぎな感じが否めません。
13. The value of tests
UnitテストとIntegrationテストを書こうという話。
コードベースを改善していく上でテストがあるメリットは計り知れないので重要な話ではあるが、この本に必要かと問われると微妙なところ。*2
14. Closing thoughts
「thought」と書いてあるから著者の深淵なる考えでも書かれているのかと思いきや、連絡先の記載や拡散の依頼など事務連絡的なことが書かれている1ページ未満の章。
さいごに
サクッと読めて、問題点の整理ができるという点は非常に良い本だった。
一方、問題に対する解決策については良いと思う点があった一方で、首をかしげるところも多かったのでそのまま使うかどうかは検討する必要がありそう。