Loading article…
コーディングのベストプラクティスまたはプログラミングのベストプラクティスは、コンピュータプログラミングにおいて多くのソフトウェア開発者がソフトウェアの品質を向上するために従う、非公式で時には個人的なルール（ベストプラクティス）のセットです。[1]多くのコンピュータプログラムは、長期間にわたって堅牢で信頼性があることが求められるため、[2]ルールは、最初の開発とその後のソースコードの作成者以外の人々による メンテナンスの両方を容易にする必要があります。
トム・カーギルは、90-90ルールで、プログラミングプロジェクトが遅れることが多い理由を次のように説明しています。「コードの最初の90%に開発時間の最初の90%がかかります。最後の10%に残りの90%の時間がかかります。」 [3]この先見性の欠如を是正できるガイダンスは、検討する価値があります。
プロジェクトやプログラムの規模は、エラー率、プログラマの生産性、必要な管理の量に大きな影響を与えます。[4]
ソフトウェアの品質
以下に挙げるように、優れたソフトウェアには多くの特性が関連しています。これらの特性の中には、相互に矛盾するもの（非常に高速であることと、広範囲にわたるエラーチェックを実行することなど）もあり、顧客や参加者によって優先順位が異なる場合があります。Weinberg は、目標が異なると、必要な労力と効率の両方に劇的な影響が出る例を示しています。[5]さらに、彼は、プログラマーは一般に、おそらく他の品質特性を犠牲にして、設定された明示的な目標を達成することを目指すだろうと指摘しています。
サマービルは、プログラムが何をするかではなく、プログラムがそれをどれだけうまく行うかに関係する4つの一般的な属性を特定しました。それは、保守性、信頼性、効率性、使いやすさです。[6]
ワインバーグは、優れたプログラムが満たすべき4つの目標を特定しました。[7]
- プログラムは仕様（「可能な入力ごとに正しい出力」）を満たしていますか?
- プログラムはスケジュールどおりに（予算内で）制作されていますか?
- 変化する要件に対応するためにプログラムはどの程度適応可能ですか?
- プログラムは、使用される環境に対して十分に効率的ですか?
ホーアはソフトウェア品質に関連する17の目標を特定しており、その中には以下が含まれる: [8]
- 目的を明確に定義する。
- 使いやすさがシンプル。
- 堅牢性（誤用されにくく、エラーが発生しにくい）。
- 早期利用可能（必要なときに時間どおりに配送）。
- 信頼性。
- 経験に照らした拡張性。
- 簡潔。
- 効率性（目的に応じて十分な速さ）。
- 開発コストは最小限です。
- 関連する標準（プログラミング言語固有の標準を含む）への準拠。
- 明確で正確かつ精密なユーザードキュメント。
前提条件
コーディングを開始する前に、必要な前提条件がすべて完了している (または少なくともコーディングの強固な基盤を提供できるほど十分に進んでいる) ことを確認することが重要です。さまざまな前提条件が満たされていない場合、ソフトウェアは完成していても不十分なものになる可能性があります。
Meek & Heath によれば、「コーディング段階に入る前に何が起こるかが、プロジェクトの成功にとって非常に重要になることが多い。」[9]
以下に概説する前提条件には、次のような事項が含まれます。
- 開発はどのように構成されていますか? (ライフサイクル)
- ソフトウェアの目的は何ですか? (要件)
- ソフトウェア システムの全体的な構造は何ですか? (アーキテクチャ)
- 個々のコンポーネントの詳細設計はどのようなものですか? (設計)
- プログラミング言語の選択肢は何ですか?
小規模でシンプルなプロジェクトの場合、アーキテクチャとデザインを組み合わせて、非常にシンプルなライフサイクルを採用することが可能な場合があります。
ライフサイクル
ソフトウェア開発方法論は、ソフトウェア製品のライフサイクルを構造化、計画、および制御するために使用されるフレームワークです。一般的な方法論には、ウォーターフォール、プロトタイピング、反復的および増分的開発、スパイラル開発、アジャイル ソフトウェア開発、ラピッド アプリケーション開発、エクストリーム プログラミングなどがあります。
ウォーターフォールモデルは、順次開発アプローチです。特に、プロジェクトの開始時に要件を完全に定義できることを前提としています。しかし、McConnell は、平均してプロジェクト中に要件が約 25% 変更されることを示す 3 つの研究を引用しています。[10]上記の他の方法論はすべて、多くの場合、段階的、増分的、または反復的なアプローチによって、このような要件変更の影響を軽減しようとします。異なる開発環境には、異なる方法論が適している場合があります。
2001年に導入されて以来、アジャイルソフトウェア開発は、ソフトウェア開発に対するより反復的で協調的なアプローチを求めるソフトウェア開発者によって人気が高まってきました。[11]
要件
マコーネルは次のように述べている。「建設を始める前に満たす必要がある最初の前提条件は、システムが解決することになっている問題を明確に述べることです。」[12]
ミークとヒースは、明確で、完全で、正確で、曖昧さのない書面による仕様が目指すべき目標であると強調しています。[13]この目標を達成することはできない可能性があり、目標はいずれにしても変更される可能性があることに注意してください（前のセクションで述べたように）。
サマービルは、あまり詳細でないユーザー要件とより詳細なシステム要件を区別しています。[14]また、機能要件（例：レコードの更新）と非機能要件（例：応答時間は1秒未満でなければならない）も区別しています。
建築
ホーアは次のように指摘している。「ソフトウェア設計を構築するには2つの方法がある。1つは欠陥が明らかにないほど単純にすること。もう1つは欠陥が明らかにないほど複雑にすること。最初の方法の方がはるかに難しい。」[15]
ソフトウェア アーキテクチャは、何を行う必要があるか、どのプログラム コンポーネントがそれを行うかを決定することに関係しています (どのように行うかは、以下の詳細設計フェーズに委ねられます)。これは、ソフトウェア システムに複数のプログラムが含まれている場合に、さまざまなプログラム間のインターフェイスを効果的に定義するため、特に重要です。過度に詳細に踏み込まずに、ユーザー インターフェイスについても考慮する必要があります。
この段階では、非機能的なシステム要件（応答時間、信頼性、保守性など）を考慮する必要があります。[16]
ソフトウェア アーキテクチャは、さまざまな利害関係者 (スポンサー、エンド ユーザーなど) にとっても興味深いものです。これは、ソフトウェア アーキテクチャによって、要件が満たされるかどうかを確認する機会が与えられるためです。
デザイン
設計の主な目的は、アーキテクチャ設計で軽視された詳細を補うことです。設計は、使用する特定のアルゴリズムの詳細を含め、実際のコーディングの適切なガイドとなるほど詳細にする必要があります。たとえば、アーキテクチャ レベルでは、一部のデータをソートする必要があることがわかっているかもしれませんが、設計レベルでは、どのソート アルゴリズムを使用するかを決定する必要があります。さらに別の例として、オブジェクト指向アプローチを使用する場合は、オブジェクトの詳細 (属性とメソッド) を決定する必要があります。
プログラミング言語の選択
マイヤーは次のように述べています。「完璧なプログラミング言語はありません。最高の言語は一つもありません。特定の目的に適した言語、あるいは適していない言語があるだけです。問題とそれに関連するプログラミング要件を理解することは、解決策に最適な言語を選択するために必要です。」[17]
Meek & Heath より: 「言語を選択する技術の本質は、問題から始めて、その要件が何であるか、そしてそれらの相対的な重要性を決定することです。なぜなら、それらすべてを同じように満たすことはおそらく不可能だからです。次に、利用可能な言語を要件のリストと比較して、最も適切な (または最も不満足でない) ものを選択します。」[18]
問題のさまざまな側面には、異なるプログラミング言語が適している可能性があります。言語またはそのコンパイラが許可する場合は、同じプログラム内で異なる言語で記述されたルーチンを混在させることも可能です。
どのプログラミング言語を使用するか選択の余地がない場合でも、マコーネルは次のようなアドバイスをしています。「すべてのプログラミング言語には長所と短所があります。使用している言語の特定の長所と短所を認識してください。」[19]
コーディング標準
このセクションは、実際にはコーディングの前提条件でもあります。McConnell 氏は次のように指摘しています。「プログラミングを始める前にプログラミング規則を確立してください。後からそれに合わせてコードを変更することはほぼ不可能です。」[19]
コーディング規約の最後のほうにリストされているように、プログラミング言語ごとに異なる規約があるため、異なる言語に同じ規約を適用すると逆効果になる場合があります。プログラミング言語ごとに特定のコーディング規約があるわけではないことに注意することが重要です。組織ごとに、ソフトウェア プロジェクトの種類ごとにカスタム コーディング標準があります。したがって、ソフトウェア プロジェクトを開始する前に、プログラマーが特定のコーディング ガイドラインのセットを選択または作成することが不可欠です。コーディング規約の中には汎用的なものもあり、特定のプログラミング言語で記述されたすべてのソフトウェア プロジェクトに当てはまるとは限りません。
コーディング規則の使用は、プロジェクトに複数のプログラマーが関与する場合に特に重要です (数千人のプログラマーが関与するプロジェクトもありました)。すべてのコードが同じ規則に従っている場合、プログラマーは他の誰かが書いたコードを読むのがはるかに簡単になります。
悪いコーディング規約の例として、Roedy Greenは保守不可能なコードを作成する方法についての長い（冗談めいた）記事を提供しています。[20]
コメント
時間的な制約や、コードにすぐに結果を求める熱心なプログラマーのせいで、コードへのコメントは後回しにされることがよくあります。コーディングは通常サイクルに従って行われるため、または複数の人が特定のモジュールで作業する可能性があるため、チームで作業するプログラマーはコメントを残しておく方が良いと感じています。ただし、ある程度のコメントは、同じモジュールで作業する開発者間の知識移転のコストを削減できます。
コンピュータが普及した初期の頃は、次のような簡単な説明をコメントに残すのが慣例でした。
- モジュール名
- モジュールの目的
- モジュールの説明
- 原作者
- 変更
- コードを変更した作成者と、変更理由の説明。
「モジュールの説明」は、明瞭性と包括性を犠牲にすることなく、できるだけ簡潔にする必要があります。
しかし、最後の 2 つの項目は、リビジョン コントロール システムの出現により、ほとんど廃止されました。コメントを使用するのではなく、このようなツールを使用すると、変更とその作成者を確実に追跡できます。
また、複雑なロジックが使用されている場合は、他のプログラマーが何が起こっているのか正確に理解できるように、その部分の近くにコメント「ブロック」を残すことをお勧めします。
ユニット テストは、コードがどのように使用される予定であるかを示すもう 1 つの方法です。
命名規則
適切な命名規則を使用することは良い習慣と考えられています。プログラマーは、X1、Y1 などを変数として使用し、意味のあるものに置き換えることを忘れて混乱を招くことがあります。
通常は説明的な名前を使用するのが良い習慣だと考えられています。
例: トラックの重量をパラメータとして取り込む変数には、TrkWeight、TruckWeightKilograms、または Truck_Weight_Kilograms という名前を付けることができます。TruckWeightKilograms (変数のPascal ケース命名を参照) はすぐに認識できるため、多くの場合は好ましい名前ですが、命名規則はプロジェクト間や会社間で必ずしも一貫しているわけではありません。
コードをシンプルにする
プログラマーが書くコードはシンプルであるべきです。単純なことを達成するための複雑なロジックは、将来別のプログラマーによってコードが変更される可能性があるため、最小限に抑える必要があります。あるプログラマーが実装したロジックが、別のプログラマーにとって完全に理解できるとは限りません。したがって、常にコードを可能な限りシンプルにしてください。[21]
ポータビリティ
プログラム コードには、絶対ファイル パス、ファイル名、ユーザー名、ホスト名、IP アドレス、URL、UDP/TCP ポートなどの環境パラメータを参照する「ハードコードされた」(リテラル) 値を含めないでください。そうしないと、アプリケーションは、予想とは異なる設計のホストでは実行されません。注意深いプログラマーは、このような変数をパラメータ化し、アプリケーション本体の外部 (たとえば、プロパティ ファイル内、アプリケーション サーバー上、またはデータベース内) でホスティング環境用に構成できます。「単一定義ポイント」のマントラと比較してください。[22] (SPOD)。
拡張機能として、XML ファイルなどのリソースにはリテラル値ではなく変数も含める必要があります。そうしないと、XML ファイルを編集しないとアプリケーションを別の環境に移植できなくなります。たとえば、アプリケーション サーバーで実行される J2EE アプリケーションでは、このような環境パラメータを JVM のスコープ内で定義でき、アプリケーションはそこから値を取得する必要があります。
スケーラビリティ
ソフトウェア プロジェクトでは、プロジェクトが大きくなるにつれて常に新しい機能が追加されるため、スケーラビリティを設計目標としてコードを設計します。したがって、ソフトウェア コード ベースに新しい機能を追加する機能は、ソフトウェアを作成する上で非常に貴重な方法になります。
再利用性
再利用は、ソフトウェア開発において非常に重要な設計目標です。再利用により開発コストが削減され、再利用されるコンポーネントまたはモジュールがすでにテストされている場合は、開発時間も短縮されます。多くの場合、ソフトウェア プロジェクトは、以前のバージョンのプロジェクトを含む既存のベースラインから開始され、プロジェクトによっては、既存のソフトウェア モジュールとコンポーネントの多くが再利用されるため、開発とテストの時間が短縮され、ソフトウェア プロジェクトをスケジュールどおりに提供できる可能性が高まります。
建設ガイドラインの概要
上記のすべての概要:
- コードブロックが実行しなければならないことを知る
- 全体を通して一貫した命名規則を維持します。
- 変数の目的についての簡単な説明を示します（コメントへの参照）
- エラーが発生したらすぐに修正します。
- コードをシンプルにする
- スケーラビリティと再利用を考慮してコードを設計します。
コード開発
コード構築
コード構築のベストプラクティスには、毎日のビルドとテスト、さらには継続的インテグレーション、さらには継続的デリバリーが含まれます。
テスト
テストは、計画する必要のあるソフトウェア開発の不可欠な部分です。テストを積極的に行うことも重要です。つまり、コーディングを開始する前にテスト ケースを計画し、アプリケーションの設計とコーディング中にテスト ケースを開発する必要があります。
コードのデバッグとエラーの修正
プログラマーは、コード全体を記述してからデバッグとエラーのチェックを開始する傾向があります。このアプローチは小規模なプロジェクトでは時間を節約できますが、大規模で複雑なプロジェクトでは注意が必要な変数や関数が多すぎる傾向があります。したがって、プログラム全体ではなく、完了したら各モジュールをデバッグすることをお勧めします。これにより、長期的には時間が節約され、何が間違っているかを把握するのに多くの時間を無駄にすることがなくなります。個々のモジュールの単体テストや、Web サービスおよび Web アプリケーションの機能テストは、これに役立ちます。
展開
デプロイメントは、アプリケーションをユーザーにリリースする最終段階です。いくつかのベストプラクティスは次のとおりです。[23] [24]
- インストール構造をシンプルに保ちます。ファイルとディレクトリは最小限に抑える必要があります。決して使用されないものはインストールしないでください。
- 必要なものだけを保持する:ソフトウェア構成管理アクティビティでは、これが確実に実施されるようにする必要があります。未使用のリソース (ファイル、ソース コード、インターフェイスなどの古いバージョンまたは失敗したバージョン) は、新しいビルドをスリムに保つために、別の場所にアーカイブする必要があります。
- すべてを最新の状態に保つ: ソフトウェア構成管理アクティビティでは、これが確実に実施されるようにする必要があります。 デルタベースの展開の場合、デルタを展開する前に、既に展開されているリソースのバージョンが最新であることを確認してください。 不明な場合は、最初から展開を実行します (最初にすべてを削除してから再展開します)。
- 多段階戦略を採用する：プロジェクトの規模によっては、より多くの展開が必要になる場合があります。[25]
- ロールバック戦略を用意する: 以前の (動作中の) バージョンにロールバックする方法が必要です。
- 繰り返し可能なプロセスには自動化を活用する: 人為的ミスが発生する余地が大きすぎるため、展開は手動で行うべきではありません。各オペレーティングシステムにネイティブなツールを使用するか、クロスプラットフォーム展開にはスクリプト言語を使用します。[26] [27]
- 実際の展開環境を再現します。すべてを考慮します (ルーター、ファイアウォール、Web サーバー、Web ブラウザー、ファイル システムなど)。
- デプロイメント手順とスクリプトをその場で変更せず、そのような変更を文書化します。新しい反復を待って、そのような変更を適切に記録します。
- カスタマイズした展開：APIやマイクロサービスなどの新しいソフトウェア製品では、展開を成功させるために特別な考慮が必要です。[28] [29] [30]
- 他の開発フェーズからのリスクを軽減する：テストや構成管理などの他のアクティビティが間違っていると、展開は確実に失敗します。[31] [32]
- 各ステークホルダーが持つ影響力を考慮する：組織的、社会的、政府的な考慮。[33] [34] [35]
参照
- ベストプラクティス
- 静的コード解析ツールのリスト
- 自動車業界ソフトウェア信頼性協会(MISRA)
- ソフトウェア保証
- ソフトウェアの品質
- ソフトウェア開発哲学のリスト
- 大聖堂とバザール- トップダウンとボトムアップのオープンソース ソフトウェアを比較した本
- デイビス201ソフトウェア開発の原則[36]
- ソフトウェア工学の理論はどこにあるのか？[37]
- 考えさせないで（直感的なナビゲーションと情報デザインの原則）[38]
注記
参考文献
- ^ McConnell, Steve (2004). Code Complete . Redmond, Washington: Microsoft Press. p. [ページ必要] . ISBN 978-0-7356-9125-4. OCLC 61315783.
- ^ サマービル、イアン (2004)。ソフトウェアエンジニアリング(第 7 版)。ピアソン。p. 38。ISBN 0-321-21026-3。
- ^ Bentley, Jon (1985). 「プログラミングの秘訣: バンパーステッカーコンピュータサイエンス」Communications of the ACM . 28 (9): 896–901. doi : 10.1145/4284.315122 . ISSN 0001-0782. S2CID 5832776.
- ^ McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. pp. 649–659. ISBN 0-7356-1967-0。
- ^ ワインバーグ、ジェラルド (1998)。『コンピュータプログラミングの心理学』（銀記念版）。ドーセットハウス出版、ニューヨーク。pp. 128–132。ISBN 978-0-932633-42-2。
- ^ サマービル、イアン (2004)。ソフトウェアエンジニアリング(第 7 版)。ピアソン。pp. 12–13。ISBN 0-321-21026-3。
- ^ ワインバーグ、ジェラルド (1998)。『コンピュータプログラミングの心理学』（銀記念版）。ドーセットハウス出版、ニューヨーク。pp. 15–25。ISBN 978-0-932633-42-2。
- ^ Hoare, CAR (1972). 「ソフトウェアの品質」.ソフトウェア: 実践と経験. 2 (2). Wiley: 103–105. doi : 10.1002/spe.4380020202 .
- ^ ミーク、ブライアン、ヒース、パトリシア (1980)、「優れたプログラミング実践ガイド」、エリス・ホーウッド、ワイリー、p. 14
- ^ McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. p. 40. ISBN 0-7356-1967-0。
- ^ Sacolick, Isaac (2022年4月8日). 「アジャイル手法の簡単な歴史」. Infoworld . 2023年2月6日閲覧。
- ^ McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. p. 36. ISBN 0-7356-1967-0。
- ^ ミーク、ブライアン、ヒース、パトリシア (1980)、「優れたプログラミング実践ガイド」、エリス・ホーウッド、ワイリー、p. 15
- ^ サマービル、イアン (2004)。ソフトウェアエンジニアリング(第 7 版)。ピアソン。pp. 118–123。ISBN 0-321-21026-3。
- ^ Hoare, CAR (1981). 「The Emperor's Old Clothes」（PDF） . Communications of the ACM . 24（2）. ACM：75–83. doi：10.1145/358549.358561 . S2CID 97895. 2019年11月25日閲覧。
- ^ サマービル、イアン (2004)。ソフトウェアエンジニアリング(第 7 版)。ピアソン。pp. 242–243。ISBN 0-321-21026-3。
- ^ Mayer, Herbert (1989). IBM PC での高度な C プログラミング. Windcrest Books. p. xii (序文). ISBN 0830693637。
- ^ ミーク、ブライアン、ヒース、パトリシア (1980)、「優れたプログラミング実践ガイド」、エリス・ホーウッド、ワイリー、p. 37
- ^ ab McConnell, Steve (2004). Code Complete (第2版). Microsoft Press. p. 70. ISBN 0-7356-1967-0。
- ^ Roedy Green. 「メンテナンス不可能なコード: Java 用語集」。2013年 11 月 26 日閲覧。
- ^ 複数 (wiki)。「ベストプラクティス」。Docforge 。 2012年11月13日閲覧。
- ^ 「例による単一定義ポイント」。2015年11月30日閲覧。
「何も繰り返さないでください。アプリケーションのあらゆる側面について、単一の定義ポイントを目指してください [...]」。
- ^ 「7 つのアプリケーション デプロイメントのベスト プラクティス - Done Devops」。dzone.com。
- ^ 「ソフトウェア展開の 7 つの大罪 [LWN.net]」。lwn.net。
- ^ blog.fortrabbit.com/multi-stage-deployment-for-website-development
- ^ Cruz, Victor (2013 年 4 月 3 日)。「アプリの導入の 30% が失敗する理由」Wired – www.wired.com 経由。
- ^ 「ソフトウェア展開のルール」。2010 年 5 月 13 日時点のオリジナルよりアーカイブ。
- ^ 「需要に合わせて展開をスピードアップするために必要なツール」2017 年 2 月 3 日。
- ^ Ankerholz, Amber (2016 年 9 月 14 日)。「DevOps と安全なアプリケーション展開の技術」
- ^ 「障害条件に合わせたソフトウェア展開の編成」Amazon Web Services 2014 年 5 月 5 日。
- ^ 「リスクのないデプロイメントのためのベストプラクティス」TheServerSide.com。
- ^ Ambler, Scott. 「効果的なソフトウェア展開」。Dr . Dobb's。
- ^ 「エンタープライズ アプリケーションの展開: ソフトウェア実装の人間性」。2016 年 8 月 21 日時点のオリジナルよりアーカイブ。
- ^ 「官僚主義のハッキング：採用とソフトウェア導入の改善 | 18F：デジタルサービス提供」。18f.gsa.gov。2014年5月14日。
- ^ 「不適切なソフトウェア導入は何もしないより悪い」。Intact Technology 2016 年 6 月 1 日。
- ^ デイビス、アラン・マーク。(1995)。ソフトウェア開発の201の原則。ニューヨーク：マグロウヒル。ISBN 0-07-015840-1. OCLC 31814837.
- ^ Johnson, Pontus; Ekstedt, Mathias; Jacobson, Ivar (2012). 「ソフトウェアエンジニアリングの理論はどこにあるのか?」IEEE ソフトウェア. 29 (5): 96. doi :10.1109/MS.2012.127. ISSN 0740-7459. S2CID 38239662.
- ^ スティーブ・クルーグ（2014年）。『Don't make me think, revisited : a common sense approach to Web usability』。エリザベス・ベイル、アレン・ストレイガー、マーク・マッチョ（第3版）。[サンフランシスコ、カリフォルニア州] 。ISBN 978-0-321-96551-6. OCLC 859556499.
{{cite book}}: CS1 maint: location missing publisher (link)
- Harbison, Samuel P.; Steele, Guy L. (2002). C - A リファレンスマニュアル. ISBN 978-0-13-089592-9。
- 『開発ライフ サイクルを強化して安全なソフトウェア製品を開発する、V2.0、2008 年 10 月』では、ソフトウェア開発者、テスト担当者、インテグレーターが、より安全なソフトウェア集約型システムの開発と、開発するソフトウェアのセキュリティの検証という 2 つの目標を達成するために採用できるセキュリティの原則と実践について説明しています。
- Dutta, Shiv; Hook, Gary (2003 年 6 月 26 日)。「C 言語でのプログラミングのベスト プラクティス」。developerWorks。IBM。2009年 7 月 13 日時点のオリジナルよりアーカイブ。2010 年1 月 21日閲覧。
外部リンク
- MISRA C コーディング標準の共著者であり、10 年以上にわたって MISRA C ワーキング グループで PRQA の代表を務めている Paul Burden 氏は、コーディング標準に関する一般的な誤解について次のように述べています。「コーディング標準は必要ありません。必要なのはバグをキャッチすることだけです。」