现如今，网络上关于怎么构建健壮、可维护 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 <span class="red">World!</span>

14. 编写测试

不编写测试当然也挺好，但要想真正把人折磨疯，最好还是要测试、只是提供一套极差的套件。这里向大家分享折磨人测试的一般准则：

• 慢——测试时间足够我们去泡杯咖啡；

• 不可靠——常测常新，永远不确定这测试到底靠不靠谱；

• 耦合——会影响到其他测试；

• 过度延伸——尽可能跟应用程序中的其他部分扯上关系。

悟性高的朋友还可以参考这份单元测试进阶“教程”：

https://fadamakis.com/8-tips-for-writing-better-unit-tests-8c0a8d8cde16

15. 永远信任一切

最后，只有懦夫和小白才需要防御性编程。这世上哪有那么多坏人？

总结

请大家别把文章当真，因实操而遭解雇的话，本文作者概不负责。😅

如果大家有自己的“奇思妙想”，请在评论栏中不吝分享。

原文链接：

https://fadamakis.com/15-terrible-advice-for-web-developers-e821e95f5d18

相关阅读：

Web3当下，最佳投资就是投资自己

Web3的反思，不要抱怨

给Web3创业者的28个原则

和我一起学习Web3