先日、herokuさんからこんなメールを頂きました。 要約すると、「DBが無料枠超えそうだからどうにかしてね」と。 以前このブログで公開させて頂き、それなりの反響を頂いたProgrammer Profile。その後更新があまりできていないにもかかわらず、アクセス頂きホント嬉しい限りです（リニューアル作業中ですが、デザイン面で色々難航しており…） www.programmerprofile.net せっかくアクセス頂いているのに、DB容量制限でエラーとなるのもしょんぼりなので、現在の無料プランから月額9$の有料プランに変更しました（広告入れてる訳ではないので、ちょっと辛いですが・・・） で、実際にネットの情報を元に作業してみると、上手くいかない点があったり、良く分からない点があったので、今後同様のアップグレードをする人の助けになったらいいなと思い、作業ログをまとめてみました。 DBの追加 ま

技術的負債についての自分の考えをまとめます。 言いたいこと 最初から綺麗なコード・設計を書ける状態を目指せ。 そうもいかないものは天秤だが、勝手に背負うな。 技術的負債とは？ 技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。 負債の種類と対応は、以下の三つに別けられると自分は考えています。 1. 新規で書く末端機能のクソコード・クソ設計 最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか？」とコメントでも添えて、さっさとプルリを投げてしまうべきです。 末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。

よくある「開発スピードを優先させるか技術的負債をなるべく発生させないようにするか」という議論、ケースバイケースだとは思うけど、ことプロダクトの立ち上げ段階では、悩んだら「開発スピード」を優先させるようにするべきだと自分は思ってる。 理由は 市場は待ってくれないから。どんなにいいプロダクトでもユーザーに使われなくては意味がないのと、プロダクトを取り巻く外部の環境(競合プロダクトや市場でのニーズ)は自分ではコントロールできないものなのに対して、技術的負債については適切に管理されていればコントロールしながら返済できるから。もちろんバランスも重要だとは思うので、どんな技術的負債も生み出していいかと言われるとそうではないけど。 というわけで自分は「ああこれクソコードだけど機能は満たしてるからそのままリリースしたいなぁ」というのはだいたいクソコードのままリリースしています。(こうやって免罪符を作ってい