- この記事は助言ではなく、著者が現在実践している開発習慣について書いたもの
- 悪い習慣を避け、良い習慣を作るために努力してきた経験を整理した記事であり、生産性向上と品質維持に役立った10の習慣を扱う
1. 小さなコミットを保つ
- コミットはできる限り小さく保つべき。小さなコミットなら、バグ発生時に特定のコミットだけを巻き戻せるため、複雑なマージコンフリクトを避けられる
- 「ソフトウェアがコンパイルできるときにコミットできるべき」をルールにしている
2. 継続的なリファクタリング
- Kent Beck の助言: 「変化を望むなら、まず変化を簡単にし、それから簡単に変化できるようにしなさい。」
- 少なくとも半分のコミットにはリファクタリングを含めるようにしている。小さなリファクタリングは、大きな要求が入ったときに大いに役立つ
- 大規模なリファクタリングは避けるべき。代わりに10分以内の小さな改善作業を継続的に行う
3. コードをデプロイすることの重要性
- コード自体は潜在的な負債であり、デプロイされていないコードは最大の負債である
- テストは安心感を与えるが、実際のデプロイは本当の承認を意味する
- デプロイ頻度が高まるほどホスティングコストが増えることはあり得るが、最新の作業が実際に動くと確認できることは重要な利点である
4. フレームワークの機能をテストしない
- フレームワークの機能はテストしない。フレームワークはすでに十分に検証されている
- コンポーネントを小さく保てば、フレームワークが大半の作業を処理するようになり、テストは減る
- 大きなコンポーネントは複雑さを増し、それに伴って多くのテストが必要になる
5. 新しいモジュールを作る
- 特定の機能が既存のモジュールに合わないなら、新しいモジュールを作るのがよい
- 既存モジュールに無理やり機能を追加するより、独立したモジュールとして残しておくほうがよい
6. テスト駆動開発（TDD）の柔軟な適用
- API 設計が明確でない場合は、先にテストを書いて「顧客」の立場から考える
- TDD を宗教的な原則として従うことはしない。必要であれば、より大きな単位で作業した後にテストしてもよい
- 小さな単位のコードを失敗状態にしなくてもよく、生産性を損なう教条主義に縛られない
7. コピペは1回だけ許す
- 1回のコピーは問題ないが、2回目のコピーからは重複が生まれる
- この時点で適切な抽象化によって重複を取り除くべき。パラメータ化が少し不自然に見えても、複数の実装を統合するよりはよい
8. デザインの変化を受け入れる
- デザインは時間が経つにつれて古くなる。リファクタリングで老朽化を遅らせることはできるが、最終的には変わらざるを得ない
- 以前のデザインに執着しすぎず、変化を受け入れるべき
- 完璧なデザインは存在せず、変化にうまく対処する能力こそがソフトウェア開発の核心である
9. 技術的負債の3つの種類
- 技術的負債は3つの種類に分類できる:
- 現在の作業を妨げるもの
- 将来の作業を妨げる可能性があるもの
- 妨げる可能性があるかもしれないもの
- 1つ目の種類の負債は最小化し、2つ目の種類に集中し、3つ目の種類は無視すべき
10. テスト容易性と良い設計の関係
- テストしにくいなら、設計に問題がある可能性が高い
- テスト設計もまた改善の対象になりうる。たとえば、
em.getRepository(User).findOneOrFail({id}) のモック作成が難しいと感じるなら、別の関数に分離したり、テストユーティリティを使ったりするのがよい
- テストが書かれない理由は、テストしにくいからであり、それは設計の問題かもしれない
9件のコメント
DRYよりもSRPが達成されているべきで、そうしておくとAIに任せても的外れなことを言わなくなるんですよね
変化にどれだけ素早く適応できるコードと環境を作れているかが、最も重要だと思います。
そして、適切な抽象化を通じてコードの再利用性と拡張性を高め、AIツールを活用して開発速度を最大化できます。
本当に良い文章です。あちこちでおすすめしたいですね
変化を受け入れ、コピペは一度だけ、テストはより良く、コミットはより小さく...！
良い文章ですね
この記事はぜひ原文をご覧になるとよいと思います。
普段から気になるニュースは原文を見るほうですが、これは特にそうするとよいと思います。1番を見ると、原文は
Keep commits small enough that you wonder if you're taking this "keep commits small" thing a little too far. となっているのに、"コミットはできるだけ小さく保つべき" と要約されていますね..
本当に良い文章ですね。
7番は本当に良い内容ですね
Hacker Newsの意見
複数の実装を避けるために、パラメータを使うのがよい。パラメータを改善するほうが、複数の実装を統合するより容易である。
コードのコピーは1回なら問題ないが、2回目以降は重複を避けるべきである。十分なデータポイントがあるときに、よい抽象化を作るべきである。
DRY（繰り返すな）やWET（すべてを2回書け）は絶対的なルールではない。コードの重複と統合のタイミングを理解することが難しい問題である。
小さなコミットの代わりに、大きなコミットを巻き戻さずに、バグを修正する新しいコミットを追加できる。
テストしやすさはよい設計と関係している。簡単にテストできないものは、設計変更が必要だというサインかもしれない。
フレームワークの機能をテストするときは注意が必要である。フレームワークは時間とともに変わる可能性がある。
コミットサイズについては、特定の変更を巻き戻す必要が生じたときに備えて、簡単に元に戻せるコミットを目指すべきである。
企業は安定したコードベースを望むが、継続的なリファクタリングが必要である。これは安定性と相反する可能性がある。