【Devin仕事日記①】componentsのコーディングルールを修正する

序文

こんにちは株式会社Another works取締役CTOの塩原です。
弊社ではDevinを導入し、現在開発に活用しています。

Devinを使いこなすのは難しいと言われている中で、ノウハウを共有することでDevinの発展に貢献できればと思い記事を書いています。

どんな仕事をお願いしたのか？

コンポーネントファイル構成ルールの変更

1. 背景・目的

• 従来構成では index.tsx（エントリポイント）と presenter.tsx（見た目専用ファイル）に分割していましたが、
  • ファイル数が増えて管理コストが上がる
  • ビジネスロジックと分断し過ぎてコードを追いにくいケースがある
• 変更後は表示部分を index.tsx に統一し、可読性と保守性を向上させます。

2. 具体的ファイル構成

// Before
components/ComponentName/
├─ index.tsx      // エントリーポイント
├─ presenter.tsx  // 見た目（DOM・スタイル）
└─ hooks.ts       // ロジック・ステート管理

// After
components/ComponentName/
├─ index.tsx      // エントリーポイント ＋ 見た目（DOM・スタイル）
└─ hooks.ts       // ロジック・ステート管理

index.tsx の構成イメージ

import React from 'react';
import useComponentLogic from './hooks';

type Props = {
  /** 必要な Props を明記 */
};

const ComponentName: React.FC<Props> = ({ /* props */ }) => {
  const { state, handlers } = useComponentLogic(/* props */);

  return (
    <div className="component-name">
      {/* DOM・見た目ロジック */}
      <h1>{state.title}</h1>
      <button onClick={handlers.onClick}>クリック</button>
    </div>
  );
};

export default ComponentName;

---

3. 移行手順

1. 既存コンポーネント
   • presenter.tsx の中身を index.tsx にマージ
   • import パスを修正（./presenter → 省略）
   • presenter.tsx を削除
2. ビルド・デプロイ
   • 全社共通の CI/CD で問題がないか検証

Devinへの依頼方法(Playbook公開)

## Overview
presenter.tsxファイルを削除するために、このファイルをimportしているindex.tsxファイルにコードを統合します
PullRequestを1件作成してレビュー依頼を完了することがゴールです

## Procedure
1.  presenter.tsxファイルを発見します
2. このpresenter.tsxファイルをimportしているindex.tsxファイルを発見します
3. presenter.tsxのコードの中身を変更せずにindex.tsxファイルに転記します
4. presenter.tsxファイルを削除します
5. PullRequestをドラフトで作成します
6. こちらのコマンドを実行し、実行した結果をPullRequestのDescriptionに記載します`git diff origin/master:*/presenter.tsx HEAD:*/index.tsx`
7. 作成したPullRequestのコードレビューをコードレビュー観点に則って行ってください。修正も行ってください

## Advice & Pointers
- index.tsxに転記したときに参照されなくなるコードがあるのでその場合は削除してください
- PullRequestの作成ルールなどはナレッジを参照してください
- コードの書き方はSampleを参考にしてください
- 新しいコミットが作成されたら`git diff origin/master:*/presenter.tsx HEAD:*/index.tsx`を実行して、PRのDescriptionを書き換えてください
- presenter.tsxのコードの行数が少ないものを優先してください

## Sample

\```
// presenter.tsx
export function Presenter() {
  return <div></div>
}
\```

ダメな例: presenter.tsxで定義されているコンポーネントをそのまま持ってきて貼り付ける
\```
// index.tsx

function Presenter() {
  return <div></div>
}

export function Index() {
  return <Presenter />
}
\```

良い例: index.tsxで定義されていたコンポーネントにコードを統合する

\```
// index.tsx
export function Index() {
  return <div></div>
}
\```

## PullRequest Template
\```
# Why
presenter.tsxファイルを削除するために、このファイルをimportしているindex.tsxファイルにコードを統合します。これにより、コンポーネントの構造がシンプルになり、メンテナンス性が向上します。

# What
以下のpresenter.tsxファイルの内容をindex.tsxに統合し、presenter.tsxファイルを削除しました：

- {変更したファイルパス}

## Masterのpresenter.tsxとHEADのindex.tsxの差分

git diff origin/master:{削除したpresenter.tsxのパス} HEAD:{変更したindex.tsxのパス}
{コマンドの出力結果}
\```

## Forbidden actions
- presenter.tsxとindex.tsxファイル以外を変更すること
- presenter.tsxをindex.tsxに転記する際にコードを変更すること
- 1ファイル以上のpresenter.tsxを変更すること
- PullRequestを1つ以上作成すること

## コードレビュー観点
- ダメな例: presenter.tsxで定義されているコンポーネントをそのまま持ってきて貼り付けるを行っていないかどうか
- コードコメントを勝手に削除していないかどうか

工夫ポイント

1. 小さなタスクから着手する「行数が少ないものを優先」

• 狙い：
  小規模な presenter.tsx から手を付けて、早期に完了感（モメンタム）を得られる。
• 効果：
  モチベーション維持と、作業手順の反復による習熟を同時に実現。

2. 差分確認コマンドの明示 (git diff origin/master:*/presenter.tsx HEAD:*/index.tsx)

• 狙い：
  どのファイルを統合・削除したかを自動的かつ明確に PR 説明に反映。
• 効果：
  レビュアーが差分探しに時間を取られず、変更点に即アクセスできる。

3. “Forbidden actions” セクションでスコープを明確化

• 狙い：
  余計なファイル変更や複数 PR を防ぎ、作業範囲のブレを抑制。
• 効果：
  レビュー効率アップ＆ミスコミュニケーション削減。

4. “Bad／Good Example” による具体的ガイド

• 狙い：
  単純転記ミス（Bad）と正しい統合方法（Good）を対比で示し、誤解を未然防止。
• 効果：
  コーディングルールの落とし穴が視覚的に理解できる。

5. 自己レビューと差分更新のループ設計

• 狙い：
  PR を出した後も、自ら git diff → Description 更新 → 再レビュー… を繰り返す工程を組み込む。
• 効果：
  「出しっぱなし」にせず、常に最新差分をレビューに反映する習慣がつく。