0 获奖名单
1、给工作「做减法」
获奖童鞋:风烛年,获得 200 元京东卡一份,声网 RTE 开发者社区专属徽章一枚,「双肩包 or 卫衣 or 充电宝」礼品自选一份
2、给项目「做减法」
由于本次参与活动文章质量未符合优质标准,因此参与本次征文的童鞋仅可获得其他礼品~
获奖童鞋:Hanson bakedcorn、风烛年
以上两位童鞋将获得:声网 RTE 开发者社区专属徽章一枚,「双肩包 or 卫衣 or 充电宝」礼品自选一份
请各位小伙伴附上自己的个人信息页面截图及快递信息,私信企业微信@Chen Yun,我们将在 5 个工作日内核对获奖信息并寄送礼品哦。
二月春风似剪刀啊朋友们!
别的地方不知道,
这几天北京的风刮的属实有一些厉害
提到剪刀,
就不难联想到「做减法」,
也就是我们社区 2 月份的征文主题
-----------------------------------------------
工作多年的开发者,难免会碰到(或者亲手写出) shit 一样的代码。
究其原因,在于很多开发者和技术团队只会通过写补丁式的代码,来进行项目的迭代或功能的增删,毕竟写 100 行代码的复杂度远低于删掉 100 行代码。缝缝补补几次,代码很难不变的和 shit 一样。
但“做加法”是人类的通病。在寻找解决方案时,我们大脑的默认选项是“增加点什么东西”而非删减掉什么。
"人们越是经常依赖加法策略,就越是容易陷入认知误区。"这是弗吉尼亚大学的心理学家 Gabrielle Adams 的一个观点,他认为“随着时间的推移,做加法的习惯可能会越来越强,从长远来看,我们最终会错过最佳的方案。"
所谓的“减法”可能就包含减少垃圾代码的堆叠和输出,抽象到更高的层面来进行程序设计;减少无用的沟通,用更高效的方式进行项目协作...
所以,声网 RTE 开发者社区 2 月份的征文主题就是「做减法」!快来分享你在日常开发工作中做过哪些减法?或者有哪些做减法的技巧与经验?
01 活动主题
1、给工作「做减法」!
在本篇帖子下留言,分享你日常工作中的「减法日常」,最好和技术、开发、项目相关哦~我们将会挑选 5 位小伙伴送上社区大礼包一份!
2、给项目「做减法」!
基于声网的 SDK(不限版本和方向),用尽可能少的代码(100 行以内)开发并跑通一个实时互动领域的场景/功能。
示例文章
文章要求
- 在正文的第一句加入“我正在参加「声网 RTE 开发者社区」征文活动”,并附带本活动外链
- 文章标题前需加上前缀【开发者的减法日常】
体裁规范
- 代码块: 必须满足发布通过审核并且成功运行的,不得抄袭同类平台的代码块。
- 文章: 根据自己撰写的原创代码块,产出相关文章,文章中必须包含相应的代码块链接,可以是历史文章中的代码修改也可以新建代码块,文章字数 ≥500字。
- 文章和代码块都要求原创,内容符合社区的内容标准和规范, 字数不得少于 500 字,不得有广告/洗稿/凑字数等行为。
注意,所有的文章都不能只贴代码,要有自己的分析思考,否则不计数。
(本次活动不与站内其他活动并行,一篇文章/帖子只能参加一个活动;若活动中发现作弊行为,立即取消活动资格!)
02 活动奖品
🎁 参与「给工作做减法」内容最优质的 1 名童鞋获得 200 元京东卡一份
🎁 参与「给项目做减法」内容优质的前 3 名童鞋将获得 300 元京东卡一份
🎁 所有成功参与的小伙伴都将获得声网 RTE 开发者社区专属徽章一枚!
🎁 我们将随机挑选 3 位童鞋额外获得「双肩包 or 卫衣 or 充电宝」礼品自选一份哦
03 参与方式
本期活动时间:即日起 - 2023/3/31
- 注册/登录「RTE 开发者社区」账号,页面右上角点击「写文章」按钮发布对应内容,参与征文的小伙伴,文章标题前需加上前缀【开发者的减法日常】哦
- 将发布的文章/帖子链接贴在本活动页面下方的评论区
其他:
1) 本文礼物发放规则最终解释权归「RTE 开发者社区」官方所有。
2) 我们将会在 4 月的第五个工作日在社区公布获奖名单!欢迎各位小伙伴多多吆喝自己的朋友来一起参与哦~
3) 获奖通知的小伙伴请及时联系小编,提供您的收货信息,或者按照通知内容发送收货地址至指定邮箱或手机号码。
【开发者的减法日常】使用声网 [跨频道媒体流转发] 实现 [语音房 - 单人 - 跨房PK] 功能 1 https://www.shengwang.cn/cn/community/blog/25583
【开发者的减法日常】使用声网 [跨频道媒体流转发] 实现 [语音房 - 单人 - 跨房PK] 功能 2
https://www.shengwang.cn/cn/community/blog/25584
关于 「给工作做减法」的一些实践分享 :
我们是做社交APP的公司, 一直在专做一个APP项目.
不断的版本迭代, 向前推进着.
整个项目迭代的流程, 大概是产品内部讨论通过一些功能点,
然后产品人员产出详细的需求文档, 然后召集研发团队开需求会,
如果需求会中产生了重大的改动, 就需要回退到产品阶段重新设计,
整个流程中, 因为前期和研发团队沟通不够充分, 所以会在需求会上做详细的讨论,
那么需求会上, 就要求产品产出的PRD文档足够精细, 才不会翻车, 或者需要开超长时间的需求会.
这样流程, 产品和研发都很痛苦, 因为产品需要花费大量精力撰写文档, 考虑细节.
而没有足够的时间, 用于关键问题的分析和思考, 对于创业公司来说,
本身所有的功能点, 其实都是未知的, 如果花费大量时间去考虑细节, 而不是关键问题,
这就导致, 核心产品人员产出PRD的时间会特别长, 而且即使开发的十分精致,
但是不一定是用户所需要的. 而创业公司, 本身就需要 [短 / 频 / 快], 需要不断的快速试错,
才会产出真正有价值的功能点.而后期的需求会, 因为是全体相关研发一起开大会,
所以导致其实主要是架构师和骨干人员在讨论细节, 而大量一线人员, 都是旁听的状态,
这种情况下, 就导致一次版本迭代, 周期拉的很长, 而长时间的开会, 导致一线人员状态不好,
架构师和骨干也会别影响.
所以我们针对上面的情况, 对项目过程做了减法 :
我们把项目阶段进行切分, 每一步只需要相关人员参加即可 :
1] 创意阶段 : 产品只需要说明白这个功能点的核心抓手即可, 不需要完善的文档, 参加人员只局限于团队高管; 这个阶段是找方向, 抓创意; 不讨论具体实现方案, 不考虑研发成本;
2] 落地阶段 : 产品基于创意阶段定下的目标, 完善产品文档, 补充核心抓手和要素, 要写清楚哪些是必须实现的核心抓手, 这样就可以抓大放小了.这个阶段, 需要各端架构师入场了, 主要是CTO带领各端架构师, 做技术可行性讨论, 需要找出成本最低的可行性方案. 本阶段, 只做技术选型和核心方案讨论, 不做具体研发设计, 不讨论实现细节. 如果需要做调研才能够给出方案的, 那么就增加一个调研时间,然后再次进行本阶段的讨论.一线开发人员, 不参与本阶段的讨论;
3] 架构阶段 : 基于落地阶段的讨论, 已经确认和实现方案, 产品人员会继续完善PRD, 开始补充一些细节, 本阶段是架构师带领骨干开始做架构设计, 各端要充分讨论之后, 确认完整的架构方案, 产出详细设计文档和核心流程图, 为了保证研发理解正确, 要做设计反讲. 本阶段一线开发人员不参与, 只是架构师和核心骨干参与, 定出可实施的技术方案, 并且拆解工作, 把工作分发到一线研发.
4] 研发阶段 : 会开一次全员的需求讲解会, 因为产品方案和技术方案都已经讨论清楚了, 所以这个会议不会很耗时, 并且在开会之前, 任务已经分发下去了, 所以一线人员参与时, 都清楚自己负责的那部分工作.
经过减法之后的项目流程, 每一阶段参与的人员减少了, 每一阶段要做的工作更加明确了,
因为参与者切分了, 所以项目可以双周期迭代了, 就是在一个项目的提测阶段, 开始下一个项目的1 /2/3阶段, 不断的迭代轮转, 效率比之前大大提高, 产品和研发, 也不会再抱怨会议超长, 却与我无关了.
【开发者的减法日常】开发懒人的减法心得
https://www.rtcdeveloper.cn/cn/community/blog/25681
咱们这个活动什么时候评奖呢