陈子贱爱笑
陈子贱爱笑
[closure-compiler](https://github.com/google/closure-compiler-js)
[Tree-shaking - webpack 2 和 Babel 6](https://segmentfault.com/a/1190000012037605) [harmony-unused](https://github.com/webpack/webpack/tree/master/examples/harmony-unused)
一个后端工程师对前后端接口约定的看法(仅供参考) - 工作模式 公司目前采用前后端分离的模式进行项目开发。本人处于后端组的Java开发职位。 - 前后端的沟通桥梁 前后端分离开发项目，前端组主要负责页面的设计与交互，后端组主要负责数据的存储与服务。前后端组工作协作靠接口文档。目前本人公司的接口文档由前端工程师主要填写，后端人员进行后期的调整。 - 发现的问题 在前后端两个小组协作开发项目的过程中，逐渐了发现了些许协作问题，以本人目前的眼界，认为最为突出的问题会发生在接口文档上。 - 结论缘由 为什么本人会认为最大的问题出现在接口文档，并在此请教改善之法呢？有以下几点原因。 - 1.前后端人员的思维差异 接口文档，表明了前端请求后端数据时的格式。本人公司采用json的数据格式进行数据交互，后端采用Java开发，自然是将model中的数据转为json格式“跪送”给前端。但由于每个人的思维不用，对接口中的字段命名习惯等也大不相同。例如后端User类中有name和age两个属性，但前端人员写接口文档时偏偏是{“username”:“xxx”, “sex”:“xxx”}。为了应对这种情况，最开始开发项目时，后端再返回数据之前采用Map的方式将model中的数据进行重组和封装，达到前端要求的接口内容。但Java代码就泛滥出大量的put操作，甚是繁琐。个人认为这种情况可以在开发前期两组就要办法做统一规范。 - 2.前端人员填写 接口的“随意性” 为了避免Map方式所带来的繁琐操作和put代码泛滥，随后的项目开发中，引入了DTO类，并借助Dozer工具进行实体类DTO类之间的映射转换。DTO类中的属性名符合前端人员在接口文档中所写的字段名称。例如为了传输User类的数据，对应的有UserDTO类，有username和sex属性。同时DTO也可以应对传输实体类部分属性的情况。OK，这种模式进行了一段时间后发现，由于前端人员写接口太过随意，导致后端会产生大量碎片化的DTO类。举个详细的例子： ``` public class Course { //课程实体类 private Long id;...
接口平台开源的可以用 [swagger](https://github.com/yvasiyarov/swagger) [RAP](https://github.com/thx/RAP) > 不过基本上所有的大厂都会有自己的一套接口文档编辑平台
``` javascript let result = [source]; replaces.sort((a, b) => b.from - a.from).forEach(replace => { let remainSource = result.shift(); result.unshift( remainSource.substr(0, replace.from), `/* ${replace.name} */${replace.value}`, remainSource.substr(replace.to) ) }); console.log(result.join('')); ```
[谷歌是如何做代码审查的](http://goodmath.scientopia.org/2011/07/06/things-everyone-should-do-code-review/) [谷歌是如何做代码审查的-译文](http://www.vaikan.com/things-everyone-should-do-code-review/) [为什么谷歌要执行严格的代码编写规范](https://my.oschina.net/huiger/blog/298734)
* 1、完善模块寻址 * 2、完善依赖解析 * 暂时只能解析 `var a = require('./a');` 这种变量定义形式，怎么优化了可以解析 `require('./a')`，或者 `import a from './a'` 这些形式？ * 怎么解析出 `require('./a')()` 这样的自执行模块？ * 3、代码压缩改进？ * 4、还有下面三点...
开源项目的持续集成推荐文章： - 1、[一个靠谱的前端开源项目需要什么？](https://segmentfault.com/a/1190000005859766) - 2、[前端开源项目持续集成三剑客](http://efe.baidu.com/blog/front-end-continuous-integration-tools/)
git flow图： --- 