コーディングの優先順位の設定
私が働いていた開発ショップでは、「コーディングの優先順位」について誰も言及していません。私はこれを本やサイトのどこかで読んで、コードの最初に優先すべき優先順位を設定します。これが指定されていない場所では、最優先事項は何ですか？
「ビジネスニーズに必要なことを実行する」と言うのは簡単に聞こえるかもしれませんが、パフォーマンス/保守性が犠牲になる可能性があります。多くの人は、保守性を最初に言いますが、それでも、ニーズを満たすと言う人もいます。
私は若い開発者なので、おそらくどこかで要点を見逃しています。もちろん、完璧なソリューションはあり得ないため、プログラミングはエンジニアリングであり、困難です。
ありがとう
プログラマーが最初に尋ねるべき質問は、「このコードを書く必要がありますか？」だと思います。私たちは、既存の堅牢なオープンソースソフトウェアの豊かな世界に住んでいます。独自のライブラリまたはアプリケーションを作成する前に、他の誰かがすでに数か月または数年かけて開発したものを探すために少し時間を費やしてください。
これは常に、ビジネス要件とアプリケーションのメンテナンスの間のバランスを取る行為です。
場合によっては、優先順位が制御できなくなります。法的な理由や主要なバグへの対処など、ビジネス要件を順守する以外に選択肢はありません。
他の例では、ビジネス要件とシステムに与える可能性のある長期的な（マイナスの？）影響との間で交渉が必要です。たとえば、開発マネージャーである誰かが、開発ショップの懸念を表明し、そのような場合の妥協に基づいて開発作業を管理する必要があります（うまくいけば）。
次に、優先順位があなたの管理下にある場合があります。次に、時間を効果的に管理し、求められたものを提供するのはあなた次第です。
したがって、優先順位の管理には少しスペクトルがあります。経験を積むにつれて、さまざまな状況で物事がどのように機能するかがわかります。暫定的に、注意し、必要に応じて懸念を表明し、最善を尽くし続けます（-：
HTHと幸運、
KM
ソフトウェアプロジェクトに関連する主なコストは複雑さです。このコストは、とりわけ、ソフトウェアの作成の難しさ、ソフトウェアの保守のコスト、および失敗したプロジェクトのコストに主に影響します。
ほとんどのソフトウェア開発チームの最優先事項は、複雑さを軽減することです。
保守性にはさまざまな色合いがあるため、この質問にそのまま答えるのは困難です。
私は保守性の3つのレベルを区別します：
- 読み取り可能なコード
- 繰り返しを避ける
- アーキテクチャ/リファクタリング
最初のレベルは非常に基本的であり、開発時間はかかりません。これは、新しいコードを書く（または古いコードを読む）たびに、可能な限り読みやすくし、コメントを追加/調整することを意味します。
2番目のレベルはそれほど基本的ではありませんが、それほど圧倒的でもありません。これは単に、コードを追加するときはいつでも、これからやろうとしていることを実行する何かがまだないかどうかを確認する必要があることを意味します。ある場合は、一般的なものをマージします（すばらしい、書く必要はありませんでした！）。これにより、コードの繰り返しが回避されます。つまり、修正するときに、修正をn番目のコピーに伝播する必要がなくなります。
3番目のレベルは間違いなくコストがかかります。アーキテクチャの変更と大規模なリファクタリングは、すぐに数日の作業を消費します。
このリストを念頭に置いて、議論するのはもう少し扱いやすいです。
- お急ぎの場合は、1。と2.を適用し、アーキテクチャについて過度に心配しないでください（もちろん、アーキテクチャがない場合は、問題を解決する最も単純なアーキテクチャを作成してください）。
- 空き日が数日ある場合、またはプレッシャーがかかっていない場合は、可能であればリファクタリングを検討してください
2番目を有効にするために、私は変更したいことのTODOリストを維持する傾向がありますが、今は行う時間がありません。次に、手元にあるとき、またはこのリストに表示されているコードの一部に取り組む機会が生じて、数日間のメンテナンスを行うことができるときは、そのまま続行します。
それは常に妥協です、あなたはそれと一緒に暮らすことを学ぶ必要があります。ビジネスニーズは、ソフトウェア自体またはそれが生成するサービスのいずれかを販売することです。市場投入までの時間は、給与を支払う会社にとって非常に重要です。必要なときに合理的な製品は、納期が遅すぎる完璧な製品よりもはるかに優れています。
あなたがジュニア開発者であれば、正しい妥協点を見つける必要はありません。それはマネージャーのためです。しかし、あなたは彼らにいくつかのインプットを与えることができます。
あなたは本質的に顧客が常に正しいと言っているのは正しいですが、残っている要素は製品の平均余命と顧客のニーズです。
たとえば、ユーザーができるだけ早く必要とする機能に取り組んでいる場合は、今すぐ機能に取り組み、後でパフォーマンスを微調整することをお勧めします。ただし、機能が引き続き機能することを確認することが重要であるため、時間が経つにつれて、保守性が重要になります。
（出典：私も若い開発者です）