浅谈前端业务开发中的经验与感想

从事前端开发转眼已有三个半年头，我的技术能力提高的同时，业务经验也逐渐丰富。
回想初入职场，刚拿到设计稿时一脸忐忑，预估排期也不知定多少合适。以为产品设计的不合理，找产品经理 PK，却被简单说服，结果仍是栽倒了坑里。
随着一个个项目的开发、上线、总结，曾经摔过的坑，化为了本身避坑的方式（虽然仍是会掉进新坑），项目推动顺畅了许多。在带动我的开发效率提高的同时，也使项目及合做团队的成员愈加成熟，造成了双赢。
下面就先从前端开发与项目中各个角色成员的合做来谈起。

产品经理

产品经理一般是一个项目中，最早接触的角色。
产品经理一头对接需求方，一头对接实施方（设计/开发），将需求转化为一个个功能点，交给实施方来实现。
做为开发，常常会吐槽产品经理的设计天马行空、不明因此。出现这种状况的缘由，不少时候确实是因为产品经理对于需求的理解不足或多此一举。但大多数状况下，产品经理仍是发挥了很重要的做用的。这点，若是经历过没有产品经理项目的同窗应该会深有感触：直接的需求方，商务/销售/老板等提来的需求，每每须要通过屡次的“翻译”和确认才能真正知足需求。
印象比较深入的一次，是公司人事提过来的需求：给员工论坛增长邮件推送的功能。当时 hr 的需求只有一句话：“想要可以自动推送新帖和热门帖子，还能够手动指定推荐的帖子，最好能带图片。”
从中，须要本身提炼出这样 3 个需求：
一、自动推送新帖；
二、自动推送热帖；
三、可选项为推送推荐帖，而且要附上插图。
提炼了一遍以后，还须要再细化需求，好比热帖的时间范围，新帖和热帖的数量，以及插图来源和没有图的状况等等，这些都须要反复再跟需求方确认清楚。
因而可知，跟产品经理的对接，其实就是间接对接客户需求。若是不幸遇到了不靠谱的产品经理，要避免掉进坑里，就必须本身来帮助产品经理把需求弄清楚。方法也很简单，就是要多问：“想实现的功能是什么？”“为何要这个功能？”“客户的需求是什么？”等等。最后，再把完善的结果落入产品文档里，“互相留证”。
有时，产品经理还会承担一部分交互设计师的工做，画较为详细的原型稿。这时候，除了确认清楚需求外，最好再梳理个优先级。由于，一些比较精益求精的产品经理，会强调很多的细节功能，但每每不是来源于客户真正的需求，或至少优先级并不高。这时候，若是开发周期有限，能够考虑与产品经理协商，放在下一期迭代再作。

交互/视觉设计师

交互/视觉设计师根据产品经理设计的产品原型，设计并优化交互/细节，完善细节，极大提高了用户体验。
一般状况下，设计师对于交互和视觉自己是最专业的，除非你有足够的事实理论依据，不然不必就某一个交互或视觉设计与设计师争论不休，毕竟专业的人作专业的事。可是，在如下两点上，做为开发是须要着重关注的：
一、标准的一致性：因为种种缘由，如标准规范的缺失、文档的缺失、人员的水平差别、沟通不足等等，会形成同一项目不一样页面、甚至于同一页面的同一类功能，出现多种交互或者视觉样式。这不只会影响开发的效率，自己也会下降用户体验。做为开发，尤为是在前端组件化流行的当下，每每会比设计师对交互或视觉规范更熟悉。这时候就须要善于分析，某些功能模块是否相似，是否可使用同一种组件来实现。一旦判断能够，就要积极沟通，一般设计师是会愿意接受建议的。
二、通用性：这里的通用性，更多在组件设计中体现。好比，设计师对于不一样场景的布局，可能给出多套尺寸，这时候能够建议，统一采用栅格布局，并与设计师肯定几套栅格比。这样一来，就不须要再为不一样的场景，专门编写几种宽度数值了。
此外，在与设计师、包括产品经理讨论某个设计或功能点时，应当先从合理性角度分析，好比对于原始需求是否必要？是否存在过分设计？是否存在功能点的重复？切忌一会儿从技术实现角度出发，每每会形成很多的无谓争论，好比那句经典口头禅：“这个需求很简单，怎么实现我无论”。
只有当一个功能肯定是须要的时候，才须要加入项目进度因素。这时候能够考虑或是技术实现困难须要延长开发周期，或是采用某些快捷实现方案，与设计师协商，略微调整设计。
固然，不是全部的项目都配备有交互/视觉设计师。对于没有设计师的项目，一方面，借助现有组件的拼装，基本不须要太多的样式设计；另外一方面，做为前端工程师，理应具有必定审美能力的，尤为是设计并编写一些交互动画的能力。因此不管有没有设计师，均可以在细节上作一些小的“自由发挥”，以提高最终用户体验。

