開発体験向上について考えてること

Table of Contents

会社での仕事の大半はDX向上な気がしているので、普段やっていることについてまとめていく。

DX: Developer Experience （開発体験）は重要だ にDX向上のメリットについて書いてあるのだが、具体的な作業は何かについて書いていないので自分なりのやり方を書いていく。

最近ずっとRailsばっかだったので、Railsプロジェクトをイメージして書く。

  • 環境構築をなるべくDockerできるようにする
  • 再現性の高い環境構築手順を作成する
  • Editorconfigを入れる
  • インフラ構成を整理する
  • 安全にDeployできるようなしくみを作る
  • CircleCIなどCIサービスを入れる
  • GitFlowを入れる
  • 明らかに使っていないファイルを削除する
  • 使用している外部サービスを洗い出しておく
  • ソースコードに埋め込まれている鍵をenvに移す
  • Sentry などエラーを検知できるしくみを導入する
  • Linterを入れて変更を少なく定期的に修正していく
  • RSpecのようなテストツールを入れる
  • dependabot を入れる
  • pull pandaを入れる
  • 静的解析ツール（Phanなど）を入れる
  • NewRelicなどの監視ツールを入れる
  • 事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く
  • 時間を見つけてロジックが複雑な部分をリファクタリングをしていく
  • errorやdeployやcommit通知をslackに流す
  • git-pr-releaseを入れる

安全にDeployできるような仕組みを作る

AWS ECSのようにコンテナマネージドサービスの場合はCircleCIからたたけばよいだろうし、そうでなければとりあえずdeploy用のサーバを立てcapisoranoでdeployしちゃっても良いだろう。

大事なのはlocalに依存しないことと再現性のあること。

使用してる外部サービスを洗い出しておく

意外とこういう洗い出し大事。使っていないコードの削除も捗るし、抽象化もしやすい。

事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く

技術的負債の説明をできるのはエンジニアしかいないので、本当に対応するべきか置いといて、きちんと伝えることは大事。

エラー通知やdeploy通知をslackに流す

DX向上はエンジニア以外わからないので、「きちんと作業している」ということを伝えるのは大事。

DX向上はエンジニアのための作業だけど、ちゃんとエンジニア以外にも「伝える」こともエンジニアとして大事なんだろうなぁ。