获奖名单公布|日常的开发工作中,你做过哪些「减法」?

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) 获奖通知的小伙伴请及时联系小编,提供您的收货信息,或者按照通知内容发送收货地址至指定邮箱或手机号码。

4个回答
风烛年 回复于 2023-02-15 09:30 · IP属地北京

【开发者的减法日常】使用声网 [跨频道媒体流转发] 实现 [语音房 - 单人 - 跨房PK] 功能 1 https://www.shengwang.cn/cn/community/blog/25583

【开发者的减法日常】使用声网 [跨频道媒体流转发] 实现 [语音房 - 单人 - 跨房PK] 功能 2

https://www.shengwang.cn/cn/community/blog/25584

回复·0
风烛年 回复于 2023-02-19 15:12 · IP属地北京

关于 「给工作做减法」的一些实践分享 :


我们是做社交APP的公司, 一直在专做一个APP项目.

不断的版本迭代, 向前推进着.

整个项目迭代的流程, 大概是产品内部讨论通过一些功能点,

然后产品人员产出详细的需求文档, 然后召集研发团队开需求会,

如果需求会中产生了重大的改动, 就需要回退到产品阶段重新设计,

整个流程中, 因为前期和研发团队沟通不够充分, 所以会在需求会上做详细的讨论,

那么需求会上, 就要求产品产出的PRD文档足够精细, 才不会翻车, 或者需要开超长时间的需求会.

这样流程, 产品和研发都很痛苦, 因为产品需要花费大量精力撰写文档, 考虑细节.

而没有足够的时间, 用于关键问题的分析和思考, 对于创业公司来说,

本身所有的功能点, 其实都是未知的, 如果花费大量时间去考虑细节, 而不是关键问题,

这就导致, 核心产品人员产出PRD的时间会特别长, 而且即使开发的十分精致,

但是不一定是用户所需要的. 而创业公司, 本身就需要 [短 / 频 / 快], 需要不断的快速试错,

才会产出真正有价值的功能点.而后期的需求会, 因为是全体相关研发一起开大会,

所以导致其实主要是架构师和骨干人员在讨论细节, 而大量一线人员, 都是旁听的状态,

这种情况下, 就导致一次版本迭代, 周期拉的很长, 而长时间的开会, 导致一线人员状态不好,

架构师和骨干也会别影响.


所以我们针对上面的情况, 对项目过程做了减法 :

我们把项目阶段进行切分, 每一步只需要相关人员参加即可 :

1] 创意阶段 : 产品只需要说明白这个功能点的核心抓手即可, 不需要完善的文档, 参加人员只局限于团队高管; 这个阶段是找方向, 抓创意; 不讨论具体实现方案, 不考虑研发成本;

2] 落地阶段 : 产品基于创意阶段定下的目标, 完善产品文档, 补充核心抓手和要素, 要写清楚哪些是必须实现的核心抓手, 这样就可以抓大放小了.这个阶段, 需要各端架构师入场了, 主要是CTO带领各端架构师, 做技术可行性讨论, 需要找出成本最低的可行性方案. 本阶段, 只做技术选型和核心方案讨论, 不做具体研发设计, 不讨论实现细节. 如果需要做调研才能够给出方案的, 那么就增加一个调研时间,然后再次进行本阶段的讨论.一线开发人员, 不参与本阶段的讨论;

3] 架构阶段 : 基于落地阶段的讨论, 已经确认和实现方案, 产品人员会继续完善PRD, 开始补充一些细节, 本阶段是架构师带领骨干开始做架构设计, 各端要充分讨论之后, 确认完整的架构方案, 产出详细设计文档和核心流程图, 为了保证研发理解正确, 要做设计反讲. 本阶段一线开发人员不参与, 只是架构师和核心骨干参与, 定出可实施的技术方案, 并且拆解工作, 把工作分发到一线研发.

4] 研发阶段 : 会开一次全员的需求讲解会, 因为产品方案和技术方案都已经讨论清楚了, 所以这个会议不会很耗时, 并且在开会之前, 任务已经分发下去了, 所以一线人员参与时, 都清楚自己负责的那部分工作.


经过减法之后的项目流程, 每一阶段参与的人员减少了, 每一阶段要做的工作更加明确了,

因为参与者切分了, 所以项目可以双周期迭代了, 就是在一个项目的提测阶段, 开始下一个项目的1 /2/3阶段, 不断的迭代轮转, 效率比之前大大提高, 产品和研发, 也不会再抱怨会议超长, 却与我无关了.

回复·0
Hanson bakedcorn 回复于 2023-02-28 06:54 · IP属地北京

【开发者的减法日常】开发懒人的减法心得

https://www.rtcdeveloper.cn/cn/community/blog/25681

回复·0
Hanson bakedcorn 回复于 2023-04-14 08:35 · IP属地江苏

咱们这个活动什么时候评奖呢

回复·0