【译】致 Web 开发者的 996 个反向教学
大家好,这里是大家的林语冰。
免责声明
本文属于是语冰的直男翻译了属于是,仅供粉丝参考,英文原味版请临幸 15 Terrible Advice for Web Developers。
我擅长给出反向的建议,并提出了 15 个奇技淫巧来营造挫败感,浪费每个人的时间。
1. 抽象层
使用尽可能多的抽象层,直到:
- 代码难以理解和调试。
- 很难对代码进行更改。
- 代码速度慢或效率低下。
- 代码速度慢或效率低下。
2. 始终对 PR 请求更改
在首次审查时,您应始终阻塞 PR(Pull Request),维护主导地位。
更改请求的某些想法是:
- 使用更长的变量名
- 使用更短的变量名
- 重命名变量
- 让代码更 DRY(Don't Repeat Yourself)
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. 混用 return 语句
通过在一个函数中混用 return
语句,让它们永远无法得知您的下一步行动:
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. TS(TypeScript)
如果有人大胆地将 TS 添加到项目中,您可以通过随意使用 any
来绕过类型检查。
function add(a: any, b: any): any {
return a + b
}
7. 使用 == 而不是 ===
以在生产构建中保存有价值的字节为理由,使用 ==
而不是 ===
。
8. 注释代码
除了编写难以理解的代码之外,留下毫无意义的误导性注释是混淆祂者的好方法。
要遵循的若干规则:
- 注释应该复制代码。
- 注释为不明确的代码找借口。
- 如果您能写出清晰的注释,那就干脆不要写。
- 注释应该引起混乱,而不是消除混乱。
- 切勿提供指向复制代码的源码链接。
- 切勿在最有帮助的地方包含指向外部引用的链接。
- 切勿在修复错误时添加注释(或测试)。
- 切勿使用注释来标记不完整的实现。
9. 使用共享状态的 props
使用 props
传递状态是耦合组件层次结构并增加重构难度的好方法。
10. 对组件状态使用状态管理
另一方面,组件状态应移动到全局存储中,以便每个人都可以修改它。
11. 长组件文件
使用大型和整体式组件的借口是更好地了解组件职责并能够跨功能重用变量。
12. 禁用 Linter
linter 可以分析您的代码,并检测潜在的错误、不一致性和偏离既定编码标准,这显然是我们不希望看到的。
以下两个代码段的差异是显而易见的:
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
}
专业提示:linting 规则唯一可接受的用法是将文件设置为比给定行数更长。1_000
是一个优秀的起始数字。
13. 在翻译中使用 HTML
使用硬编码字符串始终是一个好主意。但有时使用包含 html 元素和类的翻译会更好。
translation.key.name = Hello <span class="red">World!</span>
14. 编写测试
不编写测试是一个不错的选择,但拥有一个糟糕的套件可能会营造更多的挫败感。作为一般准则,测试应为:
- [S]low — 花足够的时间冲泡咖啡
- [U]nreliable — 产生可变结果
- [C]oupled — 影响其他测试
- [K]nowledgable — 尽可能多地了解 App 的其他部分
15. 永远相信每个人
最后,防御性编程是为弱者和缺乏经验的人准备的。为什么会有人想伤害您?
完结撒花
请不要埋怨我,也不要因此而被解雇。
如果您想阅读更多可怕的建议,看看 C++ 开发者的 60 个可怕的奇技淫巧,这些“黑魔法”启发了这篇文章。如果您自己有一条邪恶的建议,请在下方群聊自由言论。
您现在收看的是前端翻译计划,学废了的小伙伴可以订阅此专栏合集,我们每天佛系投稿,欢迎持续关注前端生态。谢谢大家的点赞,掰掰~
转载自:https://juejin.cn/post/7302338286768881716