后端开发

在目前采用较多的先后端分离模式下，项目有一个很重要的环节，即先后端联调。
虽然同为开发，但由于关注点的不一样，常常也会形成互相伤害的局面。对于前端来讲，一般因为如下几点：
一、接口前端不友好，好比返回值的数据结构嵌套很深，或者须要屡次请求后前端组装数据；
二、前端实现 vs 后端实现，好比分页、过滤、数值的计算等；
三、规范问题，如接口字段命名的一致性、是否符合同一命名标准、报错格式等；
四、缺乏详细的 API 文档说明；
五、后端服务不稳定，或 BUG 太多。
对于这些问题，一方面，能够经过技术手段来解决。好比，构建一套 API 管理系统，按规范定义 API，而且约束 API 开发者必须按照固定格式编写详细的文档才能发布 API；同时，提供测试环境，供后端自测；或是前端部署 BFF 层，合并 API 等等。
另外一方面，在遇到分歧时，前端开发者须要坚持几点原则：
一、后端 API 应尽量不依赖于特定的前端界面。这不只有利于 API 的复用性，也可避免前端太重的逻辑影响页面性能；
二、单点维护原则：有时候，确实有些逻辑或功能，放在先后端来作皆可，好比错误提示的翻译。这时候，秉持在一处维护的原则便可，而不是各自维护一套；
三、用户优先原则：后端在定义 API 时，更多的会考虑原子性；而前端是直接面对用户的，须要更多考虑用户体验。但无论前端仍是后端，最终都是服务于用户的。因此，对于一些可能会影响用户体验的 API，要坚持用户优先，甚至能够拉上交互/设计同窗，来推进问题的解决。
此外，不少时候，前端做为项目路径的下游，每每比较的被动。这时候，须要学会去化被动为主动。好比，采起一些技术手段，如 mock 数据减小对后端开发进度的依赖。
除了技术手段外，沟通问题的过程当中，应该抱着共同寻找解决方案的心态，与后端一块儿分析问题并找出最佳方案，这样才有利于项目快速良好地推动。

测试

联调完成后，一般须要提测，进入项目上线前的测试阶段。
进入这一环节，可能会被搞得特别郁闷：本身认为已经完善了的系统，仍是被抓出了很多的 BUG。
若是仅此而已，那其实还好，毕竟是本身的问题。但有时候，依据测试人员的不一样，还会遇到不少意外状况。
就我经历过的测试而言，发现测试人员大体可分为两类：
一、经验丰富的测试，能快速定位问题，而且较为准确的指给责任方，此外还会提一些交互或功能优化建议；
二、新手测试，不清楚问题缘由，基本都先提给前端，或者对产品设计理解不够清楚，提一些无效 BUG；
前者还好，除了会提一些你认为是新 Feature 的 BUG 让你来改；然后者，就须要有足够的耐心了。
可是，咱们能够换个角度来思考。第二种状况的测试，其实更接近真实用户在使用系统时的场景。与其不耐烦地强调是否是 BUG，不如思考一下，是否这部分的功能设计还须要优化？是否是会给真实用户带来困扰？甚至能够主动拉上产品经理，看看是否须要调整产品设计，或是做为需求下期迭代实现。这样一来，无形中，你就成为了项目优化的推进者。
此外，对于测试提过来的问题，若是发现不是本身的 BUG，也不要简单地推掉。帮助测试拉相关方一道讨论，能够更高效地解决问题。

