框架与使用者
之前在工作中准备尝试使用一下Vue,结果搭好了原型就被叫去开发接口去了。项目上线以后原来负责前端的同事被安排去做别的项目了，前端的维护工作又转回到了我的手上。接手维护工作后的第一个任务就是解决一个上传文件的BUG，结果改这个因为传参问题引起的BUG花了我一个小时。一是因为刚接手对代码不熟悉，二是因为代码写得有些难懂，有些我认为会写在这里的代码出现在了那里，三是因为同样的代码被复制到了三个不同的地方，隐藏在了一大坨代码的缝隙中。亲自试了一试改BUG之后，我才明白为什么上线前只要让前面负责的同事改BUG，他就一脸痛苦的样子。如果继续在当前的这套代码上维护，我也会痛不欲生，于是申请对代码进行重构，领导让我放手去做。
以前，我总是觉得，先进的前端MVVM开发框架是摆脱老项目中无穷无尽的DOM操作的灵丹妙药。现在，我觉得，如果使用者无法很好地驾驭框架，摆脱了一个苦海，又会掉入另一个苦海。重构进行的过程中，我觉得前面的同事在开发的过程中一定觉得很难处理不同组件之前的通信问题，所以一是用了非常多的变量去记录页面状态，二是能少用组件就少用组件，而始终没有发现官方文档中已经推荐了使用Vuex来解决这个问题。
代码经过我的重构之后，行数目测减少了三分之二。经过这次重构，我理解了：工具好不好，还是在于使用者，使用者会用，就能解决很多问题，反之，会引入新的问题。这让我想起来以读书的时候，我在Matlab中用循环做矩阵运算，被同组的同学喷得体无完肤。
关于代码与接口设计
这次对前端进行重构，也给了我一次审视自己写的接口的机会。开发过程中，因为移动端App的同事增经对一些接口的参数定义的理解和我自已不一样，我特意将这些接口分成了多个以避免歧义。然而当我自己进开发的时候，却发现这些拆分接出来的接口好像用不上。
该项目主要是做一个文件管理工具，外观类似网盘。前端会以Tab的形式对其中某几个文件夹进行特别展示。最开始，我的接口都是按照操作某个文件夹下的某个文件的思路来定义的，然而前端开发却对接口定义的理解和我有偏差。于是，我把原来的一个接口从Tab的角度去区分拆分成了多个，一个接口对应于某个Tab下的某个操作，看似解决了歧义问题。
现在，当我自己使用这些接口做开发的时候，却觉得，操作某个文件夹下的某个文件这种思路足够了。某个Tab下的某个操作这种思路我觉得应该是用来向用户解释的。作为开发，应该理解某个Tab下的某个操作实质上等同于操作某个文件夹下的某个文件。如果接口开发者发现接口使用者觉得接口定义有歧义，应该向使用者解释清楚后端的实现思路，而不是为了消除岐义去拆分接口。这样做的话，对前后端开发来说，不仅工作量会少很多，代码逻辑也会更加清晰。
为什么我会这样说？因为重构的过程中我发现，对于不少接口，同样的传参和响应处理方式都能正常工作，而使用到这些接口的页面也相似。如果接口地址也相同，前端就可以将页面和接口调用逻辑打包成一个连接口地址都不用传组件，又能少写一些代码。出现了现在的情况我觉得还是抽像没有做到位。
写好代码和解决好问题
我觉得写代码的工作有两个要求：“写好代码”和“解决好问题”。上文的分析只涉及到了“写好代码”这个层面。我觉得“写好代码”又可以分为：“减少冗余”和“逻辑清晰”。现在的我基本能够达到“减少冗余”的要求，“逻辑清晰”还谈不上，很多时候为了“减少冗余”结果把不该放到一起的代码放到一起了。至于“解决好问题”，低端一点需要对计算机基础知识比较了解，高端一点需要对相关专业的专业知识比较了解。10年学会编程,我才刚刚起步。