写点什么

关于提高编程思维与工作效率的总结

用户头像
Android架构
关注
发布于: 1 小时前

这篇 blog 将一直持续的更新着。(2021.8.2)


工作提效


=====================================================================


  1. 时间管理大师


利用番茄工作法或类似方法,提高工作专注度,并且需要非常刻意的去练习,虽然这些方法不能适应到所有的情况,但是它们对每天工作的内容的的细致规划、以及频繁总结,都对工作提效起着很好的指导意义。本质上如下:


do {规划目标 + 专注完成} while (true)


  1. 目标导向而非职责导向


①:职责导向:作为团队中的一员,完成团队交予的任务,即完成自身职位所应该完成的任务。


②:目标导向:为了触达目标,除了完成自身任务,也要向上、下管理


两种导向有根本的区别,目标导向更能推动项目进行,在平时工作中,仅仅是职责导向,会被动、盲目,且最终可能达不到目标,而目标导向,可以把 60 分的事情,做到 90 分


  1. 交流与沟通


没有高效的沟通方式,因为每个人因为其局限性,都有自己不同的想法,即使在评审、会议中讨论了问题,也会有人不理解,并且不敢发言。


所以需要有足够的耐心,来与任何人讨论问题,在时间充足的情况下,面对面把事情聊的水落石出,才是“高效的交流”方式。


关于编写程序


=======================================================================


  1. 接到新需求后不从程序编写入手,而是从画流程图、类图入手,即个人的方案评审期


这样在写程序时,思路可以很清晰。


个人认为,能做好这些事情,反而能提高效率,而不是 more delay 和 more bugs。


  1. 多读源码,能懂一行是一行


读源码是自虐的行为,但是有很多行为能够帮助源码的阅读。


(1)跟着大佬解析源码,就是大佬的 blog/视频看到哪一步,你也跟着读到哪一步,一些晦涩的地方大佬们都会讲出来的


(2)从小的轮子读,比如加起来只有 四五个类的那种 做一个简单操作的 小轮子,里面也有很多可以学习的地方,自己也跟着做就更好,丰富自己的 blog 或者 github。


(3)学习设计模式对阅读源码很有帮助。


读源码的目的是为了达到 面向源码编程,打一个比方:同样是写一篇英文作文,别人是零散的单词和从句的东拼西凑,而你是直接带着一本字典,谁的理解更深不言而喻。


(4)对源码既定的流程,先思考一下,多问自己几个问题,再去阅读源码,效率特高


  1. 要有代码洁癖


要养成code smell的习惯,致力编写优美的代码。如果还没有养成这个习惯,建议每天起来写代码之前,都读一下最下面的 code smell。


  1. 代入产品的思维编程


因为我是一名前端开发人员,所以做的程序是直接呈现给用户的,我们在自测时最直观的感想其实就是用户的感想。“开发程序的时候我是程序员,自测时我就是用户”。这是一种把产品思维代入的编程。它会帮助我们更追求一些代码细节的东西。


比如我们会自己会为负责的模块写一套专门界面显示工具,我们任何的数据带到这个工具里面, 我们都能看到其最直观的工作流程,比起凭空想象的模拟数据工作方式,这更便于我们修改工作流程,这样做更直接而且有据可查,直接提升用户体验。(而且在 debug 时,这样的效率比打断点、打 log 更高!


关于改 BUG


=======================================================================


  1. 改 bug 有三种境界


第一种:错了哪里就改哪里。 这种对于开发效率是最低的。


第二种:错了哪里,就把整个模块 这份代码可能出错的地方 检察一遍有没别的错误。 这个开发效率稍微好一点。


第三种:错了哪里,基于第二种找出原因后,思考一开始为什么这么设计并记录下来,保证之后不再这个地方犯错。这样的思考对自己提高开发效率是最有帮助的。


  1. **要做


《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开:qq.cn.hn/FTe 免费领取
复制代码


到阶段性的 review 代码,然后优化**


改 bug 的唯一目的是增强程序的健壮性。所以优化也是改 Bug 的一种。


项目的收工并不代表之后不做这份代码了。做完后要找时间 review 一下代码,对 代码结构/用户反馈/或者自己的单元测试结果进行分析。自己主动的去优化


关于需求评审、多方交接


============================================================================


  1. 开发的任何细节都要有文档依据


大部分情况下,开发初期的需求文档并不是最终版本,而是会随着开发做一些小更新(小更新是 Ok 允许的,如果说开发还在大更新需求的话就是双方的严重失误(比如说更改逻辑))


这导致开发时的一些细节,会觉得:这个地方需求会没有考虑到,但是又不影响主流程,所以会自己发挥


但这其实很不严谨,任何的逻辑以及细节都要在 流程图里面过。所以一定要提出来。商讨出解决方案后第一时间更新到需求文档或者开发文档,这样可以保证出现问题时,锅绝对不在你身上。


(突然想到一个表情包,程序员最讨厌的四个事情:1.写文档 2.别人不写文档 3.写注释 4.别人不写注释, 人间真实)


  1. 如果在需求评审时,只是重点考虑到这个功能能不能实现,那其实这个评审会其实还是会给以后自己留坑。应该在之上,考虑到研发的新功能是否会影响已有的功能,如果影响到,影响的部分该怎么处理。这才是需求评审会时更该注意的一点。功能能不能做这个问题,只要你别来个根据手机环境来改变 App 主题颜色,那 tmd 肯定能做啊。


提醒自己的话


=======================================================================


  1. 总是写自己会的代码,错误肯定会少,但是同时学到的东西也不会很多。

  2. 如果自己不去努力的解决问题,那么自己也会成为团队里的问题。


读书会


====================================================================


  • 《影响力》

  • 《原则》


Code Smell(代码坏味道)


==================================================================================


  1. Duplicated Code(重复的代码)

  2. Long Method(过长方法)

  3. Large Class(过大的类)

用户头像

Android架构

关注

还未添加个人签名 2021.10.31 加入

还未添加个人简介

评论

发布
暂无评论
关于提高编程思维与工作效率的总结