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

产品经理

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

交互/视觉设计师

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

后端开发

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

测试

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

对待变更

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

复盘

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

敌人 or 助手

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

成熟业务 vs 初创业务

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

总结

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