这段时间跟着我组老大做了几个FIORI项目，收获颇多，想着总结一下：
1.代码写注释
首先就是代码注释，这个能够帮助其他人接收你的项目时更好的理解项目代码，而且其实你自己过段时间再看自己写的代码也能帮助记忆。
1.1 格式
每一个function上面需要写注释，形如
function内单句代码需要注释就可以直接用//
1.2 内容
注释的内容其实也需要注意，首先描述清晰简洁，像一些常用的其实收集下来下次就可以直接用了。
比如，每一个controller的onInit方法就可以复用这句话： init function for current controller.
onExit： lifecycle for the component, when exit need to clear interal for request。
写注释不要怕麻烦不要怕麻烦，如果过个十年半拉月让你修改这个项目，你会感谢当初写注释的自己的。
2.命名规范
首先要严格遵循驼峰命名法，即使在manifest里定义了一个Model首字母大写的，也需要遵循驼峰命名法。
变量名，function名等名字取得要富有意义，这个其实也不需要再赘述了。常用的像什么handle**,get**,post**等等。
3.function
单页controller能重用的逻辑到全局提一个function出来；
很多controller都可以复用的直接把function提到BaseController里；
一个function逻辑特别长，也可以分开将做不同事的逻辑提出成function；
4.如果发现数据没有成功显示，首先要打开network查看相关的服务端交互的部分，通过查看http code可以大致推断出是哪个环节出现了问题，通过查看preview可以查看错误信息或者与服务器交互的数据。
5.测试环节
这个环节是非常重要的，我们在更改或者添加一个新的需求的时候，很有可能导致其他功能失效，所以测试不光要测试自己新添加的需求，更是要把其他功能统一测试一遍。而且项目有的可能在本地跑是没有问题的，但是部署在lauchpad就会出现问题。
在NewsFeed项目就遇到由于跨域的问题导致了本地跑的通而云端不行，在通过打开network查看相关其他成功项目时发现要想在云端跑的通就需要加上一串域名。
通常测试的步骤为：
做需求->测试需求->考虑该需求是否完善，不完善要及时沟通->本地测试其他功能->没问题部署到环境->在环境上测试
6.项目结构
如果是接手未开发完的项目，这个项目不符合mvc结构，应当修改。无用的代码需要删掉，保持项目的整洁。
7.github
上传git前可以通过代码对比查看自己都修改了什么，这个也能够帮助自己查看是否写了冗余的代码。