首發於公眾號 大遷世界,歡迎關注。? 每週7篇實用的前端文章 ?️ 分享值得關注的開發工具 ?分享個人創業過程中的趣事
該篇文章討論了網站開發人員可能會收到的糟糕建議。文章列舉了15條糟糕的建議,這些建議可能會導致網站開發過程中的問題和挫折。
文章首先指出了一些關於程式碼質量和結構的糟糕建議,例如“永遠不需要註釋程式碼”和“忽略程式碼效能”。這些建議可能導致程式碼難以理解和維護,以及效能問題。
下面是正文
抽象層
儘可能使用多個抽象層,直到:
- 程式碼很難理解和除錯
- 修改程式碼很困難
- 程式碼執行緩慢或效率低下
- 這段程式碼不能重複使用
2. 始終在拉取請求上請求更改
你應該在第一次審查時始終阻止拉取請求,以確立優勢。一些變更請求的想法包括:
- 將變數名改長
- 縮短變數名稱
- 重新命名一個變數名
- 讓程式碼更加DRY
3. 沒有提交資訊
好的提交資訊需要花費時間來編寫。與其浪費寶貴的時間寫一些像這樣的東西,
[JIRA-1234] build: replace vue-cli with vite
可以使用以下命令將您的程式碼推送到一個空的提交訊息中
git commit --allow-empty-message -m "" && git push --force
4.使用魔法數字
經常使用魔法數字來表明你確切知道自己在做什麼
window.scrollTo({
top: 89,
left: 12,
behavior: "smooth",
});
5. 混合返回語句
永遠不要讓他們知道你的下一步行動,透過混合函式的返回語句
function shouldPayTax(income) {
if(income.amount < 20_000) {
return false
}
if(income.amount > 20_000 && income.country == 'USA') {
return true
}
if(income.country == 'Panama') {
return false
}
if(this.totalWorkingHoursPerWeek > 60) {
return true
}
if(income.amount > 20_000 && income.isCelebrity == true) {
return false
}
if(income.amount > 20_000) {
return true
}
}
6. Typescript
如果有人膽敢在專案中新增TypeScript,你可以透過在任何地方使用 any
來繞過型別檢查。
function add(a:any, b:any):any {
return a + b
}
7.使用雙等號而不是三等號
在生產捆綁包中,以節省寶貴的位元組為藉口,使用 ==
代替 ===
。
8. 評論程式碼
除了編寫難以理解的程式碼之外,留下毫無意義的誤導性註釋是讓他人困惑的絕佳方式。
一些需要遵守的規則:
- 評論應該複製程式碼
- 評論原諒不清晰的程式碼
- 如果你能寫一個清晰的評論,就不要寫
- 評論應該引起困惑,而不是消除困惑
- 不要提供複製程式碼的原始來源連結
- 請不要在最有幫助的地方包含外部參考連結
- 修復錯誤時,永遠不要新增註釋(或測試)
- 不要使用註釋來標記未完成的實現
9. 使用 Props 進行共享狀態
使用 props
傳遞狀態是一種將元件層次耦合在一起並使重構變得更加困難的好方法。
10. 使用狀態管理來管理元件狀態
另一方面,元件狀態應該被移動到一個全域性儲存中,這樣每個人都可以修改它。
11. 長元件檔案
以更好地瞭解元件的職責和能夠在不同功能中重複使用變數的能力為藉口,使用大型和單一的元件
12. 沒有程式碼檢查工具
一個程式碼檢查工具可以分析你的程式碼,並檢測潛在的錯誤、不一致性和偏離已建立的編碼標準的情況,這顯然是我們不希望出現的。
這兩個片段之間的差異是顯而易見的:
const props=defineProps({
elements:Array,
counter:{
type:Number,
default:0,
},
});
const{data,method}=useComposable();
const isEmpty=computed(()=>{returnprops.counter===0;});
watch(props.counter,()=>{console.log("Countervaluechanged");});
const emit=defineEmits(["event-name"]);
function emitEvent(){
emit("event-name");
}
function getParam(param){
return param;
}
const props = defineProps({
elements: Array,
counter: {
type: Number,
default: 0,
},
});
const { data, method } = useComposable();
const isEmpty = computed(() => {
return props.counter === 0;
});
watch(props.counter, () => {
console.log("Counter value changed");
});
const emit = defineEmits(["event-name"]);
function emitEvent() {
emit("event-name");
}
function getParam(param) {
return param;
}
專業提示:唯一可接受的使用規則是強制檔案的行數超過一定數量。1000是一個不錯的起始數字。
13. 在翻譯中使用HTML
使用硬編碼字串總是一個好主意。但有時使用包含HTML元素和類的翻譯可能會更好。
translation.key.name = Hello <span class="red">World!</span>
14. 編寫測試
不寫測試是一個不錯的選擇,但是擁有一個糟糕的測試套件可能會引起更多的沮喪。作為一般準則,一個測試應該是:
- [慢]——花足夠的時間沖泡一杯咖
- 不可靠 — 產生不穩定的結果
- 相互關聯 — 影響其他測試
- [瞭解] - 儘可能瞭解應用程式的其他部分
15. 一直相信每個人
最後,防禦性程式設計是給弱者和經驗不足者準備的。為什麼會有人想要傷害你呢?
總結
請不要因為這個而討厭我,也不要因此而被解僱。 ?
交流
首發於公眾號 大遷世界,歡迎關注。? 每週一篇實用的前端文章 ?️ 分享值得關注的開發工具 ❓ 有疑問?我來回答
本文 GitHub https://github.com/qq449245884/xiaozhi 已收錄,有一線大廠面試完整考點、資料以及我的系列文章。