前段时间与后台合作参与完整的网站项目开发，从设计图的还原到黑盒测试，这段实战经历，让我成长不少，一个是与客户沟通出现的偏差导致开发浪费很多时间，一个是实战中的解决方案最佳选择问题。
从开发的第一期界面框图还原到第二期第三期界面大改，让我越发后悔，为什么没有预料到会复用和重用很多组件，由于React还没有入门，所以在这次开发中没有使用React，只是在bootstrap的基础上进行二次开发，而代码管理不当，使得复用率并不高。
第一次实战开发嘛，在所难免，我这样安慰自己，本着锻炼的想法，还是要把实际开发中一些关键问题记录下来：

• 1.设计图的还原中，首先要仔细观察所有设计图界面，记录相同的组件，每一种只要写一个，要注意耦合性，要适用大部分环境，比如说一个搜索栏，写完后放在哪里都没问题，且可以很轻松的调整大小等，说到底，就是在原有框架（bootstrap）上，写好一个能够适应本项目的复用组件；每个组件耦合性降低的过程可能要花费多出不止一倍的时间，但是等组件都写好，再拼接，就会非常快，我就是因为前期太着急，导致后面注册登陆页面（因为写了很多JS验证）而连个布局都不敢改，浪费了很多时间，如果前面慢慢来，后面反而会快很多，也就是俗话说“慢慢来，才能快一点。”
• 2.第一条其实讲的是界面开发的一种设计，其实我理解为一种架构，和整个项目的架构是同一种理念，但是逻辑要复杂的多，这是我从后端程序员身上看出的，整个项目在写代码前，一定要设计好逻辑结构，逻辑出一点点差错，后面将花费n倍时间去修改，而且很可能修改不了，后端的架构比前端更为重要，而我虽然只是实现设计图的还原，但是搞清楚整个项目的业务流程，对界面还原也会极有帮助，这一点要谨记，毕竟搞清楚业务流程不是一件简单的事（很多时候客户自己都搞不清），这时候要确定好每个页面的交互规则，比如，我点完这个按钮会出现什么？这个页面有几种跳转，几种切换方式等等，确定好可以和客户或者设计师一起商量，等大家统一好，再开始部署代码，这样就不会出现每个人心中的产品差别很大的情况，因为产品还在脑子里，没有实现呢。
• 3.前面说的都是整体，现在说细节，我发现在实战中真的会遇到平时玩遇不到的情况，代码的可拓展性和可维护性确实重要，这次项目中，客户界面有两次比较大的改动（当然也怪我们前期没跟他说明白），每次大改布局都让我生不如死，因为我的代码写的太糟了，根本不考虑以后可能出现的修改，只要布局有一点点变化，我就无法修改，几乎只能重写，很多地方都是这样，比如一个媒体布局（图文相嵌的那种），又要考虑自适应的缩放，所以用Flex比Float要好，因为万一要少个元素或多个元素，Float很可能出现无法撑开后面元素的情况，比如一个表单的前台验证，万一它不要其中一个验证，我的元素获取就会报错，所以我应该判断它是否存在再去验证，当然每个人喜欢用的解决方案都不一样，我想表达的是，在写一个布局的时候，就要考虑到如果万一要调整，我会不会无法调整，“前走三，后走四”，就像下棋一样，高手总能看的很远，写代码要考虑到可维护性，也是同样的道理。
• 4.还有一个就是开发前要考虑到框架、库、开发前的准备工作，比如，normalize.css将元素归一化，写一个公共样式common.css，把设计图中的细节元素分析一下，写进去，很简单的例子就是a标签或button标签的hover、active、focus等，然后分析一下固定大小元素的宽高值，比如头像图片大小、字体大小、input行高，页面两边的padding，都要统一下，第一个是后面可以统一改（当然也可以单独修改其中某一个），第二是就算不需要改，也可以保证页面的统一性。
• 5.第五个就是和后台合作的事情，其实这次项目和后台合作比较简单，大家也没有确定数据规范，一般都是谁搞不定第二个人再来搞，最多的就是表单的提交和AJAX，我只要给他获取到需要传的值，甚至AJAX很多都是他写的，我写好静态的，他去把静态数据换成变量，最多再加个判断条件，后面再合作，我们可能会先制定好一套规范，每个页面我如何预留接口给他，他把需要的数据以怎么样的格式和方式POST到后端，我们制定一下规则，很多地方就可以免去不必要的浪费时间的沟通。

总的来说，第一次与后台合作进行实战项目，锻炼还是很大的，虽然确实浪费了很多时间（半个多月）修改bug，但是该走的弯路一条也不能少，这样，我们下次合作就能快很多了，在学校有这种锻炼，就算不是实际工作，我觉得也是很好的一件事，需要花费很多精力，但是完成以后感觉成长很多，很值。