“这是我参与更文挑战的第7天，活动详情查看： 更文挑战”

设计、开发规范

为什么要有规范，因为有的规范就有了标准，什么都参考这个标准来，没有规范到后面要么返工要么各种兼容性处理，相信笔者，绝对会的，比如：原型设计新增按钮有的叫新增、新建，有的叫创建，ui设计：有的大有的小，前端：悬浮事件有的是手指，有的是箭头，再比如后端有的错误信息选择捕获，有的抛新的异常，有个直接向上层抛。当然有的同学会说，公司成立之初不可能建立完善的规范体制。当然这点是肯定的，这里说的是首先可以定义大致的规范，比如命名、主题色、组件等。其次在实际的工作中每个岗位指定人员去慢慢去维护和完善。而且规范是越来越标准，越来越符合当前公司使用。到最后每个公司的规范都不同，但是大致是相同。

原型规范

遵循原型设计原则，什么对齐、亲密、一致、留白、降噪、节省、MECE原则，也许开始不能完全遵循但是得知道这些，在设计的过程中朝着这个方向去靠，大部分是没有问题。当然这也在满足客户需求前提下进行的。不然再规范的原型，客户不满足，那就不能体现其价值。总之就是满足需求的前提下，尽量遵循设计原则，但注意其实用性，尺度要拿捏好。 输出的原型，前期可以不用什么高保真，但至少有描述每个事件的输入是什么（数据来源）、输出又是什么、数据边界。若是复杂的逻辑可以单独说明，必要时需要提供流程图。好处是可以支持开发，以及测试编写测试用例。

设计规范

若是拿不稳，建议前期可以参考element UI 、Ant Design等，然后定制主题即可。毕竟在色彩感官层面不同的人不同的年龄阶段审美观都是不一样的，建议只听那么一小撮人的意见，最好是那个能拍板的人，尽量减少修改的次数，注意这笔者说的是减少，因为大部分的自主研发的产品，在设计层面或多或少都会经历几次的改动的。有的同学会说设计效果图出来评审一下，然后签个字确认一下不就好了吗？对稳定型公司来说，这是最好的解决方案。然而这套流程不适用于初创型公司，因为太多的变数了，当然若是对这块没有太多的要求，那是最好了。 输出的效果图，能够支持前端开发即可。

开发规范

更直白一点就是编码规范，其前提是有支持编码规范的框架。因此，在进入编码阶段时，建议对应的前后端框架先搭建好，通用的功能模块组件公共化。这里就不过多描述，都是老生常谈的话题了。 输出的可执行文件，尽量都是通过自测的，这里为什么要用尽量二字呢，尤其是在实际工作中后端这块，不仅往往是身兼数职，前端也会存在这样的情况。当然如果人力分配的合理，建议自测。

总结

对于初创型公司来说所有的规范都是让大家朝着那个方向去靠，而不是一上来就强制要求，凡事都有一个过程。毕竟公司刚刚成立，规范可以用，但是不建议太过于依赖，尤其进行所谓的kpi绩效考核。切记切记！！！