2. 自己紹介 •アプリケーションエンジニア •基盤サービス、AWS 管理、コードレビュー •JSON API サーバ on the JVM、Rails 沢山 •Scala OSS メンテナ:Scalatra, json4s, Scalate, Skinny Framework, ScalikeJDBC
![マイクロサービス運用の所感 #m3dev](https://cdn-ak-scissors.b.st-hatena.com/image/square/7f4e84ca3b2e2694def50423ad3001db6b3bc210/height=288;version=1;width=512/https%3A%2F%2Fcdn.slidesharecdn.com%2Fss_thumbnails%2Fbvq17nbvsdydzr50uqwe-signature-ce8fa9161604a3b8b91cbe893c9fb2437a17c46cb87bd92c8aebb1ce477c9826-poli-150523000113-lva1-app6891-thumbnail.jpg%3Fwidth%3D640%26height%3D640%26fit%3Dbounds)
技術的負債についての自分の考えをまとめます。 言いたいこと 最初から綺麗なコード・設計を書ける状態を目指せ。 そうもいかないものは天秤だが、勝手に背負うな。 技術的負債とは? 技術的負債は事業リスクです。放置することによって事業が失速したり損害が発生したりするため、適切に取り扱う必要があります。 負債の種類と対応は、以下の三つに別けられると自分は考えています。 1. 新規で書く末端機能のクソコード・クソ設計 最初から綺麗なコード・設計を書けるを目指すべきですが、時間がかかるのであればスピード重視でよいでしょう。 「もっと良いように書けるべきだけど、どうすればよいか?」とコメントでも添えて、さっさとプルリを投げてしまうべきです。 末端機能で、あとで上に乗っかる物がないのであればコードの品質はそれほど問題ではありません。テストを整備しておけば、後でレベルが上がったときに綺麗にできるでしょう。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く