Javaプログラマー10のルール
2676 ワード
周知のように、すべての開発者は開発過程であるべき規則や戒律に従うべきであり、Javaプログラマーにも従うべき規則やベストプラクティスがたくさんあります.
1.簡単なことを複雑にしない
開発者は複雑な方法で簡単な問題を解決する傾向がある.仮に,我々は5人のユーザしかいないシステムにEJBを導入し,フレームワークを必要としないアプリケーションのためにフレームワークを実現し,属性ファイルを採用し,オブジェクト向けソリューションを採用し,スレッドを使用するが,これらはまったく必要ないと仮定する.どうしてそうするの?より良い解決策があることを知らない人もいるかもしれませんが、わざと新しい知識を学ぶか、ただ面白いからかもしれません.より良い解決策を知らない人には、経験のあるプログラマーのアドバイスをよく聞いてください.
2.コードにコメントを追加します.
誰もがそれを知っていますが、誰もがそうするわけではありません.ただし、コメントはあなたのプログラムに関数機能を追加しません.しかし、2週間前に書いたコードを見て、何をしているのか覚えていません.「行き交うこともあれば、互恵互恵」ということわざがあるので、プログラマーはお互い(そしてあなた自身)を理解し、コードに注釈をつけなければなりません.
3.「ハードコーディング」しない
時間が迫っているため、開発者はいつもこれを忘れたり、わざと無視したりします.しかし、もう一つの可能性は、この戒律に従うと、私たちは「時間が迫っている」という苦境に陥ることはありません.static final変数を定義し、コードを1行増やして、どれくらいの時間がかかりますか?たとえば、
文字列「ABC」と変数を比較するたびに、A.S_を参照します.CONSTANT_ABCはそれ自体が何なのかを覚える必要はありません.この定数の修正も非常に便利で、すべてのコードで検索する必要がなく、場所を変更すればいいです.
4.シンプルなコードの設計
効率的なコードは良いことですが、コード行数が少ないほど効率が高いわけではありません.1つの判断文に大量の判断情報が含まれていると仮定し、このような可読性が悪いだけでなく実行効率も高くないことを考えてみましょう.複数の判断文に分解して、コードをより読みやすく、理解しやすくすることができます.
5.グラフィックユーザインタフェースに注意
グラフィックユーザインタフェースは、ビジネスユーザにとってプログラム機能および実行効率と同様に重要である.グラフィック・ユーザー・インタフェースは、アプリケーションの成功に重要です.
6.自分という枠組みを勝手に開発しない
現在、市場では多くのフレームワークが完璧なソリューションであり、何千ものシステムに使用されています.私たちは最新の流行の枠組みに注目すれば、少なくとも表面的には熟知しなければならない.最も成功し、広く使用されている例はStrutsフレームワークであり、このオープンソースのwebフレームワークはwebシステムを構築するのに最適な選択であり、自分のStrutsバージョンを構築しようとしないでください.疲れてしまいます.もちろん、開発するシステムが3つのインタフェースしかない場合は、Strutsを使用しないでください.このようなシステムに対して、このような複雑なものを使う必要はありません.
7.Print行または文字列の慎重な使用
デバッグの便利さのために、プログラマーはあちこちでSystemを使うのが好きです.out.println、それから自分に少し言ったら削除します.しかし、私たちはよくこれらの行を削除することを忘れたり、削除したくないので、Systemを使っています.out.printlnはテストをして、どうして測定が終わった後にコードを変更しますか?これは、必要なコードを1行誤って削除する可能性があります.システムを過小評価するなout.printlnの危害.
8.文書はプロジェクトの主心骨である
各ビジネス要件はドキュメントに記入されます.どんなに時間が迫っていても、締め切りが迫っていても、ビジネスニーズが記録されていることを確認する必要があります.
9.ユニットテスト
この点はやらなければならない.これはプログラミングの中で最も基本的なルールで、特に無視できません.もしあなたの同僚があなたのコードのためにテスト計画を作成することができたら、それに越したことはありません.できないなら、自分でやらなければなりません.ユニットテスト計画をするとき.
10.数量ではなく品質
私は時々製品の問題で、締め切りやその他の突発事件で、時間通りに退勤できないことを知っています.しかし、マネージャーはあなたが一般的な問題のために遅く滞在したことに感謝したり奨励したりしません.彼らは質の高い仕事に感謝します.上記の列の原則に従うと、より丈夫でバグの少ないプログラムを書くことができます.これこそ君が一番やるべきことだ.
1.簡単なことを複雑にしない
開発者は複雑な方法で簡単な問題を解決する傾向がある.仮に,我々は5人のユーザしかいないシステムにEJBを導入し,フレームワークを必要としないアプリケーションのためにフレームワークを実現し,属性ファイルを採用し,オブジェクト向けソリューションを採用し,スレッドを使用するが,これらはまったく必要ないと仮定する.どうしてそうするの?より良い解決策があることを知らない人もいるかもしれませんが、わざと新しい知識を学ぶか、ただ面白いからかもしれません.より良い解決策を知らない人には、経験のあるプログラマーのアドバイスをよく聞いてください.
2.コードにコメントを追加します.
誰もがそれを知っていますが、誰もがそうするわけではありません.ただし、コメントはあなたのプログラムに関数機能を追加しません.しかし、2週間前に書いたコードを見て、何をしているのか覚えていません.「行き交うこともあれば、互恵互恵」ということわざがあるので、プログラマーはお互い(そしてあなた自身)を理解し、コードに注釈をつけなければなりません.
3.「ハードコーディング」しない
時間が迫っているため、開発者はいつもこれを忘れたり、わざと無視したりします.しかし、もう一つの可能性は、この戒律に従うと、私たちは「時間が迫っている」という苦境に陥ることはありません.static final変数を定義し、コードを1行増やして、どれくらいの時間がかかりますか?たとえば、
public class A {
public static final String S_CONSTANT_ABC = "ABC";
public boolean methodA(String sParam1){
if (A.S_CONSTANT_ABC.equalsIgnoreCase(sParam1)){
return true;
}
return false;
}
} 文字列「ABC」と変数を比較するたびに、A.S_を参照します.CONSTANT_ABCはそれ自体が何なのかを覚える必要はありません.この定数の修正も非常に便利で、すべてのコードで検索する必要がなく、場所を変更すればいいです.
4.シンプルなコードの設計
効率的なコードは良いことですが、コード行数が少ないほど効率が高いわけではありません.1つの判断文に大量の判断情報が含まれていると仮定し、このような可読性が悪いだけでなく実行効率も高くないことを考えてみましょう.複数の判断文に分解して、コードをより読みやすく、理解しやすくすることができます.
5.グラフィックユーザインタフェースに注意
グラフィックユーザインタフェースは、ビジネスユーザにとってプログラム機能および実行効率と同様に重要である.グラフィック・ユーザー・インタフェースは、アプリケーションの成功に重要です.
6.自分という枠組みを勝手に開発しない
現在、市場では多くのフレームワークが完璧なソリューションであり、何千ものシステムに使用されています.私たちは最新の流行の枠組みに注目すれば、少なくとも表面的には熟知しなければならない.最も成功し、広く使用されている例はStrutsフレームワークであり、このオープンソースのwebフレームワークはwebシステムを構築するのに最適な選択であり、自分のStrutsバージョンを構築しようとしないでください.疲れてしまいます.もちろん、開発するシステムが3つのインタフェースしかない場合は、Strutsを使用しないでください.このようなシステムに対して、このような複雑なものを使う必要はありません.
7.Print行または文字列の慎重な使用
デバッグの便利さのために、プログラマーはあちこちでSystemを使うのが好きです.out.println、それから自分に少し言ったら削除します.しかし、私たちはよくこれらの行を削除することを忘れたり、削除したくないので、Systemを使っています.out.printlnはテストをして、どうして測定が終わった後にコードを変更しますか?これは、必要なコードを1行誤って削除する可能性があります.システムを過小評価するなout.printlnの危害.
8.文書はプロジェクトの主心骨である
各ビジネス要件はドキュメントに記入されます.どんなに時間が迫っていても、締め切りが迫っていても、ビジネスニーズが記録されていることを確認する必要があります.
9.ユニットテスト
この点はやらなければならない.これはプログラミングの中で最も基本的なルールで、特に無視できません.もしあなたの同僚があなたのコードのためにテスト計画を作成することができたら、それに越したことはありません.できないなら、自分でやらなければなりません.ユニットテスト計画をするとき.
10.数量ではなく品質
私は時々製品の問題で、締め切りやその他の突発事件で、時間通りに退勤できないことを知っています.しかし、マネージャーはあなたが一般的な問題のために遅く滞在したことに感謝したり奨励したりしません.彼らは質の高い仕事に感謝します.上記の列の原則に従うと、より丈夫でバグの少ないプログラムを書くことができます.これこそ君が一番やるべきことだ.