ソフトウェア開発の良い習慣 |ザラールのブログ

2024 年 9 月 5 日

注: これは HNに投稿しました そして注目を集めました。

この投稿はアドバイスではなく、私にとって効果があるものです。

悪い習慣を身につけるのは簡単ですが、良い習慣を身につけるのは難しいです。自分にとって効果的だったことを書き留めることは、一生懸命に開発した良い習慣を維持するのに役立ちます。ここでは、私が現在開発している製品の速度を向上させ、相当なレベルの品質を維持するのに役立った 10 のことを順不同でリストします。

1. 「コミットを小さく保つ」ということを少しやりすぎているのではないかと思うほど、コミットを小さく保ちます。特定の変更をいつ元に戻さなければならないかわかりません。6 日前にバグを導入した場所がわかり、マージ競合という悲惨な状況を経験せずにそのコミットだけを元に戻せるという至福の感覚があります。私の経験則: ソフトウェアのコンパイルはコミット可能であるべきです。

2. ケント・ベックスのライブ 聖なる知恵の言葉: 「希望する変更ごとに、変更を簡単にします (警告: これは難しいかもしれません)。その後、簡単な変更を行います。」すべてのコミットの少なくとも半分をリファクタリングにすることを目指します。継続的なリファクタリングとは、何かを改善するために 10 分以内に加えられる変更を考えることです。これを行うと、より大きな要件が発生し、その小さな改善だけでそれを満たすために小さな変更を加えていることに気づくたびに効果が得られます。大規模なリファクタリングは悪い考えです。

3. すべてのコードには責任が伴います。デプロイされていないコードは負債の死神です。それが機能するかどうか、少なくとも何も壊れないかどうかを知る必要があります。テストは自信を与え、本番は承認を与えます。多くのデプロイを行うとホスティングのコストが少しかさむかもしれませんが、最後に行ったことは進歩の真の兆候であることがわかれば、支払う代償はわずかです。 動作するソフトウェアは進歩の主な尺度ですと、そのうちの一人が言います。 アジャイル原則。この文では、「作業」と「進捗」はかなりの重労働を行っているため、自分用に定義しました。機能しているとは、デプロイできるほど十分に機能していることを意味し、それが機能に貢献しているコードであれば、それは進歩です。

4. フレームワークの機能をいつテストしているかを把握してください。もしそうなら、それをしないでください。このフレームワークは、あなたよりもはるかに詳しい人々によってすでにテストされており、彼らを信頼する必要があります。 useState() フックは本来の役割を果たします。コンポーネントを小さくしておくと、フレームワークがコンポーネント内の重労働のほとんどを実行するため、多くのテストの必要性が減ります。コンポーネントが大きい場合は、より複雑になるため、多くのテストを作成する必要があります。

5. 特定の関数がどこにも収まらない場合は、その関数用に新しいモジュール (またはクラス、コンポーネント) を作成すると、後でその関数のホームを見つけることができます。意味がないとわかっている既存のモジュールにそれを押し込むよりも、新しい独立した構造を作成する方が良いでしょう。最悪の場合は最悪ですが、独立したモジュールとして機能しますが、いずれにせよそれほど悪くはありません。

6. API がどのようなものであるべきかわからない場合は、「顧客」 (この場合はあなた) について考える必要があるため、最初にテストを作成します。最初にコードを書いてその後にテストを行っていたら思いつかなかったケースが必ず見つかります。 TDD について信心深くなる必要はなく、大規模なバッチで作業しても問題ありません (たとえば、合格する前に数行以上のコードを作成するなど)。赤/失敗状態で記述するコードの量は、必ずしも少ない必要はありません。自分が何をしているのかはわかっていますが、定説に生産性の邪魔をさせないでください。

7. 一度コピペでOKです。 2 回目に重複 (つまり 3 つのコピー) を導入する場合は、行わないでください。適切な抽象化を作成するには、十分なデータ ポイントが必要です。現時点では、同じものの実装が分散するリスクが高すぎるため、統合が必要です。ほぼ同じものを複数実装するよりも、不安定なパラメータ化を行う方が良いでしょう。この状況が再び発生した場合、4 つの異なる実装を統合するよりもパラメーターを改善する方が簡単です。

8. デザインが古くなってしまいます。リファクタリングを行うことで、陳腐化する速度を遅らせることはできますが、最終的には動作方法を変更する必要があります。少し前まで自分にとって大切だったものや、当時誇りに思っていたものから離れることを、それほど悲観する必要はありません。そのときあなたは正しいことをしたので、何も変更する必要がないほど正しくできなかったことで自分を責める必要はありません。ほとんどの場合、ソフトウェアを作成することはソフトウェアを変更することです。ただ受け入れて先に進みましょう。完璧な設計などというものは存在せず、変更はソフトウェア開発の中核です。物事を変えるのがどれだけ得意かということは、ソフトウェア開発がどれだけ得意かということになります。

9. 技術的負債は、主に 3 つのタイプに分類できます。1) 現在の作業の妨げとなるもの、2) 将来の作業の妨げとなるもの、3) 将来の作業の妨げとなるもの かもしれない 後で何かをするのを防ぎます。他のすべての分類は、これら 3 つのサブセットです。 #1 に多くのものを入れることを最小限に抑え、#2 に集中するようにしてください。 ＃3は無視してください。

10. テスト容易性は優れた設計と相関関係があります。簡単にテストできないものは、設計を変更する必要があることを示しています。その設計がテスト設計である場合もあります。例として、嘲笑するのが難しいと感じた場合、 em.getRepository(User).findOneOrFail({id})その場合、その呼び出しをモックできる独自の関数に組み込むか、エンティティ マネージャー メソッドを簡単にモックできるテスト ユーティリティを作成する必要がある可能性があります。テストが難しい場合、テストは書かれなくなります。テストしたくないからではありません。

おそらくもっとたくさんあるでしょうが、10 という数字は素晴らしい数字です。