この記事では、Java 開発者が知っておく必要があるトップ 10 の戒めについて説明します。参考のために皆さんと共有してください。詳細は次のとおりです。
Java 開発者として、独自のコードの品質と保守性の向上は常にテーマとなっています。私はこの記事をオンラインで見て、自分自身を励ますために利用しました。
Java 開発者向けの標準とベスト プラクティスが数多くあります。この記事では、すべての開発者が従うべき 10 の基本的なルールをリストします。守れるルールがある場合、それは非常に悲劇的な結末につながります。
1. コードにコメントを追加する
誰もがこれを知っていますが、どういうわけかそれに従うのを忘れています。注釈を追加することを「忘れた」ことが何回あるか数えてください。それは本当です。コメントはプログラムの機能に実質的な貢献をしません。ただし、2 週間前に書いたコードに何度も、おそらく一生にわたって戻る必要があり、コードがなぜそのように動作するのかを覚えていてはなりません。これらのコードがあなたのものであれば、あなたは比較的幸運です。思い出が蘇るかもしれないから。しかし、残念なことに、多くの場合、コードは他の人のものであり、その人が会社を辞めている可能性が十分にあります。
2. 物事を複雑にしないでください
私もやったことがありますし、皆さんもやったことがあると思います。開発者は、単純な問題の解決策を思いつくことがよくあります。ユーザーが 5 人だけのアプリケーションに EJB を導入しました。フレームワークを必要としないアプリケーションにもフレームワークを使用します。プロパティ ファイル、オブジェクト指向ソリューション、スレッドをアプリケーションに追加しましたが、それらはまったく必要ありませんでした。なぜこれを行うのでしょうか?より良い方法がわからないためにそうする人もいますが、新しい知識を学び、アプリケーションを自分にとってより興味深いものにするためにそうする人もいます。
3． 覚えておいてください – 「少ないほど良い」は必ずしも良いことではありません
コードの効率化は素晴らしいことですが、多くの場合、作成するコードの行数が減ってもコードの効率が向上するわけではありません。簡単な例をお見せしましょう。
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastusedDate != null && todayDate.compareTo(lastusedDate)>0)) || (newStatusCode.equals ("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0))){ newStatusCode = "NYP";}質問したいのですが、上記のコードの if 条件が何をしたいのかを伝えるのは簡単ですか?さて、このコードを書いた人が、コードにコメントを追加するというルール 1 に従っていなかったと仮定しましょう。
この条件を 2 つの別々の if ステートメントに分割した方が簡単ではないでしょうか?ここで、次の修正されたコードを考えてみましょう。
if(newStatusCode.equals("SD") && (sellOffDate == null || todayDate.compareTo(sellOffDate)<0 || (lastusedDate != null && todayDate.compareTo(lastusedDate)>0))){ newStatusCode = "NYP ";}else if(newStatusCode.equals("OBS") && (OBSDate == null || todayDate.compareTo(OBSDate)<0)){ newStatusCode = "NYP";}読みやすくなったんじゃないでしょうか？はい、ステートメント条件を繰り返しました。はい、追加の「IF」と 2 つの追加の括弧があります。ただし、コードは読みやすく、理解しやすくなっています。
4. ハードコードは使用しないでください
開発者は、いつものように急いでいるために、このルールを意識的に忘れたり無視したりすることがよくあります。このルールに従うと予定より遅れてしまう可能性があります。今の状態を終わらせることはできないかもしれません。しかし、静的定数を定義する追加のコード行を記述すると、どれくらいの時間がかかるでしょうか?
ここに例を示します。
パブリッククラス A { パブリック静的最終 String S_CONSTANT_ABC = "ABC"; パブリックブールメソッド A(String sParam1){ if(A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){ return true;これで、文字列「ABC」を何らかの変数と比較する必要があるたびに、実際のコードが何であるかを覚えておく必要はなく、S_CONSTANT_ABC を参照するだけで済みます。また、コード全体で定数を探すのではなく、1 か所で定数を変更するのが簡単になるという利点もあります。
5. 独自のフレームワークを発明しないでください
何千ものフレームワークがリリースされており、そのほとんどはオープンソースです。これらのフレームワークの多くは優れたソリューションであり、何千ものアプリケーションで使用されています。少なくとも表面的には、これらの新しいフレームワークについていく必要があります。これらの優れた広く使用されているフレームワークの中で、最も優れた最も直接的な例の 1 つは Struts です。想像できるすべてのフレームワークの中で、このオープン ソース Web フレームワークは、Web ベースのアプリケーションに最適な候補です。ただし、2 番目のルールを覚えておく必要があります。物事を複雑にしないことです。 3 ページのみのアプリケーションを開発する場合は、Struts を使用しないでください。そのようなアプリケーションでは、リクエストを「制御」するものは何もありません。
6. 行を印刷したり文字列を追加したりしないでください
開発者はデバッグ目的で、適切と思われるあらゆる場所に System.out.println を追加することを好みますが、このコードは後で削除すると自分に言い聞かせます。しかし、これらのコード行を削除するのを忘れたり、単に削除したくないことがよくあります。 System.out.println を使用してテストを完了した後もアクセスできるのはなぜでしょうか。 System.out.println による損害を過小評価していたために、実際に必要なコード行が削除される可能性があります。次のコードを考えてみましょう。
public class BadCode { public static void CalculationWithPrint(){ double someValue = 0D; for (int i = 0; i < 10000; i++) { System.out.println(someValue = someValue + i) } } public static void CalculationWithOutPrint( ){ double someValue = 0D for (int i = 0; i < 10000; i++) { someValue = someValue + i; } } public static void main(String [] n) {BadCode.calculationWithOutPrint();以下の表では、calculationWithOutPrint() メソッドの実行に 0.001204 秒かかったことがわかります。比較すると、calculationWithPrint() メソッドの実行には 10.52 秒かかりました。
(このようなテーブルを取得する方法がわからない場合は、私の記事「WSAD を使用した Java プロファイリング」WSAD を使用した Java プロファイリングを参照してください)
このような CPU の無駄を回避する最善の方法は、次のようなラッパー メソッドを導入することです。
パブリッククラス BadCode { パブリック静的最終 int DEBUG_MODE = 1; パブリック静的最終 int PRODUCTION_MODE = 2; パブリック静的 void CalculationWithPrint(int logMode){ double someValue = 0D; i < 10000; i++) someValue + i; myPrintMethod(logMode, someValue) } } myPrintMethod(int logMode, double value) { if (logMode > BadCode.DEBUG_MODE) { return; } System.out.println(value) } public static void main(String [] n) { BadCode.calculationWithPrint(BadCode.PRODUCTION_MODE) ; }}以下の図では、StringBuffer を使用するメソッドの実行には 0.01 秒しかかからなかったのに対し、文字列の追加を使用したメソッドの実行には 0.08 秒かかったことがわかります。選択は明らかです。
7． GUIに従ってください
これがどれほどばかげているように聞こえても、何度でも言います。GUI はビジネス顧客にとって、機能やパフォーマンスと同じくらい重要です。 GUI はシステムを成功させるために不可欠な部分です。 (ただし)、IT 雑誌では GUI の重要性が無視される傾向があります。多くの組織は、「ユーザーフレンドリーな」GUI の設計に豊富な経験を持つデザイナーを雇わないことでコストを節約しています。 Java 開発者は自分自身の HTML の知識に頼る必要がありますが、この分野における知識は非常に限られています。私はこのようなアプリをたくさん見てきました。それらは「ユーザーフレンドリー」ではなく、「コンピューターに優しい」ものです。ソフトウェア開発と GUI 開発の両方に精通している開発者はほとんど見かけません。あなたがユーザー インターフェイスの開発を任された不運な開発者である場合は、次の 3 つの原則に従う必要があります。
1. 車輪の再発明をしない。同様のユーザー インターフェイス要件を持つ既存のシステムを探します。
2. まずプロトタイプを作成します。これは非常に重要なステップです。顧客は自分が何を得るのかを見ることを好みます。また、ユーザーを怒らせるようなユーザー インターフェイスを本気で作成する前にフィードバックを得ることができるので、あなたにとっても素晴らしいことです。
3. ユーザーの帽子をかぶります。言い換えれば、ユーザーの観点からアプリケーションの要件を検討します。たとえば、概要ページをページ分割するかどうかなどです。ソフトウェア開発者は、開発の複雑さが軽減されるため、システム内のページネーションを無視する傾向があります。ただし、要約されたデータには数百または数千の行が含まれるため、これはユーザーの観点からは最適なソリューションではありません。
8. 必ず文書化された要件を準備してください
すべてのビジネス要件を文書化する必要があります。これは一部のおとぎ話では真実かもしれませんが、現実の世界では不可能です。開発時間がどれだけ迫っているか、納期が近づいているかどうかに関係なく、すべてのビジネス要件が文書化されていることを常に認識しておく必要があります。
9. 単体テスト、単体テスト、単体テスト
コードの単体テストに最適な方法については詳しく説明しません。私が言いたいのは、単体テストを行う必要があるということです。これはプログラミングの最も基本的なルールです。これは、上記のすべての法律の中で無視できない最も重要なものです。コードの単体テストを作成してテストできる同僚がいるのが最善です。しかし、誰もやってくれないなら、自分でやらなければなりません。単体テスト計画を作成するときは、次のルールに従ってください。
1. コードを記述する前に単体テストを作成します。
2. 単体テストにコメントを記述します。
3. 「興味深い」関数を実行するすべてのパブリック メソッドをテストします (「興味深い」とは、特別な方法で set メソッドと get メソッドを実行しない限り、setter または getter ではないメソッドを意味します)。
10． 量ではなく質を覚えておいてください。
（必要がないときは）オフィスにあまり遅くまで残らないようにしてください。製品の問題、厳しい締め切り、予期せぬ出来事により、定時に退社できない場合があることを理解しています。しかし、通常の状況では、マネージャーは仕事を終えるのが遅すぎる従業員を評価したり、報酬を与えたりすることはありません。彼らが生産する製品の品質のおかげです。上記のルールに従えば、コードのバグが減り、保守しやすくなることがわかります。そしてそれがあなたの仕事の最も重要な部分です。
要約する
この記事では、Java 開発者向けの 10 の重要なルールを示します。これらのルールを知るだけでなく、コーディング プロセス中にそれらのルールに従うことも重要です。これらのルールが、私たちがより優れたプログラマーや専門家になるのに役立つことを願っています。
この記事が Java プログラミングの皆様のお役に立てれば幸いです。