最近公司的项目使用angular，与ionic开发企业级软件；
现在项目越来越庞大了，我是中途加入团队，现在有时候就实现一个简单的需求，就要花费几天；
比如产品说：在提交按钮的时候，再去请求一个接口，校验一下数据；
听着简单，做的时候，就发现各种坑了；牵扯到数10个文件；
稍不注意，就会造成更多的bug；
实现一个需求，真是胆战心惊的；
下面说说里面的坑，以后应该怎样避免
控制器与视图
尽管下面的视图view1,view2,view3差不多，
很多逻辑也是一样的；
不要用同一个控制器，
不要不加修饰的直接控制视图；
谁也不知道，三个视图以后会怎么变化；
只要修改一个视图的逻辑，很容易影响到其他视图的逻辑；
下面是正确的做法，
每一个视图，对应自己控制器；
如果有公共的逻辑，直接注入一个服务；
如果以后，哪一个视图逻辑需要修改，可以在控制器里面改，或者修改服务；
如果修改的服务会影响其他视图，可以尝试新建服务；
对于视图，也是同样的逻辑，相互不影响；
现在软件里很多地方采用第一种方式：比如
视图都差不多，但是对里面的操作有些不一样，页面的显示也有不一样；在软件初期就应该用不一样的控制器分别对每一个页面进行控制；
-------------------------------
视图与模型
正确的应该这样
显示是没有明确的中间的这个调和的模型；
都是视图直接显示请求过来的字段；
如果字段多，那么有些就不显示；
如果字段少，就加几个在外面，并没有加到模型里面；
导致修改的时候，分不清哪些数据是后端来的，
哪些是需要提交的数据；
加之没有注释；各种乱；
--------------------------------------------------
其他建议
1、文件大，很多地方，没有做封装；
建议用函数拆分，每个文件不要超过1000行
2、单个函数长，逻辑多；
建议做小的逻辑拆分，单个函数不要超过100行
3、注释少，看代码的时间花费多；
对于文件与函数，写必要的注释；
4、废弃代码多，这个很麻烦，如果不是本人，根本不敢删除，
没有用的，就注释在代码里面，说是以后可能会用。
但是不用的注释代码，实际上越留越多；
建议：禁止无用的代码注释在文件里
5、多个开发者共同开发这个项目，没有统一的命名规范；
下划线的，驼峰的，非下划线也非驼峰的，中文拼音的；
建议制定一个规范
6、代码不格式化
建议，每次提交自己的代码时，使用编辑器，格式化
-----------------------------
对于设计
对于设计，我就说一个弹窗；
下面这个弹窗，用到苹果手机上，没问题；
但是用在android机上，就毁坏的不是一个软件，
而是整个手机
ionic是个好框架啊；
原本ionic针对，ios与Android做了不同的界面风格；
由于公司设计师把ios与Android的风格中和了一下；
于是有些地方，需要把Android风，改为ios风；
有时候，相反；
-------------------
