前端代码的可维护性

到新公司20天，做了两个任务，本身不复杂，但是嵌套在原有的系统里，常常不知如何下手。

原因有二。

第一，需求不清。产品和程序之间在写代码前没有沟通。我以他们的原型图为准，但原型图太粗糙了。做了一段时间，甚至发现不是自己想的那样，造成无用功。当然，这不是主要议题。在知道这边的情况后，我必然会采取行动。

第二，也就是我本篇想说的——代码的维护性。

现在的代码就是乱糟糟一坨，尤其是后端那块儿，各种不统一。前端那块儿相对要好很多，目录结构相对清晰，对常用的插件和工具也进行了封装。然而还是出现了页面不统一的情况。出现不统一的根本原因在于大家一起开发的时候没有互相的参考和约定，没有写出一个文档。当面对茫茫的代码时，我们要做的不是深入代码，而是对代码有个全局的把握。当前的代码有哪些功能，没有哪些。那样的话，新人就不必纠结是不是再重新实现的问题。本质上团队开发就是一起写lib的过程，我们要做的是尽量将这个lib完善，下次能很快的使用。boostrap就是这样一个产物。lib的构建也挺有讲究，每块干什么，预留什么，这都值得研究。有经验了再专门写一下。

现有的代码用seajs组织，将代码进行了模块化。利用grunt进行合并压缩。这样做大大提高了代码的重用性，构建起代码来很方便。

上周六去杭州参加D2论坛，这次的主要议题是前后端分离。介于和后端调试的时候留下的阴影，我深深体会到它的优势。前端没有必要花费大量的时间去为后端验证数据的正确性。前端管好前台流程和逻辑就行，可以用仿制的数据跑通流程就可以了。而后端也不需要求之于前台显示结果。

这些将是我们接下来一段时间的任务。^_^