技術的負債の一括払い、分割払い

技術的負債について

ja.wikipedia.org

技術的負債は基本的には避けるべきものだが、スタートアップにおけるプロダクト開発では往々にしてスピードが求められるために、負債を負うことを甘受したほうがよい、と判断される場面がある。プロダクトが大きくなっていくといずれ対応しないといけないが、そもそもその段階までプロダクトが育つかどうかよく分からない、むしろ他の高優先度の機能開発を優先しないと死ぬ、みたいなケースを想定している。

自分の経験から具体例を挙げると、例えば一覧画面におけるページングは後回しにされることが多い。初期段階では全件取得するようにしておいて、プロダクトが順調に成長して一覧ページが重くなってきたら実装する、といった感じ。

一括払い

前述した、「必要になったらその機能を追加する」という考え方は一括払いと言えそう。最初に負った負債を一気に返す。一気に返さないといけないので、その分かかる労力が大きい。

ページングの例で言うと、ページング基盤のような設計・実装が必要になり、その基盤を使う対応をバックエンド・フロントエンドの両方に入れる必要がある、といった感じ。

一括払いの課題は、労力がかかってしまう(≒工数がかかる) ために後回しにされがちな点だと思っている。

分割払い

では分割払いとは何か。これは、最初から将来のことを想定した設計・実装にしておくというアイデアかと考えている。

ページングの例で言うと、ページング機能自体は実装しないが将来的にページングが可能な設計にあらかじめしておくという感じ。設計を最初に考える必要があり、かつ一覧画面を作るときは都度その設計に沿う必要がある。一括払いよりも前の時点から少しづつ負債を返していくというイメージ。

分割払いの課題は、負債を少しずつ返す分、一括払いのような一時的なスピードが得られない点だと言えそう。

まとめ

どちらかの方法が優れている！ということが言いたかったわけではなく、単に今までの経験で感じたことを文章にまとめたかったので書いてみた。

これまでの経験では一括払いを選ぶケースが多かったけど、ケースに応じて分割払い選択をするのもありなんじゃないかと思っている。

ScalaMatsuri2014 1日目

ScalaMatsuri2014に参加してきた。運営スタッフやスポンサーの方々に感謝。

いま書ける範囲で感想を書く。

概要

大きなフロアをRoom A/Bに分けた上で、一部の時間帯を除いて各部屋で別のセッションをやるという感じだった。

これにより、同時間帯でより人気のあるセッションに民族大移動が発生するという感じで、スピーカーの方にはややプレッシャーがかかるのでは、と思った。

以下、印象に残ったセッションについて。

基調講演 - Scala 進化論

ScalaのauthorであるMartin Oderskyさんによるセッション。

私はScala歴1年経つかどうか、という程度の経験しかないのでScalaの過去の経緯など全く知らず、初めて聞く話が多かった。

特に印象に残った点は以下。

  • 割とScala.js推してたような感がある。
    • 個人的にあまりウォッチしていなかったので触った方がよさそう。
  • 不変なポリシーとして、Scala自体には多くの機能を入れず、ライブラリのために適切に抽象化する。
    • しかし各ライブラリでDSLが存在するのは諸刃の剣でもあり、巨大なプロダクションで利用する場合は規律や協調が必要。
  • null-safetyな機能を入れようとしたが、みんな自然とOptionを使い始めたので入れなかった。
    • NotNullなんていうマーカーtraitがあったらしい。

いきなり30分オーバーになってしまって、質問タイムを設ける余裕がないのが残念だった。質問タイムがあれば、例のコンパイラのforkの件について誰かしら突っ込んだのでは…。

sbt、傾向と対策(会場では聞けなかったのでニコ生で見てから追記）

  • いきなりマルチプロジェクトに対応した形で書くのがおすすめ。トップのbuild.sbtに以下の様に書く。
lazy val root = (project in file(".").settings( ... ))
  • testOnlyで指定したテストのみ実行。
  • ~testQuick でソースコードを監視し、変更があったら自動でテストを走らせる。
  • セッティングは内部ではkey-valueaマップの形になっている。 書き方は以下のようなイメージ。昔はいろいろな書き方があったが、今はこの3つでだいたいOK。
key := {
  val x = otherKey.value
  x + 1
}

key += { ... }

key ++= Seq(...)
  • キーはコンソールに打ち込むためのエントリーポイントのようなもの。
  • キーの委譲の仕組みがある。委譲の優先順位は ivyConfigurations で確認可能。
  • コンフィギュレーションとはソースとライブラリ依存性の集合。
  • compile と打ち込めばインクリメンタルコンパイルされる。
  • 1.0 化の前に入れたい機能がいくつかあるのでそれが終わってから。個人的には、sbt server(IDEやJenkinsなどとの統合ができるようになる) が気になった。

GitBucket: Perfect Github clone by Scala

GitHubのクローンであるところのGitBucketのauthorである竹添さんによるセッション。

もう片方の部屋ではsbtのセッションが始まるという圧倒的アウェー感の中始まった。

個人的に印象に残ったのは以下。

  • Apache MINA をSSH対応のために利用している。
    • MINAって個人的にはミナって読んでたけどマイナの方が正しいのだろうか。
  • Scalaでプラグインを書くことができる(実際に、gistをプラグインで提供している)。
    • 「Scala触ったことない人が、GitBucketのプラグイン作成をきっかけにしてScalaを書くようになってもらえれば...」

GitHubやBitbucketなどを使えない人が実際に存在するわけで、そういう人に向けた現実的なソリューションとしてすごくいいものだと思った。

Solid and Sustainable Development in Scala

ScalikeJDBCやSkinnyFrameworkのauthorである瀬良さんによるセッション。

  • "Trait Chaos. We should have self-discipline." とか、"Do you really need cake pattern ? "など、全体的に心当たりがありすぎて耳の痛い話だった。
  • 理想論だけでなく、現実の問題を解決すべきという姿勢には強く共感できるので、仕事で使えるチャンスがあれば使っていきたい(できればcontributionも...)。

全編英語のセッションで翻訳なしだったけど、ネイティブスピーカーの英語は聞き取れない私でもだいたい聞き取れたので特に問題なかった。

はてなにおけるScala活用事例

Mackerelの開発チームの方によるセッション。

  • AngularJSを使っていて、更にPlayのテンプレートエンジンにTwirlを使っている。
    • エンジニアでも分からなくなることがあるのに、はてなのデザイナーはうまくやっているとのこと...
  • 他セッションでは割とディスられがちだったSlickを使っている。
    • コードによっては解読不可能なクエリが生成されて厳しいことになる。
    • 生成されたクエリを見た感じでは、あまり触りたくないなぁと...

追記予定 ?

他のセッションの話も書きたいけどまだスライド公開されてなかったりするし最高に眠いので、また明日以降追記するかもしれない。

2日目予定

1日目はほぼ講演を聞くだけだったが、2日目はアンカンファレンスという、"従来のような講演形式とは違う「参加者が創っていく」カンファレンス" が行われるらしい(公式サイトより抜粋)。

会場の隅で、アンカンファレンス用のネタがホワイトボードに貼付けられていたのでざっと見た感じ 以下あたりが気になった。

2日目も朝早いのでさっさと寝て備える。