项目实战总结

项目总结

最近可以说结束了一个大型项目的重构，感觉有一些感触想记录下来，便于自己以后来翻看。

顺便记录一下我们采用的东西，下面就不一一列举了：

• 后端语言：PHP的ThinkPHP 3.2.3
• 数据库：MySQL
• 缓存：Memcache
• 前段语言：React
• 组件库：and
• 打包工具：Webpack

Q1：谁来说了算？

这大概是第一个问题，由于打算把这个项目作为一个长期运维的项目，所以对页面的交互提出了非常高的要求，同时对页面的美观也提出了很高的要求，这个时候突发奇想，提出了一种可能很好的交互体验，即记录下用户在每个页面的操作，同时在顶部提供超链接供用户跳转回以前任一浏览过的页面，并且在该页面还保留着用户离开时的数据与操作。

为了达到这个目的，我们做了以下尝试：

把当前用户的所有操作不保存在React的state中，而是统一保存在React的缓存组件Mobx中，便于后期恢复。

比如当前页面的输入框，以前的做法是使用this.setState()的方式进行保存，但是现在为了用户能在回到当前页面时也能保有离开时的输入，所以就将用户的输入保存在Mobx中，这样即使使用React Route跳转到别的页面，回来也能读取数据。

这样的设想前期没有什么问题，但是当一个组件开始复用时呢？假设组件A要调用组件B时，为了在组件A中的操作不至于影响原先组件B的内容，所以只能模仿组件B，重新写一个组件，被组件A调用，这样不仅会增加出现问题的可能性，还提升了维护成本，最重要的是，这样就违背了组件开发的原则，各个组件件应该是独立的。

到这里似乎与标题没有什么关系，但是实际上关系是很大的，因为出现这个问题的源头是两派人的错误，设计师与程序员，设计师负责提升交互与页面的美观，程序员负责将设计师的构想变成现实，但是问题是设计师不懂程序背后的原理，他的思考总是欠缺一些考虑的，而程序员也不能盲信设计师，因为我们部门的前端大神真的很牛，脾气又超级好，所以基本是设计师提出的要求，他都能搞出来。于是酿成了上面的错误，虽然不致命，但是种子已经埋下去了，之后就等着哪一天爆发了。

好了，回到原题，谁说了算？，程序员说了算，这是本质，程序的本质是对数据的处理，前端的交互是为了更好的提升程序中用户数据录入的那部分，所以本质上还是程序员说了算。设计师的确是很重要的一环，而且是最初的开始。所以设计师与程序员才需要更多的交流，而不能自己执拗的坚持着我们不懂的所谓的用户交互，而同时对于程序员来说，努力提升自己，积累自己的经验，才能更好的实现设计师所提出的要求，这就像海盗船上的航海士与船长，航海士的意见再重要，也需要船长来做最后的决定，恰恰是我们部门太迷信航海士的话，导致我们错失了很多冒险的机会，只是那些为了去哪的海盗，而永远不可能成为海盗王。

Q2:前后端的爱恨情仇

数据交给谁处理？

这个我是蛮有感触的，因为我是负责其中的一些关联性比较小的模块，比如客户管理，供应商管理，分类管理等，而我前后端都懂一点，所以基本是前端自己写页面，后端自己写接口，所以自由度很高，但是恰恰是这种自由度带来了一个矛盾：数据交给谁处理？

后端可以把数据都获取好后直接交给前端来处理，也可以直接在后端处理好后交给前端渲染，这其中由于React和antd的组件库非常容易报错，所以我们部门的前端大神在获取后端交付数据后都会自己处理一遍，比如数据会重新遍历一遍再赋值给变量，当获取的数组对象为null或者为undefined时会为其设置一个默认值等。所以负责写后端的人就相对轻松一点了，但是我由于是后端出身，所以喜欢使用后端的代码来处理数据，这样前端的代码我可以少写一点。这个时候我明显和大神不一样，所以

那么数据交给谁来处理呢？

前端，这是带我的一个大哥的意见，因为你只有一台服务器，要处理多个用户的请求等，把数据处理分散到各个用户端，可以减轻服务器的压力。当然，这是对还是错，那我就不知道了，但是我知道我需要写更多的前端代码了。

按请求写接口还是按数据写接口

这个又是一个问题，我写的虽然是关联性很小的模块，但是别的页面经常要用到我的接口，我的一个习惯是针对一个页面写一个接口，当用户跳转到该页面后就去调用相应的接口，当然这只是我的习惯。所以引起了麻烦，比如在新增订单的页面，需要分类信息，那么如果是我，则会把分类信息写在新增订单的接口中，但是另一个大哥则觉得只要获取一个分类信息，那么就去掉用分类信息的接口就好，何必还要再专门另开一个接口。于是就去掉用我专门为我那个页面写的接口，结果后期我不知道他掉用了我的接口，我为了别的原因，把返回的数据换了，他那边就直接瘫痪了，找了半天没找到原因，最后发现是我接口改了。

于是我觉得，针对用户的一个页面，写一个端口，这样是必要的，不仅为你在后期添加剩余数据方便，各个接口间也不会造成问题，虽然可能后期要修改的话，要修改多个接口，但是我觉得还是这样更好。

Q3:API文档

这个是我与带我的大哥比较冲突的一点，他觉得这些文档是给前端的人看的，但是我和他基本前后端通吃，所以我们俩单独负责的模块文档不需要那么详细，这个的确是事实，可是我还是感觉需要文档，这是为后期长远考虑，先不说我什么时候就会被fire，再者说新加入的开发人员如果要接手我们的模块，有文档也会轻松一点。所以我还是建议留文档的。

那么怎么写文档快一点呢？要是使用markdown写的话，展示数据之类的还是比较麻烦的，所以这里推荐一个组合吧，还没有形成习惯，但是在前期的开发过程中还是给我们提供了便利的：

• postman：这个可以模拟请求的发送和获取数据，而且可以进行整理导出，非常方便，直接去试试就知道了，有了他我们少写了很多内容
• Showdown：这个是一款在线的文本分享软件，支持markdown语法，我们会把一些必要的文档放在这里，供大家查阅

• Teambition：这个的确很重要。

  我创建了一个，然后设置了以下模块：

• 疑问栏：专门针对开发中的疑问，懂得人就会自动回复你

• 后端已开放端口
• 后端剩余端口
• 前端已创建模块
• 前端剩余模块
• 设计师模块
• 改进意见与建议

由于是小型团队，所以老大不是很赞成我使用这个的意见，他主张以口头交流为主，但是我感觉这个还是很好的，这个能让我们看到自己每天的进度，能让我们心安理得的下班，同时老板也能实时把控项目的进展情况，作出更好的决策。

好了，暂时就想到这么多了，剩下的内容等到自己想到的时候再添加吧。