作者 | Fotis Adamakis
译者 | 核子可乐
策划 | 丁晓昀
现如今，网络上关于怎么构建健壮、可维护 Web 应用的文章随处可见，相信大家早就看烦了。那如果公司里刚好来了个你看着不顺眼的新同事，各位打算给这家伙点颜色瞧瞧，该怎么下手？别担心，坏事就由我来做。只要按照以下 15 条建议实施，绝对能让 Web 开发者在浪费一整天时间之后、陷入深深的沮丧与自我怀疑当中。
1. 抽象层
多用抽象层、越多越好，直到：
代码已经难以理解和调试。
代码变更变得极为困难。
代码运行速度变慢、效率降低。
代码失去复用性。
2. 用各种方式刁难 PR 变更
一定要拖住 PR 请求，借此维护住你在项目中的主导地位。
下面提几个可行的刁难借口：
要求把变更名延长；
要求把变量名缩短；
要求重新命名变更名；
要求代码更“紧凑”。
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. 注释代码
除了要编写难以理解的代码之外，也别忘了留下毫无意义的误导性注释，否则没准哪个聪明人就看懂了你的开发逻辑。
相关参考规则如下：
注释应该与代码重复；
注释的作用是解释代码为什么不够清楚；
对于可以写出清晰注释的部分，什么都别写；
注释的意义在于引起混乱，而非消除混乱；
切勿提供复制代码的原始链接；
切勿提供有帮助的外部参考链接；
在修复 bug 时，切勿添加任何注释（或测试）；
切勿使用注释来标记不完整的实现。
这里还有更多“妙招”供大家参考：
https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/
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(()=>{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;
}
专业提示：关于 linting 规则，唯一可以接受的用法就是确保文件长度超过特定行数。这里不妨把数字设定为 1000。
13. 在翻译中使用 HTML
要想搞砸 Web 开发，对字符串进行硬编码永远是种好办法。有时候，使用包含 html 元素和类的翻译更能够“锦上添花”。
translation.key.name = Hello World!
14. 编写测试
不编写测试当然也挺好，但要想真正把人折磨疯，最好还是要测试、只是提供一套极差的套件。这里向大家分享折磨人测试的一般准则：
慢——测试时间足够我们去泡杯咖啡；
不可靠——常测常新，永远不确定这测试到底靠不靠谱；
耦合——会影响到其他测试；
过度延伸——尽可能跟应用程序中的其他部分扯上关系。悟性高的朋友还可以参考这份单元测试进阶“教程”：
https://fadamakis.com/8-tips-for-writing-better-unit-tests-8c0a8d8cde16
15. 永远信任一切
最后，只有懦夫和小白才需要防御性编程。这世上哪有那么多坏人？
总结
请大家别把文章当真，因实操而遭解雇的话，本文作者概不负责。
如果大家有自己的“奇思妙想”，请在评论栏中不吝分享。
声明：本文为 InfoQ 翻译，未经许可禁止转载。
原文链接：
https://fadamakis.com/15-terrible-advice-for-web-developers-e821e95f5d18