J'ai travaillé pendant de nombreuses années et j'ai rencontré toutes sortes de collègues. J'ai vu toutes sortes de codes, excellents, nuls, peu attrayants, etc. Cet article enregistre quelques habitudes personnelles de développement de code.
1. Paramètres de la méthode d'encapsulation
Lorsque votre méthode comporte trop de paramètres, il est recommandé d'encapsuler un objet. Ce qui suit est un matériel pédagogique négatif. Qui vous a appris à écrire un tel code ?
public void updateX(long num, String str1, String str2,
String str3, String str4,
String str5, String str6) {
}
Essayez d'encapsuler ces sorties dans un objet
public class X {
private Long num;
private String str1;
...
}
Pourquoi écrivez-vous ainsi ? Par exemple, votre méthode est pour la requête. Si vous ajoutez des conditions de requête ultérieurement, devez-vous modifier la méthode ? La liste des paramètres de la méthode doit être modifiée à chaque fois qu'elle est ajoutée. Encapsulez un objet, quel que soit le nombre de conditions de requête ajoutées à l'avenir, il vous suffit d'ajouter des champs à l'objet. Le fait est que le code a l'air confortable aussi!
2. Encapsuler la logique métier
Si vous avez vu "Shit Mountain", vous vous sentirez profondément. Une telle méthode peut écrire des milliers de lignes de code, et il n'y a aucune règle. Souvent, le responsable dira que ce métier est trop compliqué et qu'il n'y a aucun moyen de l'améliorer, ce qui est une excuse pour être paresseux. Quelle que soit la complexité de l'entreprise, nous pouvons améliorer la lisibilité du code grâce à une conception et un conditionnement raisonnables. Vous trouverez ci-dessous un code suggéré.
@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);
}
Le métier dans ce code est très complexe. On estime que 10 000 choses ont été faites de manière conservatrice en interne, mais les choses écrites par des personnes à différents niveaux sont complètement différentes. Je dois louer la scission de cette entreprise et l'encapsulation de la méthode. Il existe plusieurs petites entreprises au sein d'une grande entreprise. Différentes entreprises peuvent appeler différentes méthodes de service.
La personne qui prend la relève peut comprendre rapidement l'entreprise même s'il n'y a pas de documents pertinents tels que des organigrammes. De nombreuses méthodes commerciales écrites par le développement principal sont la première ligne de code pour l'entreprise A, la ligne de code suivante pour l'entreprise B et la ligne de code suivante pour l'entreprise A. Il existe également un tas de logique d'unité imbriquée et appelée entre les entreprises, ce qui est très désordonné et contient beaucoup de code.
3. La bonne façon de juger que le type de collection n'est pas vide
Beaucoup de gens aiment écrire du code comme celui-ci pour juger des collections
if (list == null || list.size() == 0) {
return null;
}
Bien sûr, si vous insistez pour écrire comme ça, il n'y a pas de problème.
org.springframework.util.CollectionUtils Mais ne vous sentez pas mal à l'aise, maintenant tout package jar dans le framework a une classe d'outil de collecte, telle que com.baomidou.mybatisplus.core.toolkit.CollectionUtils. Veuillez écrire comme ceci à l'avenir
if (CollectionUtils.isEmpty(list)) {
return null;
}
4. La valeur de retour du type de collection ne renvoie pas null
Lorsque votre méthode métier renvoie un type de collection, veuillez ne pas renvoyer null, l'opération correcte consiste à renvoyer une collection vide. Jetez un œil à la requête de liste de mybatis. Si aucun élément n'est interrogé, il renverra une collection vide au lieu de null. Sinon, l'appelant doit faire un jugement NULL, et il en va de même pour les objets dans la plupart des cas.
5. Il est recommandé d'utiliser le lombok
Bien sûr, c'est un point discutable, et j'ai l'habitude de l'utiliser pour omettre les getters, les setters, toString, etc. Utiliser Lombok
6. Écrivez le moins d'outils possible
Pourquoi écrire moins de classes d'outils, car la plupart des classes d'outils que vous écrivez sont incluses dans le package jar que vous importez, telles que String, Assert assertion, IO upload file, copy stream, Bigdecimal], etc. Il est facile d'écrire vos propres bogues et de charger des classes redondantes.
7. Rédigez des commentaires significatifs sur la méthode
Est-ce qu'écrire ce genre de commentaire a peur que la personne qui prendra la relève plus tard soit aveugle.
Ne l'écrivez pas ou ajoutez simplement une description après. C'est pénible d'écrire des commentaires comme celui-ci et de recevoir un tas d'avertissements d'IDEA
/**
* 请求号码验证
*
* @param a
* @param b
* @param param
* @return Result
*/
8. Essayez de ne pas laisser IDEA appeler la police
Très dégoûté de voir une série d'avertissements dans la fenêtre du code IDEA, très inconfortable. Parce qu'il y a des avertissements, le code peut être optimisé ou il y a un problème. Il y a quelques jours, j'ai trouvé un petit bug dans Teams. Cela n'a rien à voir avec moi, c'est juste que mes collègues surveillent les affaires à l'extérieur et jugent pourquoi les affaires ne vont pas. J'ai jeté un coup d'œil à la question.
Parce que les littéraux entiers int en Java sont typés, ils deviennent une collection d'Integer, puis cliquez dessus. stepId est un type long, et Long est dans la collection, alors cela contient des retours faux correctement, ce n'est pas un type.
Vous voyez, si vous faites attention à l'avertissement, vous pouvez déplacer la souris dessus pour voir l'indice, et il y aura un bogue de production en moins.
9. Utiliser autant que possible de nouveaux composants techniques
Je pense que c'est la qualité qu'un programmeur devrait avoir. Quoi qu'il en soit, j'aime utiliser de nouveaux composants technologiques, car l'émergence de nouveaux composants technologiques consiste à résoudre les lacunes des anciens composants technologiques, et en tant que techniciens, nous devons suivre le rythme.
Bien sûr, la prémisse est d'être préparé, pas de mettre à niveau pour acquis. Java 17 a publié l'exemple le plus simple et les nouveaux projets utilisent toujours Date pour gérer DateTime.
en conclusion
Ce qui précède sont quelques-unes de mes opinions personnelles, veuillez indiquer s'il y a des lacunes.