对待变动

“变动”对于开发者来讲是最头疼不过的一件事了，每每一个看似很小的变动，可能牵扯出不少关联问题，大大影响开发效率。
然而，现实状况是，不管是需求方、产品经理、交互/视觉设计师，甚至后端开发均可能提出变动。
有些变动“看似”不可避免，好比开发途中收到用户反馈，但愿增长某个功能；
有些变动看似没必要要，却又被强烈坚持，好比上线前，交互设计师以为某个按钮位置不合适，须要调整。
不少时候，看似不可避免的需求变动，每每能够在产品设计中来避免，或者采起更好的方式来解决，如放在下一期迭代。看似没必要要的功能，也不是说必定不能增长。我认为，关键须要作好几点；
第一，作好变动带来的影响范围的评估。对于一些大型的系统，产品设计上的一点小变动，可能会牵一发而动全身，特别是一些公共模块，好比计费。一些小变动，若是不作好范围评估，可能对其余模块产生影响，甚至是不可用；
第二，评估好所需时间。一般，一个项目的上线节点是肯定的。或者，会严格制定提测的时间，测试也会有本身的排期。一旦某一需求点变动，没有评估好时间，万一形成了延期，将会对整个项目的进度带来影响；
第三，要权衡收益与时间。咱们不该该刻板坚持说，需求开始已经定好了，这版任何需求变动我都不接受。毕竟，多数的变动，仍是从优化产品的角度出发的。若是评估一个变动对上线时间没有什么影响，彻底能够顺手改掉。但若是某个变动，多是客户直接要求的，看似非改不可，但修改起来须要大大延长项目周期，这时候就须要作个权衡了，或是调整人力资源，或是调整技术方案。
总之，对待变动，不是一味地拒绝，也不是轻易地接受，须要充分权衡利弊收益，作出合理判断。

复盘

“复盘”一词最初来源于围棋比赛，指一局棋局结束后，复演该局，分析整盘的胜负所在。
对于一些大型项目，项目的结束作一下复盘，能够总结一些问题或经验，用来提高后续项目的效率。因此，进行复盘是颇有必要的。
好比，我接手过一个项目，项目的前期，产品经理提供的文档很是简洁（只有一页），但项目逻辑远比文档描述来的复杂。这致使，整个开发过程当中，须要屡次跟产品经理沟通确认需求。除此以外，在项目中途，视觉设计师还作了好几处视觉上的调整，以致于整个项目时间远比预估来得紧张。
对于这个项目，当时作了一个复盘。复盘前，专门统计了一些数据做为依据，好比产品文档变动次数，设计稿变更点的数目等等。在会议中，秉持对事不对人的态度，列举事实依据指出影响项目效率的缘由，并提出优化方案，如产品经理须要在项目开发前，准备好足够完善的文档；视觉设计师的视觉稿完成后，须要组织评审，尽量避免在开发后，再作调整。
经过优化方案的沉淀与推动实施，成功确保了后续项目，再也不遇到相同的问题，从而提高了效率。

敌人 or 助手

我作的项目是谁的项目？
在我刚开始工做的一段时间，对于接手的项目，个人理解，它们纯粹就是一个个任务。我须要考虑的，只是如何用代码去实现它们。
但在如今，我会意识到，我最早考虑的，不是如何实现，而是为何要作这个项目？具体来讲，就是项目的需求自己为了解决什么问题？能带来什么收益？进而思考，产品的设计方案是否知足需求自己？是不是最佳的方案？是否会形成一些问题？
换言之，在项目中，应当把本身看待成一个项目 owner，而再也不仅仅是一个执行者。个人合做方，包括产品经理、设计师、后端开发、测试都是个人助手，帮助我一块儿把这个项目作好并推进它成功上线。固然，前提是，你须要主动去充分理解并承认这个项目，使它真正成为“个人项目”。
这样一来，合做中遇到问题时，我会以对于项目积极的方向去努力，而不只仅知足于完成本身部分的工做。好比，后端某个接口有问题，除了反馈给后端外，若是根据本身的经验作个判断，是否是 API GATEWAY 的问题，或者是否是某个字段取值不对之类的，能够帮助后端更快解决问题。这不只有利于项目的总体进度，也能下降一个沟通成本，毕竟若是本身不提供足够的信息和建议，可能反而增长了沟通的频率，对本身的开发效率也会形成影响。
总之，记住一点，合做方不是敌人，是个人助手，咱们是为了相同目标，通力合做的伙伴。

