前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >对angular开发者的建议,设计师也有

对angular开发者的建议,设计师也有

作者头像
前朝楚水
发布2018-04-03 14:49:39
7900
发布2018-04-03 14:49:39
举报
文章被收录于专栏:互联网杂技

最近公司的项目使用angular,与ionic开发企业级软件;

现在项目越来越庞大了,我是中途加入团队,现在有时候就实现一个简单的需求,就要花费几天;

比如产品说:在提交按钮的时候,再去请求一个接口,校验一下数据;

听着简单,做的时候,就发现各种坑了;牵扯到数10个文件;

稍不注意,就会造成更多的bug;

实现一个需求,真是胆战心惊的;

下面说说里面的坑,以后应该怎样避免

控制器与视图

尽管下面的视图view1,view2,view3差不多,

很多逻辑也是一样的;

不要用同一个控制器,

不要不加修饰的直接控制视图;

谁也不知道,三个视图以后会怎么变化;

只要修改一个视图的逻辑,很容易影响到其他视图的逻辑;

下面是正确的做法,

每一个视图,对应自己控制器;

如果有公共的逻辑,直接注入一个服务;

如果以后,哪一个视图逻辑需要修改,可以在控制器里面改,或者修改服务;

如果修改的服务会影响其他视图,可以尝试新建服务;

对于视图,也是同样的逻辑,相互不影响;

现在软件里很多地方采用第一种方式:比如

视图都差不多,但是对里面的操作有些不一样,页面的显示也有不一样;在软件初期就应该用不一样的控制器分别对每一个页面进行控制;

-------------------------------

视图与模型

正确的应该这样

显示是没有明确的中间的这个调和的模型;

都是视图直接显示请求过来的字段;

如果字段多,那么有些就不显示;

如果字段少,就加几个在外面,并没有加到模型里面;

导致修改的时候,分不清哪些数据是后端来的,

哪些是需要提交的数据;

加之没有注释;各种乱;

--------------------------------------------------

其他建议

1、文件大,很多地方,没有做封装;

建议用函数拆分,每个文件不要超过1000行

2、单个函数长,逻辑多;

建议做小的逻辑拆分,单个函数不要超过100行

3、注释少,看代码的时间花费多;

对于文件与函数,写必要的注释;

4、废弃代码多,这个很麻烦,如果不是本人,根本不敢删除,

没有用的,就注释在代码里面,说是以后可能会用。

但是不用的注释代码,实际上越留越多;

建议:禁止无用的代码注释在文件里

5、多个开发者共同开发这个项目,没有统一的命名规范;

下划线的,驼峰的,非下划线也非驼峰的,中文拼音的;

建议制定一个规范

6、代码不格式化

建议,每次提交自己的代码时,使用编辑器,格式化

-----------------------------

对于设计

对于设计,我就说一个弹窗;

下面这个弹窗,用到苹果手机上,没问题;

但是用在android机上,就毁坏的不是一个软件,

而是整个手机

ionic是个好框架啊;

原本ionic针对,ios与Android做了不同的界面风格;

由于公司设计师把ios与Android的风格中和了一下;

于是有些地方,需要把Android风,改为ios风;

有时候,相反;

-------------------

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2017-05-04,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 交互设计前端开发与后端程序设计 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档