大家好呀，我是你们的wangly。
其实这篇文章早就想写了，随着前端的使用场景越来越宽泛，Web，桌面，小程序，H5，大批量的项目刺激着前端开发的热度，但随之而来的就是在写项目时碰到一个个雷区，往往自己的炸的一脸黑，所以，才写一篇心得探讨文，与君共勉。文章的目的总结一下:
- 第一是总结下原因，警醒自己。
- 第二是想温故而知新，白嫖学习下其他的建议。
如果你们也碰到让自己懊恼的方案，不妨在评论区PR交流一下，共同进步。
万丈高楼平地起
正所谓万丈高楼平地起，好的地基对于房子的重要性大家都知道吧。同样的，一个好的项目在孵化的时候，就一定是由严谨的需求分析，可行性分析,技术选型,原型设计都是一个唇枪舌剑的过程。而所谓的豆腐渣项目就是：
- 需求分析基本没有，做项目完全靠参考其他项目。
- 可行性分析就是想办法实现，哪怕牺牲性能。
- 技术选型还算好，毕竟前端项目多数以三大框架为主。
- 原型设计，出图可能靠自己，也许有个UI，但可能也因为前面的流程没走对从而爆炸或者设计歪了。
出现此类情况的可能是产品经理和项目经理没有统筹，多数以敏捷开发为主的公司。
要想马儿跑，就要给好草
江湖上流传着各种跑路代码的传说，虽然一部分可能是因为菜，但也许真的是故意为之。吃多少草干多少活。所以一个糟糕的项目也和开发的人员的付出比有关系的。节省开发经费的时候，消耗的是你项目的寿命。根据经验，往往此类项目容易在此人提桶后难逃重构的命运，也就是所谓的竹篮打水一场空。反复循环。因为本身开发人员开发时想的只是实现功能，根本没有想过迭代。所以：本人都可能不知道怎么维护，何况接盘侠？
此类以小公司和外包为主。毕竟只要东西出来就好。一般都不想给钱。想自己多赚点。至于项目交尾就溜了。
拆东西二墙，以补之?
什么是拆东西二桥？需求做到一半，将自己前面依赖的逻辑砍掉。最后导致一件非常尴尬的事情，流程跑不通，跑不通。那么怎么办呢？答曰：见山开山，见路修路。正所谓缝缝补补又三年。补丁打的多了，删删改改遗留的代码就成为了一个隐患。常见的是当新人接手，容易在项目中绕晕，一不小心将某个口子打开，从而引起连锁反应。最后通宵修复无果，隔天跑路。该项目从开发到胎死腹中往往只是一个新需求的事情。
往往存在外包公司，项目进程一半，开发组可能就轮换了一批。正所谓：接盘包车，不稳也不慌。
需求不明，脑门拍烂
往往有时候，灵机一动，灵光乍现，突发奇想，茅舍顿开...等等词语变得非常的贬义，因为这些时候我们总能接到一些拍脑门需求。当功能开发出来，可能本人就忘记了，更有可能就直接砍掉了。最后奋斗了个空气。瞎忙活一场。然后过几天又要加上去。摇摆不定，最后后面新需求出来的时候，砍掉的功能就不会删除代码，而是将其注释或者隐藏起来，最后自己也不会去删除。
往往属于服务和部分学校外包公司。
过河拆桥
这类情况发生在改原型，没错就是该原型。项目做到一般，因为特殊原因，觉得不好看。所以重新设计。没错重新设计。既然重新设计了，交互逻辑肯定是大部分重写。所以难免重构代码。也就是过河拆桥，重新来过。要么是产品或者项目看到别家的东西比自己好看，想重新开始，又或者是项目未验收通过，甲方爸爸不满意。
一般在某些外包公司，生死有命，富贵在甲方。双方剥削。
总结
优秀的项目大部分都是一个优秀的团队产出。因为好的团队磨合对于项目可不是1 + 1 = 2，众所周知三个臭皮匠顶一个诸葛亮。当然，个别大佬除外。一个人顶一群人也是存在的。总而言之，本篇文章主要是给大家注意一下。避免开发的时候中路提桶。
前方高能：以上小型外包公司可能都占据了，这也是为什么大多数人对外包问之告辞的原因。
