presentation:
night.css
width: 800
height: 600
@import “可视化与前端基建和效能的结合/custom.css”
开发人员工作标准
从传统项目铁三角到敏捷铁三角
传统项目铁三角：成本、时间、范围，这三者都围绕这质量。
敏捷铁三角：价值、质量和约束条件（范围、时间、成本）。
1
2
3
4
5
| 在竞争变化的商业环境中，如果实现的不是有价值的需求，哪怕你在成本、时间、范围和质量方面都很完美，这个产品做出来也是没有人使用的，一个没有人使用的东西，也就没有意义。
敏捷强调的是价值和质量，首先做出来的东西对客户是有价值的，且能满足客户的。在这个基础上面变化是随时都有可能发生的，所以约束条件范围、时间、成本根据实际情况调整，提升客户的价值。
虽然不断的变化可能会给我们的进度、成本带来一定的冲击，但这就要求我们做好变化管理，提前识别和预判客户有价值的需求。敏捷团队最终的成功还是要看可用的产品，在达成这一目标的前提下，传统项目铁三角不是最关键的。
|
Exhibitionism
你是不是 exhibitionism？
如何避免自己成为 exhibitionism？
你有没有勇气把你写的代码发给全公司的开发看？
你有没有勇气让你的考评由合作人员打分来决定？
项目管理的职责
对交付时间和交付质量负责，助力于产品价值的体现
关于标准
- 代码质量
- 技术深度
- 业务知识
分清楚及格和优秀，不要将基本的工作要求当成你做得好的标准
项目负责人
你真的了解整个项目/系统么？
你对于自己做的每一个修改，都知道其影响范围么？
分内的事情要做好，分外的事情多掺和(肇事者、参与者、旁观者)
“我是前端，我哪知道后端的逻辑？”
你喜欢把事情的成败掌控在别人手里么？
关于时间观念
时间是一种承诺，是体现一个人靠不靠谱、影响信任的关键
延期在特殊情况下(新技术、未知领域、不可抗力因素)是被允许的，但是必须至少提前一天通知主管
运营中台对接项目、短视频项目：如果让对方给我们打分，他们会打几分？
关于解决问题的标准
- 是否从业务和流程根源上弄清楚了问题产生的原因？
- 是否从技术原理上清楚了问题产生的原因？你能给别人讲清楚么？
- 这个问题是否彻底解决了？后续是否还有可能出现？
别靠猜测去解决问题，否则计算机科学就会变成一门玄学
我们和优秀人员的差距在哪里？
可视化搭建的被一位大专的同学干翻了
短视频的被一位景德镇陶瓷学院的同学干翻了
开发人员工作标准
开发人员工作标准-前端
分数计算：红色-5，黄色 0-5 分(主观项动态评分)，绿色由技术委员会根据案例情况单独评分
开发人员工作标准-前端-设计
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
| 红：
[客观]首页请求总数过多
[客观]首页请求总体积过大
[客观]兼容性设计不达标(兼容到Android4.4、iOS9、Chrome49)
[客观]首页加载时间大于1秒
黄：
[主观]设计内容覆盖完整，包括页面模块化拆分设计、数据传递流程、性能等
[客观]考虑按需加载，保证正式的静态资源大小低于预警线
[主观]设计的组件可独立运行，可接入其他功能，尽量降低依赖
[主观]具有抽象意识，能从需求中提取公共组件进行封装，并考虑到可扩展性
[主观]考虑到容错设计(异常情况的兜底，不要开天窗)
绿：
[主观]提供通用技术方案来解决兼容性、性能等质量问题
[主观]引入新的技术、框架、方案来升级开发模式，带来效能上质的提升
|
开发人员工作标准-前端-编码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| 红：
[客观]代码健康度综合得分(规范、安全、复杂度、重复度、可维护性)未达到标准
[客观]使用JS的不良特性(全局变量、回调地狱、滥用闭包等)
[客观]单个文件体积超过阈值
黄：
[主观]保持UI高还原度
[客观]针对T3以上人员，review别人的代码，找出的问题数达到一定的量
[客观]被review出的问题数低于预警值
[主观]配置文件单独抽离，不与业务代码混淆
绿：
[客观]开发出来并通过审核的组件数
[客观]组件被业务方调用的次数
[客观]组件被应用到的业务数
|
开发人员工作标准-前端-调试
1
2
3
4
5
6
7
8
9
10
11
12
| 红：
[主观]移动端开发人员不会用真机平台
[主观]不善于通过控制台进行调试，开发阶段不留埋点信息
[主观]调试时不先从业务入手，直接看代码
[主观]不会断点调试、抓包等常规调试手段
黄：
[主观]会用公司现成的工具和平台辅助调试
绿：
[主观]能自己开发调试工具并推广到公司范围进行使用
|