“这是我参与更文挑战的第7天,活动详情查看: 更文挑战”
设计、开发规范
为什么要有规范,因为有的规范就有了标准,什么都参考这个标准来,没有规范到后面要么返工要么各种兼容性处理,相信笔者,绝对会的,比如:原型设计新增按钮有的叫新增、新建,有的叫创建,ui设计:有的大有的小,前端:悬浮事件有的是手指,有的是箭头,再比如后端有的错误信息选择捕获,有的抛新的异常,有个直接向上层抛。当然有的同学会说,公司成立之初不可能建立完善的规范体制。当然这点是肯定的,这里说的是首先可以定义大致的规范,比如命名、主题色、组件等。其次在实际的工作中每个岗位指定人员去慢慢去维护和完善。而且规范是越来越标准,越来越符合当前公司使用。到最后每个公司的规范都不同,但是大致是相同。
原型规范
遵循原型设计原则,什么对齐、亲密、一致、留白、降噪、节省、MECE原则,也许开始不能完全遵循但是得知道这些,在设计的过程中朝着这个方向去靠,大部分是没有问题。当然这也在满足客户需求前提下进行的。不然再规范的原型,客户不满足,那就不能体现其价值。总之就是满足需求的前提下,尽量遵循设计原则,但注意其实用性,尺度要拿捏好。 输出的原型,前期可以不用什么高保真,但至少有描述每个事件的输入是什么(数据来源)、输出又是什么、数据边界。若是复杂的逻辑可以单独说明,必要时需要提供流程图。好处是可以支持开发,以及测试编写测试用例。
设计规范
若是拿不稳,建议前期可以参考element UI 、Ant Design等,然后定制主题即可。毕竟在色彩感官层面不同的人不同的年龄阶段审美观都是不一样的,建议只听那么一小撮人的意见,最好是那个能拍板的人,尽量减少修改的次数,注意这笔者说的是减少,因为大部分的自主研发的产品,在设计层面或多或少都会经历几次的改动的。有的同学会说设计效果图出来评审一下,然后签个字确认一下不就好了吗?对稳定型公司来说,这是最好的解决方案。然而这套流程不适用于初创型公司,因为太多的变数了,当然若是对这块没有太多的要求,那是最好了。 输出的效果图,能够支持前端开发即可。
开发规范
更直白一点就是编码规范,其前提是有支持编码规范的框架。因此,在进入编码阶段时,建议对应的前后端框架先搭建好,通用的功能模块组件公共化。这里就不过多描述,都是老生常谈的话题了。 输出的可执行文件,尽量都是通过自测的,这里为什么要用尽量二字呢,尤其是在实际工作中后端这块,不仅往往是身兼数职,前端也会存在这样的情况。当然如果人力分配的合理,建议自测。
总结
对于初创型公司来说所有的规范都是让大家朝着那个方向去靠,而不是一上来就强制要求,凡事都有一个过程。毕竟公司刚刚成立,规范可以用,但是不建议太过于依赖,尤其进行所谓的kpi绩效考核。切记切记!!!