本人有五年前台开发经验，2年后台开发经验，实际上我觉得后台可能比前台还要容易，在不考虑比较深的技术壁垒的情况下，前台有原型图，我需要百分百还原，再加上画面特效，用户 *** 作特效等挺麻烦的，有时候一个小小的点卡半天很正常，只要不是特别简单的需求，说随便两个小时搞好的我是不怎么相信的。转后台之前，本来以为很难，结果后台写起来真的就是好快，我经常做到无聊到没事做把人家的活揽过来一起做，后来还是前后台一起搞了，后台框架搭好以后，剩下的只是业务接口实现而已。总的来说，前台入手容易精通难，后台更多偏向框架的灵活使用。不要瞧不起前台，特别是某些后来开发人员觉得不就是写个界面么？但我想说界面的逻辑不比后台简单，前几年曾经去参加一个公司的面试，以后后开发人员跟我在那装，一个劲的说就是前台而已，很简单的事情，说了好多次，把我说烦了，我就跟他探讨前后台，屁都不懂的面试官，就一新生蛋子，最后我说你公司连面试官都这水平，与我期望不符合，要过来简历就撤了，带着有色眼镜看待技术的人一般都是那种一知半解，一瓶子不满，半瓶子晃悠的人
我就是做前端开发十年了，其实你这个问题在职场中普遍存在。就像以前我认为，后端不就写写接口，一个接口10几分钟的事情，墨迹个半天没出来一样，总是很埋怨，其实你真正去实 *** 的时候，发现并没有这么简单，细节的东西特别多。
前端说需要两天时间，可能考虑某些改动涉及会影响到其它功能方面的问题，都需要测试评估，并且前端的开发，比后端还多了界面这一块开发的时间，这界面调试往往最费时间，这是很多后端开发人员没有考虑到的。
总之，前端评估可能是一个相对宽泛并且预留了一定空间的时间，也许他能答应2小时做完，但能保证真的做好了吗，没有隐患问题存在，这些都是要考虑的，毕竟前端一发布出去就不好在升级版本改动了，这也就是他和你评估时间存在较大差异的一个重要原因吧！
图一，安装完oracle,sql,db,mysql后，负责数据库开库的叫做底层，
图二，负责浏览器视窗页面上能看见的什么东西的一律叫前端。
图三，负责整个视窗界面看起来很舒服，给人留下深刻印象的我们一般叫他们ui.
项目经理拿到项目，会给底层大致讲解一下，然后底层会根据讲解开库做系统，然后给前端代码。前端拿到代码写入页面然后整个系统大致完成，接着ui介入，ui根据客户需求制定界面，再转回前端，双方共同负责界面达成。接着就轮到测试上场了。一般测试的外号文雅点叫清道夫，难听点叫擦屁股的。然后高端大气上档次的就是全栈工程师了。在测试过程中负责整个系统测试，运行，并找出各个部位的bug,并修复它，然后写出报告，报告将直接提交人事或者财务，根据描述部位对相应人员做出处罚。
这就是软件设计部门的整个工作流程。所以，你说后台开发对前端有疑问，就有点纳闷。前端有问题，和你后台开发什么关系？
至于什么后台开发。。。。。好像外包公司起这名的比较多。
首先问题要分几面来看。
会者不难，难者不会。
要看别人的具体经验，具体技术水平。
每个人做同一件事花的时间是不一样的，不要把自己的想法强加给别人。
如果别人认为你应该怎么怎么样，你也会反感。
而且前端要2天，项目经理能给，就说明前端说的在理。
如果你觉得2小时可以干完，说明你能力强，但作为同事，还是要善良一些，你总不能有活就帮他干。
也许他干几次之后，效率就上来了，从两天变一天，再变成2小时呢。
人是要进步的，是要学习的。
多站在对方的角度思考问题，也许你就有一个不一样的答案。
最后祝工作开心顺利！
在工作中遇到这种人很正常，这种人就是大家口中的“磨洋工”。
有些人认为前端和后端不一样，后端改个需求可能一个小时就可以搞定，前端复杂，需要一天或者更长时间，这完全是胡扯，是消极工作的一种变现。有些程序员就是喜欢将工作难度夸大，明明一个小时的工作量，他非的要评估一天的工作量。这对于非技术人员可能感觉不到，但是对于一起开发的技术人员来说，一眼就能看透工作量，只是同为同事，大家不好说破而已。
三天100行代码的奇葩同事曾经碰到过一个前端同事，技术很一般，分配给的任务，不管是小到一个css样式的调整还是一个完整的功能模块，让他评估时间，最少需要一天。曾经有一次一个简单。需求评估，后端同学评估只需要半天时间，他的前端竟然需要三天时间，让他说出具体工作的难度在哪里，他却支支吾吾说不出来。这三天的时间我时不时观察他，发现他一天大半的时间都在浏览网页，要不就是微信群各种聊。三天过去了，我去看了一下他提交的代码行数，不到100行！三天时间写了不到100行代码！
所以，有些程序员就喜欢磨洋工，当然，也有可能是考虑的比较全面，追求代码质量。 如果碰到这种情况，只要他评估的时间在产品可以接受的时间范围内，那你也就无所谓。如果你是一位研发负责人，请他将工作进行拆分评估，具体到功能点的时间，看他这两天时间是如何分配的？炸一炸他，他总能露出破绽。
首先，个人不太理解，为什么一个后端开发的程序员需要控制前端程序员的开发时间？不管前端需要多少时间，到底是2小时还是2天，这个不应该是由产品经理或者项目负责人来控制的么？
有时候不在其位不谋其政，作为后端程序员可以提出自己的疑问，但是到底如何布置任务和排期，还是交给负责人来协调吧。程序员之间没有必要相互对立，特别还是因为一个自己并不擅长的领域相互产生矛盾。
当然，如果你自己除了是后端开发外，还兼职了项目负责人，那确实可以对前端的研发时间进行评审。如果你和前端对于某个功能的时间评估上出现分歧，那么可以采用以下这些方法。
可以考虑“功能点分析”让前端把功能分解若干个功能点，然后对每个功能点都采用乐观时间进行评估，最后汇总后在增加30%的Buffer。
例如：我现在要做一个订单页面，这个订单页面有查看订单列表、查看订单详情、取消订单、确认收货、评价几个功能。
画一个思维导图，然后每个功能再往下分解。查看订单列表包括了ajax请求api获取数据，组装table，css考虑已有框架的样式复用，不另算时间；详情页的话，也包括了ajax请求api，页面的html和css等等等等（细分的力度自己掌握）。
最后，所有的功能点被一一列举出来以后，就挨个分析，哪个哪个需要几个小时，最终就可以汇总出时间了。这里可能需要注意一下，单一的功能点，其实大致已经可以评估得到代码量了，只要不是特别复杂的算法类功能点，大部分都可以把时间精确到小时甚至0.5小时。而且，这里我们采用乐观评估的方法，就是说，大家别去想这个功能可能有坑，可能如何如何。最后汇总时间后，给予总体的Buffer量来抵御风险。
当然，也可以使用“对照分析”的方法我们可以考虑对照曾经做过的类似功能或类似优化，当时的那个功能花费了多少时间，而这次相比上次的差异是哪些？是会花费更多时间，还是更少时间。这样，就能够得到一个大致的完成时间了。
这种评估方式，就只是针对于当前的功能曾经有过经验，时间上有参考价值的情况下。不能把完全不相干的两个功能拿来类比。而我们在评估的时候，就只需要考虑差异部分的评估，大大的减少需要评估的内容。
最后，就是“专家评估”了如果你对于前端确实也比较了解，自己完全能够独立完成这个工作任务，时间花费可以测算的话，你其实就可以作为一个“专家”的角色了。那么，你评估的时间就是大家必须要遵循的时间。当然，这种方式需要你有绝对的权威性，不然就是 搞笑 。
不管使用什么方式，对于分歧问题的处理其实都比较机械，并不是非常的利于团结，最好的方法还是大家商商量量的把事情给解决了。
这个问题需要多纬度去分析：
其实本质就是要么你判断错误，要么是你同事判断错误。
无论是你对还是你错，这工作都是由别的同事来完成的，你没必要太过于关心，你没必要太过于在意。
但是，假如这个工作和你的工作有关联，这个工作的完成时间，完成质量，会影响到你的工作进展与工作质量，那么你必须要恰当的参与进去，你需要：
这个很重要，同事之间工作上的沟通交流还是必须的，交流内容可以由浅入深，先从你认为只需要2小时就完成的工作谈起，然后逐渐深入进去，多听听同事的解释，当然你也可以发表你的意见。互相理解，互相体谅，互相帮助，最好能达成一致。
如果工作非常紧急，你这个同事也不配合你，那你只能请领导出面进行协调。当然，你要有理有据，只针对工作不要针对人。
最后建议：
如果不是领导，那么就不要参与不要议论别人的工作。
如果没得到允许，那么就不要参与不要议论别人的工作。
这个我倒是有心得可以分享。其实如果做程序员的或多或少都会遇到这样的现象，要不你就是问题中的后台开发，要不就是改东西需要两天的前端。我觉得都很正常啊，毕竟你不是对方，你也不知道对方有什么想法和困难。
像产品给个需求给到开发，一般说改这个东西要多久，开发看了下进度表，思考了一会后给了个时间点，这时候一般产品不会多问，因为他不知道实际开发难度，而且他也不知道开发的其他需求进度，所以不敢多说，反正开发给了排期，在合适的项目进度内也就ok。
但如果是开发对开发，那就出现问这个问题的情形，开发A要给开发B提个需求，然后开发A实际内心有个预期感觉这个需求能在其他事情不干扰下多久完成。注意！是其他事情不干扰下的情况，其次，这是开发A按自己的能力评估，不是按开发B的能力评估的，而且这种事情一般不是遇到自己，便潜意识就把需求想得比较简单，毕竟大家都容易“宽于待己，严于待人“。
在这种前提下，实际开发B可能本身就有其他优先级高的需求要做，其次这件事情可能牵涉到系统内部其他需要修改的地方，会牵一发而动全身，不是后端想象修改单个页面就可以完成的那么简单。
所以这种情况开发A说的2个小时是一种自我想象的事情，要不等前端找后台开发说，这个需求最多就2个小时就可以完成，就改个接口，新增这些数据POST出来就行，那我估计这个问题转换下角色我又可以再回答一次了哈哈。
对于一个技术团队来说，配合默契是非常重要的，特别是前端和后端人员，如何做到默契，需要三点：
一、前端要懂后端，后端要懂前端，只要这样，大家才能无缝对接；
二、对工作的重视，无论你负责哪个环节，只要有这个态度，项目会顺利的进行下去；
三、同事之间的关系，这很重要，千万不要有互相拆台的行为：这其中有个人的人品问题，也有个人交际情商问题，这个比较难以处理。
回到你的问题，你认为2小时的工作量，但你同事却说需要两天，这种矛盾的可能性比较多，但不管是什么情况，你都要本着和同事维护好关系为基础，要主动理解同事，哪怕他说的是错的，你就会释然了。
你两小时能完成人家两天的工作量，产出是人家八倍！！！那你是不是可以跟你的领导建议下，把前端的任务交给你，让老板给你开这个前端双倍的工资，你承诺产出比现在的前端多4倍，然后你每天只要干4小时活就能完成任务。
多赢局面啊：
1、服务端工资再高也不可能比前端两倍还多，现在前端都不便宜！你大幅涨薪了，而且每天工作时间少一半，你赚大了；
2、老板少花了一半的钱、产出却扩大了一倍，老板赚大了；
3、那个可怜的前端可以让他滚蛋了…
希望这个办法能让你们公司长命百岁
程序员首先是雇员、然后是工程师；比起创造力，工程能力对这个职位更为重要为什么有人在技术造神
大家应该已经感受到，技术圈这两年已经和娱乐圈创业圈差不多的氛围了，这其实是有原因的。
最主要的原因是，创业公司和创业媒体越来越多，他们需要大量的程序员投身到创业这个高风险的行业中，而造神，正是让程序员们自动跳进火坑的绝佳办法。不是说程序员不能创业，我是说，创业媒体们故意模糊了创造和创业的界限，把程序员们的创造冲动偷换概念，鼓吹了太多不适合的人去创业。
另一个原因是，招聘成本高涨，CTO 们为了能提升影响力，不得不频频出席各种大会刷脸。文笔好的再做做自媒体和技术社群，既能强化个人品牌提高身价，又能在融资的时候提升成功率。
总之，这个行业出现了各种技术大神。
这些大神在普通人类和初级程序员眼里是无所不能的，是他们向往的目标；在中级程序员和高级程序员眼里，这些大神就是他自己，只不过他还没红起来而已…
于是攀比心理也开始泛滥，全国第三的架构师比比皆是，整个圈子渐渐就浮躁起来。
然而绝大部分程序员，依然是雇员
媒体们在包装时，最喜欢按独立开发者的路线来整。「从小就对技术有天分」、「大学时曾在某编程大赛一鸣惊人」、「写了个 APP 玩结果一个月有了千万用户」、「从公司离职自立门户三年上市」。
OK，这的确是程序员的一条职业路线图。但是媒体们不愿意告诉你的是，一：只有极少数程序员是通过这个路线成功的；二：这条线其实需要太多非程序员职位的技能，比如产品设计能力和销售能力。
程序员的四大职业象限
这件事造成了两个结果，一是冲动点的程序员跑去创业了，二是不那么冲动的程序员天天觉得自己能创业，能干大事，在现在公司屈才了。于是就有了这样的画面：雇员们天天抱怨雇主不能提供给他们高管或者独立开发者级别的待遇。
如果不是你自己开的公司，那么雇员同学，你的价值是由你对公司的贡献来决定的。
程序员的价值决定
绝大部分互联网公司的程序员职位，没有技术门槛
然而不幸的是，绝大部分互联网公司都不是技术驱动的公司。真的就是鸟哥说的那样，绝大部分技术岗位，其实技术门槛都不高（门槛在工程上，后文细讲）。技术不过是这些公司的护航舰，而不是破冰船。
先别打我，冷静下来想想，到底有多少你会的那些技术，是你的同行们不会的呢？不多，对吧？
几年前亿级别的搜索还是问题，现在已经到处是通用解决方案了；几年前千万到亿级别的网站和 APP 解决方案还在大公司手里，现在各个架构大会都讲烂啦，而且其实都差不多；就连 DeepLearning，带 API 接口的框架也开始涌现，只需要把图片用 REST 传进去就能取到结果了。
很多事情，已经没有难度，只需要持续投入。是的，对绝大部分程序员来讲，他们不需要成为科学家，而需要成为工程师，成为从科学家手里接过火种，去燎原大地的人。
怎样才是一个好工程师
工程的本质不是创造，而是去风险化。
工程是关于如何低成本、高效率、按时按量完成既定任务的。所以判断一个工程师是否优秀，并不是他多有创意多有名气，而是看他有多稳，看他能多 GettingThingsDone，中文就是「靠谱」。
有时候一个好的解决方案，未必采用了最新的技术和框架，而是看上去朴实无华，功力都包涵在背后的细节里。就像顶尖高手打的斯洛克台球，每一杆都平淡无奇，只是因为上一杆的回球太到位。
有同学问，那我工程做的太好，岂不是没有机会遇到一些高难度挑战了么？放心，一般公司都雇佣了产品经理来帮你制造高危事件。
同样的，一个好的工程师，会选择最适合需求和团队的方案，考虑开发效率和系统效率的均衡，从而已达到最优效果；而不是整天和别人去争论什么语言最好、哪些框架过时了。
工程的另一个要求是进度控制和质量控制。
在项目立项之后动工之前，对要做的事项作出详尽的规划，对未来一到两周的工作给出细致的排期，这是进度控制的基础。
代码的及时入库与合并，自动化测试和每日构建，CodeReview 和文档编写，这些看似无关紧要的习惯则决定了项目质量。
不幸的是，很多程序员把这些工程上至关重要的东西当成垃圾，视为对他们「创造力」的压抑。
他们总是以创造力为借口去寻求自身的自在，比如上班不带胸牌不打卡，中午休息时间在公司看视频打游戏，最好可以远程上班，项目到期之前再来检查进度，公司不要用统一框架，只有傻逼才写文档。
对职业的理解偏差和工程能力上的荒芜，培养了大批能写代码但死活写不好代码的「码农」，反而让那些有着彪悍工程能力和良好习惯的程序员变得奇货可居。
最后，来说说程序员那无处安放的创造力
有了锤子想找钉子是很正常的原始冲动，但我们必须认识到，创造力对于程序员这个职业来讲，是锦上添花的东西。如果你没有强大的工程能力，那么创造力也不过是无本之木。所以扎扎实实的把工程基础打好，这是最根本的。
在此基础上，我比较推荐程序员采用内外两条线来培养自己。在公司内的项目上采取相对保守的策略，尽力把稳定性做到最好，培养出自己卓越的工程能力；然后在公司外的开源项目和自己的独立项目上，采用一些新的技术、实践一些新的想法、充分发挥自己的创造力，梦想还是要有的，对吧。
这样做最明显的好处是，你可以了解到新技术和激进方案的优缺点，从而在进行方案选型时，有更多的依据；还有一个职业发展上的好处：如果不是主负责人，公司的项目往往不能代表你的能力；但独立项目却可以作为一个非常好的能力证明出现在你的简历里边。
你可以是一个身怀绝技的手艺人，在自己家里你尝试各种手法各种风格的个人作品；但当你参与颐和园这种级别的工程时，好好的把自己负责的石头雕成总设计师要求的样子就好 —— 毕竟这个时代一个人已经很难负责整个项目了。这就是我所理解的程序员的工匠精神。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）