其他
如何成为一名靠谱的程序员:职业素养入门指南
👉导读
本文基于我十多年程序员生涯观察,落笔始于 2019 年学习怎么带领团队新人时,在此之前我一直在想,如果当年有人告诉我这些道理,我是不是可以发展得更好,也少一些纠结。本文不是如何成为编程高手的秘籍,也不是介绍如何在职场中为人处世,更不是告诉你怎么成为优秀的程序员,本文只介绍如何处理好工作中的细枝末节,帮助你树立专业的、靠谱的程序员“人设”,是一篇程序员职业素养的《新人须知手册》。友情提醒,长文干货,提前收藏码住!文末还有龙年红包福利!👉目录
1 不靠谱程序员案例2 你的目标3 计划与执行4 需求讨论5 编写代码6 代码评审7 文档编写01
1.1 虚假的交付
1.2 随意的承诺
1.3 推卸责任式的通知
1.4 组织浪费多人时间的会议
1.5 重要事故不向上反馈
1.6 延期不提前预警
1.7 遗漏工作和疏忽大意
负责人:你本周的工作计划遗漏老系统下线,需要跟进下。 小 A:我和业务团队的开发小 B 沟通了,他说要问一下他们的领导,我们后面继续跟进。 负责人:小 B 有说什么时候能给答复吗? 小 A:小 B 好像有紧急告警在处理,他说本周会问他们的领导,我这周晚点再问。 负责人:不急,但需要有明确的时间节奏。
负责人:时间点有了吗? 小 A:还没,我问问。
小 A:小 B 说本周五才能和他的领导对齐改造节奏。
负责人:没看到结论反馈,这里的进展怎么样? 小 A:(丢出一个文档)这里有排期,他们会做迁移。 负责人:符合我们预期吗? 小 A:他们把流量迁移完,我们的老服务就可以下线,符合预期,6 月中旬完成。
负责人:“无其他业务需求时做支持,预计 6 月中旬完成”,整个承诺还带有附属条件,我们不能认为他们一定会在 6 月中完成业务迁移,应该要和他们再次确认,给出可以完成的时间点。
遗忘工作事项,需要负责人多次提醒 在沟通进度的过程中,陷入追问模式,无法抓住要点回答 他和业务团队对排期有明显的理解 gap:他以为 6 月中旬可以完成,实际上对方说的是没有其他需求的情况下才能 6 月中旬完成,对方给的这个承诺不需要负承诺责任,如果延期了,他们可以说:我说过了,没有业务需求才能这个时间完成,最近我们有业务需求。业务团队实际上没有给出确切的排期,这会威胁到我们团队的目标达成。
02
03
04
1. 这个需求很简单,怎么实现我不管 2. 需求明细我没有,你照着竞品抄 3. 你先开始写代码,需求单我后面给你补 4. 写了一半的需求,又改了! ...
4.1 讨论前的准备
4.2 理解需求的本意
4.3 确认和对齐
4.4 评估工作量
1. 数据来自另一个团队,他们需要开发新接口把数据传给我,这里涉及到协议定制、代码开发、双方联调;我们可以先把协议对齐,然后两边用假数据并行开发,最后约定一个联调时间;这里预估 4 小时用来沟通协议和开发数据接入代码,4 小时用来联调接口; 2. 数据使用者要求对数据做简单的变换处理,譬如:把标题和内容拼到一起、给文档 id 加一个前缀,这部分需要在数据处理插件工厂里写一个处理插件,代码比较简单,预估 2 小时开发,4 小时代码评审; 3. 数据处理完后需要发送到消息中间件,供使用者订阅,我们有现成的配置化插件,只需要在业务 meta 配置里添加一段描述即可,预留 1 小时做配置; 4. 上线,我们有成熟的持续发布(CD)流程,预留 1 小时;
1. 合作方采用一种我们从没用过的新协议,调研新技术用了 2 天; 2. 虽然只有几十行代码,但是代码质量很差,导师给我做了三轮代码评审才通过,用了 1 天; 3. 需要写数据说明文档,详细描述数据有哪些字段,以方便众多使用者,用了 0.5 天;
1. 把大需求拆小,小到能以小时预估,拆小可以看得更透彻; 2. 一天以 8 小时或者 6 小时算工作时间,不要算上你的加班时间; 3. 不要在一段时间内并行做 N 个需求,需求之间切换有损耗,容易预估不准; 4. 预留 buffer 时间,可以是在你预估的时间上,再乘上一个系数,系数可能是 2 也可能是 1.3,你通过<计划-执行>来得到你的系数;
05
5.1 编码之前
5.2 注意事项
(1)大范围的修改需要多周知
(2)在需求开发中逐步重构
后来开发者(可能也是你)可以更快地增加功能,保持敏捷; 代码结构更清晰,不容易隐藏 bug;
(3)写好单元测试
(4)代码里的 TODO
(5)持续的练习
06
07
7.1 核心原则
汇报总结类的文档,通常建议采用《金字塔原理》,最重要的结论信息放在最前面,以上统下结论先行,读者可以先看到结论,然后再评估是否有必要阅读细节。譬如,新系统的性能压测文档,通常会把压测结论放在前面,后面的段落才介绍压测背景细节。 项目评审类的文档,通常建议开篇先介绍为什么要做这个项目,然后再按照<总-分>的思路介绍项目。譬如,我们写项目技术方案评审,通常在第一章量化的介绍目标,让读者可以第一时间看到项目的价值。
7.2 规范和培训
-End-
分享抽龙年红包封面!!转发本篇文章就能随机获得以下封面 1 个!限量50个,周四中午12点开奖!
📢📢欢迎加入腾讯云开发者社群,享前沿资讯、大咖干货,找兴趣搭子,交同城好友,更有鹅厂招聘机会、限量周边好礼等你来~
(长按图片立即扫码)