有人说产品开发过程中web前端没有结论，只有随需求不停的修改，但是项目必须要有阶段性的结论，作为一个前端开发，如何避免为了某一个需求而陷入反复更改的困境呢？不要把责任全部推到产品不断的需求更改或者设计不停的视觉调整上，你其实可以做得更好。在不断的追求新技术，打磨技术精益求精之时，拓宽自己的知识面，寻找正确了工作姿势也很重要。

首先，心态很重要。

如果你期望你的工作状态是这样：产品经理把一个功能需求的每一个环节都考虑周到，每一个细节点的覆盖全面，每一个想法都表达完美（当然，这是一个好的产品经理应该追求并达到的），交互和视觉能够以用户体验和美学的角度完美的诠释产品的需求点，然后将所有需求的前期沟通准备都ready，给到开发开始投入生产，然后你作为一个前端开发，与后台一起合作，逐个的还原产品需求文档所描述的功能与细节，偶然在作为一个开发的同时，也作为一个用户向产品提出一些逻辑不合理的点，沟通敲定，最后开发完毕，产品视觉体验觉得OK，可以上线。

那在工作的前几年，你过的一定很烦恼，因为你可能总是在纠结这些问题：

1、按照产品的需求单实现功能点后，产品经理体验发现整体的流程逻辑跑起来太繁琐，改！

2、视觉走查发现页面按照视觉稿给定的尺寸在不同的屏幕尺寸上并不协调，改！

3、交互发现按照产品的逻辑更改后，整个交互变得并不友好，需要重新调整交互方案，不爽，改！

.....

所以你发现，作为一个前端开发，在这一个需求上，完成你的开发量后，你又得大改！并且你还得告诉自己，一切以产品的完美为依托，在发现有问题的时候，就是得尽力配合改动。

但你内心还一定有点小抱怨，产品经理需求还没想好就开始投入设计和开发，交互设计不完善的问题设计人员竟然在设计过程中没有发现，是他们的不专业影响了开发进度。

如果一直以这种角度思考问题，作为一个完全可以被代替的代码搬运工，还期待着身边的搭档完美解决所有的问题，你只能在抱怨中毫无作为，不要忘记自己是在一个团队中，如何更有效率的帮助团队完成目标，如何自主的把控节奏很重要。

产品经理在对着一个生动的页面时的想法远比在对着脑中或者文档上描述的功能点时更丰富，而前端开发对一个产品细节的包括是最全面的。所以，作为一个前端开发，你可以做的更多。

在产品宣讲的前期，根据以往开发的经验，你可以更多的提出产品所遗落的细节，而这些细节的补充可以让交互视觉在设计时更全面。而在开发过程中，你会跟你所开发的产品进行一次全面深入的对话，每一个按钮，每一块信息的表达，每种用户操作所对应的反馈，你的程序都必须覆盖到，所以及时的更产品视觉一起沟通这些反馈的表现形式，是否需要调整，以避免在开发完成后的二次变更。在开发的组件设计阶段，如何合理封装组件逻辑、适度的预留弹性入口，也极为重要，我的看法是组件化不仅仅是为了开发人员的代码复用，也为了页面模块的快速调整修改。

这些注意点作为一个稍微有经验的前端开发，可能都有自己的一套实行方式，但如何在团队合作时落实的更好，效率更高呢。有人说开发人员改行做产品经理有优势，因为有比较严谨的产品逻辑思维，但是我觉得产品经理，设计，开发人员三者应该是互通的，产品经理当然是更注重产品的思维和了解市场，但也需要有良好的逻辑思维，了解基本的视觉规范。而设计人员，尤其是交互设计，需要更了解用户体验规则，有好的审美，但是也需要了解产品的基本要素，了解开发的复杂度。所以开发人员，在不断最求精益求精的技术时，也应该不断增强自己的产品思维，只有了解真正的产品需求，才能在开发前或者开发中发现潜在问题，只有懂得设计的基本原则，才能在合理与不合理中抛出可能的风险，提前调整方案。

产品思维

当产品经理为了一个用户点击行为而列出不下五六种相应的响应模式时，跟你谈到用户行为引导和用户转化，请理解其合理性，甚至给出更多的细节确认会让后期的开发更有效率，网上有很多产品思维类的书籍和研究，广泛涉猎更有助于培养自己的见解。

一个产品经理好友推荐的一些书籍有空可以慢慢读一下：

《Free》

《结网》

《启示录》

《简约至上》

设计的基本原则

不要再纠结1px的问题，抱怨设计的眼睛为何如此毒辣，为何你看起来毫无差别完全按照设计稿实现的东西，能被挑出那么多的问题。同时，从移动端iphone4的尺寸到google nexus6，从12寸到29寸的显示屏，一份静态的设计稿大多数情况下都不能覆盖到所有的显示屏尺寸，作为最接近产品产出的开发人员，你需要和设计沟通给出最合理的兼容方案。

收集的网上评价比较适合入门级别理解的设计书籍：

《The Design of Everyday Things 》

《破茧成蝶-用户体验设计师》

《众妙之门——网站UI设计之道》

《写给大家看的设计书》

组件化思维

前面说的两点都需要日常生活中慢慢积累理解，现在要谈的我们前端开发熟悉的点了，组件化思维。这里不是要谈前端的组件化方案，而是组件设计的出发点。

1、养成代码组件化的习惯，它会使你页面模块的添加、删除、更改变得更优雅，而管理和阅读也会更舒心。

2、收拢参数入口，保持可扩展性，在设计组件时，不可能把所有的可能性变动都设计并实现，但组件如果要复用，日后变更或者添加新功能是必然的，所以保持良好的可扩展性非常重要，如果每次的修改都要花大量的经历在向前兼容确认上，就失去的组件化的意义。

3、代码文档化，组件维护不是一件容易事，代码形成文档化的风格后，本身就是一种自规范，不同的人修改或者使用代码时，不需要额外的规范文档就能合理遵循组件规范。

4、合理控制组件粒度，根据业务需求衡量组件复杂度与修改复用程度的性价比。