读书笔记
程序员技能成长
代码审查
-
如何做代码审查
-
要有审查清单
-
代码结构
-
代码安全性
-
代码性能
-
代码注释
-
单元测试
-
代码优化
是否可以使用枚丽代替自定义的常量,在代码中是否包含魔法值,是
否可以使用 Optional 代替 NPE 的检查,是否可以使用 Stream 代替 for 循环,是否可以使用设计模式
-
其他
代码逻辑是否正确,是否实现了业务功能,代码是否有好的可读性及可测试性,等等。
-
-
要在日常开展代码审核
-
不要一次审查太多代码
- 做代码审查,每次审查的代码行数最好在 200 行以内,不超过 400 行,否则查找
代码缺陷的敁果就会大打折扣。
- 做代码审查,每次审查的代码行数最好在 200 行以内,不超过 400 行,否则查找
-
工作法则
- 工具化法则
- 案例:做一个能够自动打印历史请求的工其,然后通过工其平台将打印的请求重收到指定的服务器上,提升研发发效率
- 文档写多少
- 应该将文档整理成思维树,标注定义、兲键描述、兲键词、兲联词和详细的文档链接
- 可以提供工作效率的硬件
- 显示器
- 外设:鼠标、键盘等
加速成长与学会学习
-
程序员如何加速成长
- 积极主动:随着分工的细致化,程序员更要积极主动地去了解其他人所做的事情,只守着自己的‚一亩三分地,被动地工作,是无法成为一个优秀的程序员的。
- 空杯心态:空杯心态并不意味着要否定自己过去,而是怀着一种放空的态度融入新的环境,对待新的工作和事物
- 别怕犯错:最重要的是仍错误中学习到什么。
- 想清楚再做:对每个很小的需求都会写一份设计文档,在彻底想好如何做之后再开始写代码。
- 不设边界
- 技术也可以思考产品的方案。吃亏且多做了的事情,实际上是成长。
-
做业务如何成长
-
- 欣赏自己的成长:外部感知可能笔内部感知更慢
-
- 做个有心人:关注如何把事情、产品做得更好
-
-
学会学习
- 管理好自己的目标
- 目标管理:评估能力、指定目标、评估目标
- 最重要的事情只有1件事,同时只做1件事
- 管理好自己的目标
业务分析与设计
- 黄金圈法则:也叫做2W1H,为什么(Why)、怎么做(How)、做什么(What)
- UML建模工具
-
用例图
- 关系:包含(Include)、扩展(Extend)、泛化(Generalization)

- 关系:包含(Include)、扩展(Extend)、泛化(Generalization)
-
类图 :把用户根据用例图把参加抽象成磊,描述类的内部结构以及类与类之间的关系
-
对象图:一组对象之间的关系,而不是类之间的关系
-
状态图:一个特定对象所有可能的状态,以及各种时间引起的状态之间的转移和变化

-
活动图:是状态图的一种特殊图,其中的状态大多处于活动状态,本质是一种流程图,强调活动到活动的控制流

-
序列图:是交互图的一种,描述对象之间消息发送的先后关系,强调时间顺序。

-
协作图:是交互图的一种,描述了收发消息的对象的组织关系,强调对象之间的合作关系。

-
构件图:用来表示系统中构建与构建之间以及类或接口与构建之间的关系图

-
部署图:用于可视化部署软件的物理组件拓扑,并描述系统的静态部署视图
-
管理探秘
- 满意的工作从两件事开始,一是有明确的目标,二是有实现这一目标的可操作性步骤。
- 提供清晰的领导风格,并以信任感作为基石
- 第一遍任务详细介绍
- 让对方重复任务是什么
- 谈论任务的目的
- 明确风险和汇报标准
- 让对方发挥主观能动性
- 确定在做的事情符合自己的目标
- 确定自己究竟想要什么
- 把自己的目标写下来
- 为自己的目标设定一个最后期限,并让大家知道
- 将实现目标需要做的最重要的事情列出来
- 每天都做一些接近自己目标的事情
实践思考
-
内部在没有安排代码审查前,由于团队成员经验不同,导致经常出现一些简单弱智的代码,频繁被客诉。后续安排经验丰富的开发专责于代码审查,在这一步被拦截20%左右的bug;并能够在这一步推进团队代码文化建设。
-
团队每月安排1次代码走查,团队全员参加,平均每次排查出20左右问题。
- 优点:能够在出问题之前,提供通过审查代码的方式发现问题;
- 缺点:每次需要审查的修改点过多,需要一整天评审。时间长了,团队成员投入的精力就不足了。
- 后续改进:考虑由专家在每一周判断本周是否要发起代码评审,将时间周期缩短。
-
如何做好对上的预期管理
- 彻底理解需求
- 学会站在老板的角度理解KPI,求同存异
- 及时汇报

818

被折叠的 条评论
为什么被折叠?



