掃二維碼與項(xiàng)目經(jīng)理溝通
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
大家好，我是田螺。
我們開發(fā)完需求，提測(cè)前，一般都需要代碼評(píng)審。小伙伴們，你們知道代碼評(píng)審，一般都有哪些軍規(guī)嘛？今天田螺哥給你帶來代碼評(píng)審的18個(gè)軍規(guī)。
其實(shí)，寫代碼的時(shí)候，沒有必要寫太多的注釋，因?yàn)楹玫姆椒?、變量名，就是最好的注釋。以下就是筆者總結(jié)的一些注釋規(guī)范：
以下就是一些添加注釋的demo：
/**
* @author 田螺
* @date 2023/04/22 5:20 PM
* @desc 田螺的實(shí)現(xiàn)類，撿田螺、賣田螺 （更多干貨，關(guān)注公眾號(hào)：撿田螺的小男孩）
*/
public class TianLuoClass {
/**
* 這是賣田螺的兩法，它將兩個(gè)田螺的價(jià)格整數(shù)相加并返回結(jié)果。
*
* @param x 第一個(gè)整數(shù)
* @param y 第二個(gè)整數(shù)
* @return 兩個(gè)整數(shù)的和
*/
public int sellTianLuo(int x, int y) {
return x + y;
}
}日志是快速定位問題的好幫手，是撕逼和甩鍋的利器！打印好日志非常重要。如果代碼評(píng)審的時(shí)候，這些日志規(guī)范沒遵守，就需要修改：
對(duì)于日志打印規(guī)范，我之前整理出一篇文章，大家可以看一下哈，挺有用的：
工作總結(jié)！日志打印的15個(gè)建議
Java代碼的命名應(yīng)該清晰、簡(jiǎn)潔和易于理解。我們代碼評(píng)審的時(shí)候，要注意是否有命名不規(guī)范，不清晰的代碼。下面是一些命名規(guī)范的建議：
我們代碼評(píng)審的時(shí)候，要注意參數(shù)是否都做了校驗(yàn)，如userId非空檢查、金額范圍檢查、userName長(zhǎng)度校驗(yàn)等等。一般我們?cè)谔幚順I(yè)務(wù)邏輯的時(shí)候，要遵循先檢查、后處理的原則。
如果你的數(shù)據(jù)庫字段userName設(shè)置為varchar(16),對(duì)方傳了一個(gè)32位的字符串過來，你不校驗(yàn)參數(shù)，插入數(shù)據(jù)庫直接異常了。
很多bug都是因?yàn)闆]做參數(shù)校驗(yàn)造成的，這一軍規(guī)，是代碼評(píng)審重點(diǎn)關(guān)注的哈：
if(object!=null){
String name = object.getName();
}如果你要遍歷列表，也需要判空
良好的異常處理可以確保代碼的可靠性和可維護(hù)性。因此，異常處理也是代碼評(píng)審的一項(xiàng)重要規(guī)范。以下是一些異常處理的建議：
大家有興趣可以看下之前我的這篇文章哈：Java 異常處理的十個(gè)建議
代碼評(píng)審的時(shí)候，關(guān)注一下，代碼編寫設(shè)計(jì)是否滿足模塊話，接口是否具有可擴(kuò)展性
比如你的需求是醬紫：是用戶添加或者修改員工時(shí)，需要刷臉。那你是反手提供一個(gè)員工管理的提交刷臉信息接口？還是先思考：提交刷臉是不是通用流程呢？比如轉(zhuǎn)賬或者一鍵貼現(xiàn)需要接入刷臉的話，你是否需要重新實(shí)現(xiàn)一個(gè)接口呢？還是當(dāng)前按業(yè)務(wù)類型劃分模塊，復(fù)用這個(gè)接口就好，保留接口的可擴(kuò)展性。
如果按模塊劃分的話，未來如果其他場(chǎng)景比如一鍵貼現(xiàn)接入刷臉的話，不用再搞一套新的接口，只需要新增枚舉，然后復(fù)用刷臉通過流程接口，實(shí)現(xiàn)一鍵貼現(xiàn)刷臉的差異化即可。
至于分布式鎖,大家可以看下我之前的這幾篇文章哈
良好的代碼格式，可以使代碼更容易閱讀和理解。下面是一些常見的代碼格式化建議：
代碼評(píng)審的時(shí)候,要重點(diǎn)關(guān)注是否考慮到了接口的兼容性.因?yàn)楹芏郻ug都是因?yàn)樾薷牧藢?duì)外舊接口，但是卻不做兼容導(dǎo)致的。關(guān)鍵這個(gè)問題多數(shù)是比較嚴(yán)重的，可能直接導(dǎo)致系統(tǒng)發(fā)版失敗的。新手程序員很容易犯這個(gè)錯(cuò)誤哦~
所以，如果你的需求是在原來接口上修改，尤其這個(gè)接口是對(duì)外提供服務(wù)的話，一定要考慮接口兼容。舉個(gè)例子吧，比如dubbo接口，原本是只接收A，B參數(shù)，現(xiàn)在你加了一個(gè)參數(shù)C，就可以考慮這樣處理：
//老接口
void oldService(A,B){
//兼容新接口，傳個(gè)null代替C
newService(A,B,null);
}
//新接口，暫時(shí)不能刪掉老接口，需要做兼容。
void newService(A,B,C){
...
}代碼評(píng)審的時(shí)候，要關(guān)注程序邏輯是否清晰。比如，你的一個(gè)注冊(cè)接口，有參數(shù)校驗(yàn)、判斷用戶是否已經(jīng)注冊(cè)、插入用戶記錄、發(fā)送注冊(cè)成功通知等功能。如果你把所有所有功能代碼塞到一個(gè)方法里面，程序邏輯就不清晰，主次不夠分明，反例如下:
其實(shí)，以上這塊代碼，主次不夠分明的點(diǎn):參數(shù)校驗(yàn)就占registerUser方法很大一部分。正例可以劃分主次，抽一下小函數(shù)，如下：
public Response registerUser(String userName, String password, String email) {
//檢查參數(shù)
checkRegisterParam(userName, password, email);
//檢查用戶是否已經(jīng)存在
if (checkUserInfoExist(userName)) {
Response response = new Response();
response.setCode(0);
response.setMsg("注冊(cè)成功");
return response;
}
//插入用戶
addUser(userName, password, email);
sendMsgOfRegister(userName, email);
//構(gòu)造注冊(cè)成功報(bào)文
Response response = new Response();
response.setCode(0);
response.setMsg("注冊(cè)成功");
return response;
}
private void sendMsgOfRegister(String userName, String email) {
MessageDo messageDo = new MessageDo();
messageDo.setUserName(userName);
messageDo.setEmail(email);
messageDo.setContent("注冊(cè)成功");
messageService.sendMsg(messageDo);
}
private void addUser(String userName, String password, String email) {
UserInfo addUserInfo = new UserInfo();
addUserInfo.setUserName(userName);
addUserInfo.setPassword(password);
addUserInfo.setEmail(email);
userService.addUserInfo(addUserInfo);
}
private boolean checkUserInfoExist(String userName) {
UserInfo userInfo = userService.queryUserInfoByUsername();
if (Objects.nonNull(userInfo)) {
return true;
}
return false;
}
private void checkRegisterParam(String userName, String password, String email) {
if (userName == null || StringUtils.isEmpty(userName)) {
log.info("用戶名不能為空！");
throw new BizException();
}
if (password == null || password.length() < 6) {
log.info("密碼長(zhǎng)度不能少于6位！");
throw new BizException();
}
if (email == null || StringUtils.isEmpty(email) || !email.contains("@")) {
log.info("郵箱格式不正確！");
throw new BizException();
}
}代碼評(píng)審，也非常有必要評(píng)審代碼是否存在安全性問題。比如：
其實(shí)我以前寫過一篇文章，保證數(shù)據(jù)安全的10種方案，大家可以看看哈：保證接口數(shù)據(jù)安全的10種方案
什么是冪等？
計(jì)算機(jī)科學(xué)中，冪等表示一次和多次請(qǐng)求某一個(gè)資源應(yīng)該具有同樣的副作用，或者說，多次請(qǐng)求所產(chǎn)生的影響與一次請(qǐng)求執(zhí)行的影響效果相同。
代碼評(píng)審的時(shí)候，要關(guān)注接口是否考慮冪等。比如開戶接口，多次請(qǐng)求過來的時(shí)候，需要先查一下該客戶是否已經(jīng)開過戶，如果已經(jīng)開戶成功，直接返回開戶成功的報(bào)文。如果還沒開戶，就先開戶，再返回開戶成功的報(bào)文。這就是冪等處理。
一般情況有這幾種冪等處理方案：
冪等要求有個(gè)唯一標(biāo)記，比如數(shù)據(jù)庫防重表的一個(gè)業(yè)務(wù)唯一鍵。同時(shí)強(qiáng)調(diào)多次請(qǐng)求和一次請(qǐng)求所產(chǎn)生影響是一樣的。
大家如果對(duì)接口冪等有興趣的話，可以看下我之前的這篇文章：聊聊冪等設(shè)計(jì)
代碼評(píng)審的時(shí)候，如果用數(shù)據(jù)庫、Redis、RocketMq等的中間件時(shí)，我們需要關(guān)注這些中間件的一些注意事項(xiàng)哈。
比如數(shù)據(jù)庫：
比如Redis:
之前我寫過一篇文章，介紹Redis使用注意點(diǎn)的，大家可以看一下哈:使用Redis，你必須知道的21個(gè)注意要點(diǎn)
理解幾個(gè)常見的代碼壞味道，大家代碼評(píng)審的時(shí)候，需要關(guān)注一些哈：
遠(yuǎn)程調(diào)用是代碼評(píng)審重點(diǎn)關(guān)注的一欄，比如：
我們?cè)谖⑿派?4小時(shí)期待你的聲音
解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流
微信二維碼
微信二維碼
移動(dòng)版官網(wǎng)