【开发随记】【提效】工作习惯那些事系列之四——任务处理
- 作者简介：花神庙码农（专注于Linux、WLAN、TCP/IP、Python等技术方向）
- 博客主页：花神庙码农 地址：https://blog.csdn.net/qxhgd
- 系列专栏：开发随想
- 如觉得博主文章写的不错或对你有帮助的话，还望大家三连支持一下呀！！！ 关注✨、点赞、收藏、评论。
- 1、背景
- 2、指导思想
- 3、方法论
- 1）开发之前
- 2）开发过程
- 过程数据
- 质量层面
- 3）开发完成
- 任务本身
- 总结提升
- 4）风险预警
- 有些人做完一个开发任务，磁盘不会有任何痕迹留下，过后一问三不知（设计方案、修改内容、测试情况），具体改了什么只能去代码仓库查，大有“天空不留下鸟的痕迹，但我已飞过”的赶脚，看似很潇洒，但对个人的技术成长、后期故障查证及复盘是非常不利的。
- 之前的文章【开发随记】【提效】工作习惯那些事系列之四——任务管理 关注如何处理多任务的情形，而本文将会探讨如何高效正确的完成任务，请各位大神批评指正。
- 开发前要澄清需求、明确方案；
- 开发时要注意记录过程数据；
- 开发完要注意总结、升华；
- 各阶段涉及的风险（时间、质量）等要及时反馈；
这一步相当重要，所谓磨刀不误砍柴工，千万不要一上来就去撸代码。
- a、需求：
– 首先要读懂需求，知其然，更要知其所以然，此阶段可参考业界的常用做法，如SBE、MFQ、脑图等； - b、方案：
– 需求明确后，要考虑具体的技术方案，复杂的方案可以和团队的TL、Leader、或者老司机讨论，一般可按下面思路来设计方案：
- 以前是否有类似的方案可复用或借鉴？如果有，首先考虑沿用以往方案，细节上的差异可通过参数、配置等方式兼容；
- 如无现成方案可用，优先考虑把该方案做成一个通用的方案，所谓前人栽树后人乘凉；
- c、评估影响范围及开发周期：
– 影响范围：该方案会影响某一款产品还是N款产品？影响哪些功能？
– 开发周期：是否可以按项目要求如期完成？
- 注意记录过程数据，包括之前讨论的需求细节、实现方案、新旧代码对比、测试方法及调试命令、测试过程、结果及对应日志、截图等；
- 测试要覆盖自己的修改点及前面分析的影响范围，如不具备测试条件，和项目反馈；
- 合库之后要取库里版本自测，避免漏合；
- 有些人代码入库后，就万事大吉了，没有任何的动作了，有些遗憾；
- 如果在开发完成后，做个总结，那么对自己的成长会比较有帮助，同时也便于后续的追溯、参考等；
- 代码
– 新旧代码对比 - 文档
– 方案的细节；
– 关键代码流程梳理；
– 测试步骤及相应配置、调试命令；
– 测试结果：测试了哪些条目、哪些产品、性能类要记录下性能数据、必要的截图等；
– 测试日志、抓包等；
- 将本任务涉及的代码流程、调试命令、配置方法等总结好，汇总到自己的知识库（如eDiary、WiKi之类），如果团队或部门有相关的信息空间，也可以同步补充进去；
- 开发调试过程的一些经验、教训，也可以一并整理出来；
- 该方案如比较典型、可提取成最佳实践、专利等；
- 在上述任何一个阶段，如果觉察到风险（时间风险、质量风险），一定要第一时间向项目反馈，千万不要等到交付日期才提，黄花菜都凉了。
如果你有更好的操作方式，欢迎在本文下方留言；
如本文对你有些许帮助，欢迎大佬加关注、评论、点赞、收藏；
您的支持是我持续创作的动力。
