私は長年働いてきて、あらゆる種類の同僚に会いました。私は、優れたコード、ゴミ、魅力のないコードなど、あらゆる種類のコードを見てきました。この記事では、個人的なコード開発の習慣を記録します。
1. カプセル化方式パラメータ
メソッドにパラメータが多すぎる場合は、オブジェクトをカプセル化することをお勧めします。以下はネガティブな教材ですが、誰にこんなコードの書き方を教えられたのでしょうか？
public void updateX(long num, String str1, String str2,
String str3, String str4,
String str5, String str6) {
}
これらの出力をオブジェクトにカプセル化してみてください
public class X {
private Long num;
private String str1;
...
}
なぜこのように書くのですか？たとえば、メソッドはクエリ用です。後でクエリ条件を追加する場合、メソッドを変更する必要がありますか? メソッドパラメータリストは追加するたびに変更する必要があります。オブジェクトをカプセル化すると、今後クエリ条件がどれだけ追加されても、オブジェクトにフィールドを追加するだけで済みます。コードもすっきり見えるのがポイント！
2. ビジネスロジックをカプセル化する
『クソ山』を観たことがある人なら感慨深いだろう。このような方法では、数千行のコードを記述することができますが、ルールはまったくありません。多くの場合、担当者は「この業務は複雑すぎて改善する方法がありません」と言い、それは怠け者の言い訳になります。ビジネスがどれほど複雑であっても、合理的な設計とパッケージ化を通じてコードの可読性を向上させることができます。以下は推奨コードです。
@Transactional
public void clearBills(Long customerId) {
//获取清算所需的票据ng
ClearContext context = getClearContext(customerId);
// 验证该金额是否合法
checkAmount(context);
// 确定优惠券是否可用，并返回可扣除金额
CouponDeductibleResponse deductibleResponse = couponDeducted(context);
// 结清所有账单
DepositClearResponse response = clearBills(context);
// 发送还款对账消息
repaymentService.sendVerifyBillMessage(customerId, context.getDeposit());
// 更新帐户余额
accountService.clear(context, response);
// 处理已清算的息票，用完或未绑定
couponService.clear(deductibleResponse);
// 保存优惠券扣减记录
clearCouponDeductService.add(context, deductibleResponse);
}
このコードのビジネスは非常に複雑です。内部で保守的に行われたものは 10,000 件あると推定されていますが、さまざまなレベルの人々によって書かれたものはまったく異なります。このビジネスの分割と手法のカプセル化を賞賛せざるを得ません。大企業の中に複数の中小企業が存在します。企業が異なれば、異なるサービス メソッドを呼び出すことができます。
引き継ぐ人は、フローチャートなどの関連資料がなくても業務をすぐに理解できます。一次開発によって記述されたビジネス メソッドの多くは、ビジネス A のコードの最初の行、ビジネス B のコードの次の行、ビジネス A のコードの次の行になります。また、ビジネス間でネストされて呼び出される多数のユニット ロジックもあり、非常に煩雑でコード量も多くなります。
3. コレクション型が空ではないことを判断する正しい方法
多くの人はコレクションを判断するためにこのようなコードを書くことを好みます
if (list == null || list.size() == 0) {
return null;
}
もちろん、こう書くことにこだわるのであれば問題ありません。
org.springframework.util.CollectionUtils ただし、フレームワーク内のどの jar パッケージにも com.baomidou.mybatisplus.core.toolkit.CollectionUtils などの収集ツール クラスが含まれるようになりました。今後はこのように記述してください。
if (CollectionUtils.isEmpty(list)) {
return null;
}
4. コレクション型の戻り値がnullを返さない
ビジネス メソッドがコレクション型を返す場合、null を返さないでください。空のコレクションを返すのが正しい操作です。mybatisのリストクエリを見てみましょう。クエリされた要素がない場合は、null ではなく空のコレクションが返されます。それ以外の場合、呼び出し元は NULL 判定を行う必要があり、オブジェクトについてもほとんどの場合同じことが当てはまります。
5. ロンボクの使用をお勧めします
もちろん、これは議論の余地があり、私の習慣はゲッター、セッター、toString などを省略するためにこれを使用することです。ロンボク島を利用する
6. できるだけ少ない数のツールを作成する
作成するツール クラスのほとんどが、インポートする jar パッケージ (文字列、アサート アサーション、IO アップロード ファイル、コピー ストリーム、BigDecimal など) に含まれるためです。独自のバグを作成したり、冗長なクラスをロードしたりするのは簡単です。
7. 意味のあるメソッドコメントを書く
このようなコメントを書いているのは、後に引き継ぐ人が失明することを恐れているのでしょうか。
それを書かないか、その後ろに説明を追加するだけです。このようなコメントを書いてIDEAから大量の警告を受け取るのは面倒です
/**
* 请求号码验证
*
* @param a
* @param b
* @param param
* @return Result
*/
8.IDEAに警察を呼ばせないようにしてください
IDEA コード ウィンドウに一連の警告が表示されるのは非常に不快で、非常に不快です。警告があるため、コードを最適化できるか、問題がある可能性があります。数日前、Teams で小さなバグを発見しました。それは私とは何の関係もありません。同僚が外でビジネスを観察し、なぜそのビジネスが間違っているのかを判断しているだけです。私は質問に目を通しました。
Java の整数リテラル int は型指定されているため、Integer のコレクションになり、それをクリックします。stepId が long 型で、Long がコレクション内にある場合、これに含まれる値は正しく false を返します。これは型ではありません。
警告に注意を払っていれば、その上にマウスを移動するとヒントが表示され、本番環境のバグが 1 つ減ります。
9. 可能な限り新しい技術コンポーネントを使用する
これがプログラマーに求められる資質だと思います。とにかく、私は新しい技術コンポーネントを使用するのが好きです。なぜなら、新しい技術コンポーネントの出現は、古い技術コンポーネントの欠点を解決することであり、技術者として、私たちは時代についていく必要があるからです。
もちろん、アップグレードするのが当たり前ではなく、備えが前提です。Java 17 は最も単純な例をリリースしましたが、新しいプロジェクトでは引き続き DateTime を処理するために Date を使用します。
結論は
上記は私の個人的な意見ですので、不備等ありましたらご指摘ください。