成熟业务 vs 初创业务

在我经历过的全部项目中，既有比较成熟的产品业务，也有初创的产品业务，它们的整个开发过程，仍是有比较大的不一样的。
对于成熟的产品业务，整个项目流程和角色分工，基本是比较完备的。可是，这并不表明开发过程必定顺风顺水。由于，一些既定的流程未必获得严格执行，或者某个角色专业度不足。这种时候，就须要对照前面提到的，与各个角色合做的方式。
某些状况下，还会存在合做方自身存在一些问题，好比工做态度、负责程度等。这时候，可能就不是靠一己之力能够解决的了，而是须要记录相关过程，并及时将问题反馈至上级来解决。
相比成熟业务，初创业务每每更关注“速度”。由于初创业务极可能处于市场探索期，须要快速完成产品推广市场；同时又要及时迭代，知足客户各类需求。这种状况下，整个研发流程或是角色分工，不必定会很完备。好比，不必定有专职测试，可能会由产品经理兼职；又或者，不必定有设计师，可能须要咱们前端利用现成组件加一点审美能力自由发挥。显然，这种时候，想要事先制定一个严格完备的研发流程，每每不太现实。
那么如何在这种条件下，确保开发效率呢？我认为，须要作到如下几点：
第1、借助技术手段。好比，最经常使用的 mock 数据，实现先后端开发时间上的解耦。
相比成熟业务，初创业务可能缺乏不少基础设施，这就须要多作一些工程化的工做优化工做流，下降沟通成本。
技术手段还体如今，借助一些现成的脚手架工具或完善的框架来快速搭建项目，如dva。
第2、须要提升项目管理能力。最基本的一点，是要会评估需求优先级。
对于前端开发来讲，实现的功能中，除了调用后端 API 来实现的基本功能外，很大一部分是提高用户友好度的工做。对于初创业务，这一部分的弹性实际上是比较大的。相比成熟业务，初创业务、特别是技术型的初创业务，用户对体验上的问题，容忍度相对是比较高的。因此，在项目时间比较紧张的时候，合理评估需求优先级，合理安排研发时间，对于确保项目如期上线相当重要。
第3、要少抱怨、多建议。
初创业务毕竟要同时面对项目周期紧、规范流程不完备、基础设施缺少等不利因素，天然会遇到不少问题。这时候，不能只作问题的发现者，而是尽量成为问题的解决者，至少也是问题的推进解决者，才有利于整个团队和项目。

总结

程序员常常用搬砖来自嘲，其实软件工程和土木工程都做为工程，确实有一些能够类比的地方：
若是我只关注我被派到的活自己，好比搬砖、砌砖，一旦整个设计、或某个环节出了差错，即使个人活作得再好，整个工期仍是会受影响，甚至会推倒我砌的完美的墙从新盖；
若是我把眼光放大，了解我砌的墙在整栋楼中起得做用，我可能会发现，这墙设计的不够厚，我多砌一层，可能就避免了一次返工；
若是把眼光再放大，可能还会发现，砖摆放位置太远，运砖上花了不少时间；设计图纸不够清晰，老是容易看错...
对于项目开发过程当中，或多或少存在流程、人员、规范等等各方面的问题，这时候须要主观能动性，去打破这些问题，而非选择无视和忍受。告诉本身，我是要把整个项目作好，而不是仅仅把本身的手头任务作好，由此一来，遇到相应问题，天然会想办法推进解决。这样不只有利于项目，就我的来讲，不也是一种能力的提高吗？