本文源于一条谈论。
有个读者谈论说：“发现许多前端的大领导多是后端。他们尽管懂一点前端，但总觉得前端简单。有时候，很难向其证明前端不好完结。”
这位朋友让我写一写，那我就写一写。
反正，不论啥事儿，我高低都能整两句，不说白不说，说了也白说。本文暂时算是一条谈论回复吧。乐意看扯淡的同学能够留一下。
现象分析
首先，前半句让我很有同感。因为，我便是前端身世，并且在研制办理岗上又待过。这个身份，让我既了解前端的作业流程，又常常和后端平级一起交流经验。这有点卧底的意思。
有一次，咱们几个朋友聚餐闲聊。他们也都是各个公司的研制负责人。我们就各自吐槽自己的项目。
有一个人就说：“咱们公司，有一个干前端的带项目了，让他搞得一团糟”
另一个人听到后，就叹了一口气：“唉！这不是外行领导内行吗？！”
我其时听了感觉有点别扭。我扫视了一圈儿，如同就我一个前端。因而，我也点了点头（默念：我是卧底）。
是啊，一般的项目、研制办理岗，多是后端开发。因为后端是事务的设计者，他掌握着基本的数据结构以及事务流通。而前端在他们看来，便是调调API，然后把成果展示到页面上。
别的，一般项目遇到大事小情，也都是找后端处理。比方手动修正数据、批量生成数据等等。从这儿能够看出，项目的“根基”在后端手里。
互联网编程界流传着一条轻视链。它是这样说的，搞汇编的轻视写C语言的，写C的轻视做Java的，写Java的轻视敲Python的，搞Python的轻视写js的，搞js的轻视作图的。然后，作图的设计师周末带着妹子看电影，前面的那些大哥继续加班写代码。
当然，咱们发起一个友好的环境，不发起三六九等。这儿仅仅调侃一下，选用夸张的手法来阐述一种现象。
这儿所谓的“轻视”，其本质是源于谁更接近原理。
比方写汇编的人，他以为自己的代码能直接调用“CPU”、“内存”，能够直接操作硬件。有些前端会以为美工设计的东西，得依靠自己来完结，并且他们不明白技术就乱设计，还有脸要求100%复原。
所以啊，有些只做过后端的人，或许会以为前端开发没啥东西。
好了，上面是现象分析。关于谁更有优越感，这不能细究啊，因为这是没有结论的。假如搞一个辩论赛，就比方说”Python一句话，汇编写三年“之类论据，各有千秋。各种语言既然能呈现，必定有它的妙用。
我便是胡扯啊。不论您是哪个工种，请不要对号入座。假如您觉得被冒犯了，能够谈论“啥都不明白”，然后脱离。千万不要砸自己的电脑。
下面再聊聊第二部分，面对这种状况，有什么好的应对办法？
应对办法
我感觉，后端身世的负责人，就算是出于人际关系，也是会尊重前端开发的。
“小张啊，对于前端我不是很懂。所以请帮我评价下前端的工期。最好列得细致一些，这样有利于我了解人员的作业量。弄完了，发给我，咱们再讨论一下！”
一般都是这么做。
这种状况，咱们就老老实实给他上报就行了，顶多加上10%~30%处理未知危险的时间。
可是，他假如这样说：“什么？这个功用你要做5天？给你1天都多！”
这时，他是你的领导，对你又有考核，你怎么办？
你心里一酸：“我离任吧！小爷我受不了这委屈！”
这……当然也能够。
假如你有更好的去处，能够这样。就算是没有这回事，有好去处也赶紧去。
可是，假如这个公司整体还行呢？仅仅这个直接领导有问题。那么你能够考虑，这个领导是流水的，你俩处不了多长时间。哪个公司每年不搞个组织架构调整啊？你找个看上的领导，吃一顿饭，求个投靠呗。
或许，这个领导仅仅因为不明白才这样。谁又能样样精通呢？给他说明白，他或许就想通了。人是需要说服的。
假如你奔着和平友好的心态去，那么能够试试以下几点：
榜首，列出杂乱原因
既然你以为难以完结，那肯定是难以完结。详细哪里不好完结，你得说说。
记得刚作业时，我去找后端PK，我问他：“你这个接口怎么就难改了？你不改这个字段，咱们得多调好几个接口，而且还对应不起来！”
后端回复我：“首先，ES……；其次，mango……；最后，redis……”
我就像是被反复地往水缸中按，听得”呜噜呜噜“的，一片茫然。
尽管，我其时不明白后端，但我觉得他从气势上，就显得有道理。
到后来，仍是相同的场景。我变成了项目经理，有一个年青的后端也是这么回复我的。
我说：“首先，你不用……；其次，数据就没在……；最后，只需要操作……”。他听完，挠了挠头说，如同的确能够这么做。
所以，你要列出难以完结的地方。比方，没有老练的UI组件，需要自己从头写一个。又或许，某种特效，业界都没有，很难做到。再或许，某个接口定得太杂乱，循环调组数据，会产生什么样的问题。
假如他说“我看到某某软件便是这样”。
你能够说，自己仅仅一个初级前端，完结那些，得好多高级前端一起研讨才行。
假如你懂后端，能够做一下类比，比方哪些功用等同于多库多表查询、多线程并发问题等等，这能够辅佐他理解。不过，假如能到这一步，他的位子如同得换你来坐。
第二，给出代替计划
这个计划，适用于”我尽管做不了，但我能解决你的问题“。
就比方那个经典的打洞问题。需求是用电钻在墙上钻一个孔，我搞不定电钻，可是我用锤子和钉子，相同能搞出一个孔来。
假如，你遇到难以完结的需求。比方，让你画一个很有特征的扇形玫瑰图。你觉得不好完结，不用去诉苦UI，这只会激化问题。咱能够给他提供几个业界老练的组件。然后，告诉他，哪里能改，都能改什么（色彩、间距、字体……）。
咱们有些年青的程序员很直，遇到不顺心的工作就怼。像咱们大龄程序员就不这样。因为有房贷，上有老下有小。年龄大的程序员就想，到底是哪里不合适，我得怎样经过我的经验来促进这件事——这并不光彩，年青人就得有年青人的姿态。
第二招是给出代替计划。那样难以完结，你看这样行不行。
第三，车轮战，搞衬托
你或许遇到了一个硬茬。他便是不变通，他不想听，也不想懂，坚持“怎么完结我不论，明日之前要做完”。
那他或许有自己的压力，比方老板便是这么要求他的。他易手就来要求你。
你俩的条件或许是不相同。记住我一句话，没有一起条件，是不能做比照的。你是员工，他是领导，他不能要求你和他有相同的压力，这就像你不能要求，你和他有相同的待遇。多数PUA，便是拿不同的条件，去要求相同的成果。
那你就得开始为以后扯皮找衬托了。
假如你们组有多个前端，能够发动我们去进谏。
”张工啊，这个需求，的确不简单，不光是小刘，我看了，也觉得不好完结“
你一个人说了他不信，人多了或许就信了。
假如仍是不信。那没关系，已经将危险提前抛出了。
“这个需求，的确不好完结。非要这么完结，或许有危险。工期、测验、上线后的稳定性、用户体会等，都或许会呈现一些问题”
你要表现出为了项目忧虑，而不是不想做的姿态。假如，以后真发生了问题，你能够拿出“之前早就说过，多次反应，无人答理”这类的说辞。
”你居然不想着如何解决问题，反倒先想如何逃避责任？！“
因而说，这是下下策。不建议程序员玩带有心机的东西。
以上都是浅层次的解读。因为详细还需要结合每个公司，每个领导，每种局面。
总之，想要解决问题，就得想办法。
我是掘金@TF男孩，一个能够点播话题聊天的IT男。
