经过几年的开发和参考，我渐渐对计算机行业“过度堆砌”产生了一些新的看法。
什么是过度堆砌？对我来说，计算机行业的过度堆砌，可以认为是一个开发者为了“炫技”，故意采用更加复杂的方式去实现某个事务。
下面我举几个例子。
个人的小型项目用BEM CSS
BEM CSS是一套规范，我在之前的博客中也提到过。他把css的命名归为
block {}
block__element {}
block--modifier {}BEM CSS是为大型多人协作项目设计的规范，是有使用成本的，例如
- 大型项目、多组件、原生无作用域CSS
- 语义化类名
- 尽量少用后代选择器
- 方便组件复用
但是个人的小型项目用，会导致BEM带来的约束、冗长的命名成本大于它带来的收益，不用反而更高效。
小脚本还用Typescript？
在github上有几百行的单文件小脚本还在用typescript去写，里面也不乏AnyScript者。这确定不是增加使用成本吗？
Demo中的复杂实现
这里举uni-app x demo中的例子，一个日历工具竟然被uni-app的开发者设计的那么复杂，这还怎么发挥教导的作用？
小型项目的分层架构
有的非常小的express项目非要严守controller service mapper这样的分层规范，增加开发成本。
如果这样的项目不分层，那么可以：
- 样板代码极少，上手快，写的快
- 没有分层规则约束
- 调试方便
- 结构扁平
- 改动成本低
任意评判技术栈的风气
很多人看见一个项目，直接针对项目所用技术栈进行评判，缺忽略了客观实际，死守教条主义，不能结合项目本身的大小、目的去给出公正的评判。
例如有人看到一个express写的项目，立即说到：“express过时了”，但根本没有深究项目核心，没有所谓的技术性评判。
一个项目所用技术，所选技术栈的好坏，从来都要从项目自身去评判。
适合项目的技术，就是好技术，从来没有优劣之分，从来不应该从中获得优越感。
总结
小型项目摒弃冗余分层、复杂规范的轻量化开发模式优势显著：样板代码更少、上手与开发速度更快，无多余规则约束，项目结构扁平清晰，调试与功能改动成本极低，更适配小型项目的开发需求。
技术无优劣，适配场景才是核心，拒绝盲目炫技式的技术堆砌，摒弃形式化技术壁垒，回归高效、务实、适配的开发本质。