《程序员的三门课:技术精进、架构修炼、管理探秘》读书笔记

读书笔记

程序员技能成长

代码审查

  • 如何做代码审查

    • 要有审查清单

      • 代码结构

      • 代码安全性

      • 代码性能

      • 代码注释

      • 单元测试

      • 代码优化

        是否可以使用枚丽代替自定义的常量,在代码中是否包含魔法值,是

        否可以使用 Optional 代替 NPE 的检查,是否可以使用 Stream 代替 for 循环,是否可以使用设计模式

      • 其他

        代码逻辑是否正确,是否实现了业务功能,代码是否有好的可读性及可测试性,等等。

    • 要在日常开展代码审核

    • 不要一次审查太多代码

      • 做代码审查,每次审查的代码行数最好在 200 行以内,不超过 400 行,否则查找
        代码缺陷的敁果就会大打折扣。

工作法则

  • 工具化法则
    • 案例:做一个能够自动打印历史请求的工其,然后通过工其平台将打印的请求重收到指定的服务器上,提升研发发效率
  • 文档写多少
    • 应该将文档整理成思维树,标注定义、兲键描述、兲键词、兲联词和详细的文档链接
  • 可以提供工作效率的硬件
    • 显示器
    • 外设:鼠标、键盘等

加速成长与学会学习

  • 程序员如何加速成长

    • 积极主动:随着分工的细致化,程序员更要积极主动地去了解其他人所做的事情,只守着自己的‚一亩三分地,被动地工作,是无法成为一个优秀的程序员的。
    • 空杯心态:空杯心态并不意味着要否定自己过去,而是怀着一种放空的态度融入新的环境,对待新的工作和事物
    • 别怕犯错:最重要的是仍错误中学习到什么。
    • 想清楚再做:对每个很小的需求都会写一份设计文档,在彻底想好如何做之后再开始写代码。
    • 不设边界
      • 技术也可以思考产品的方案。吃亏且多做了的事情,实际上是成长。
  • 做业务如何成长

      1. 欣赏自己的成长:外部感知可能笔内部感知更慢
      1. 做个有心人:关注如何把事情、产品做得更好
  • 学会学习

    • 管理好自己的目标
      • 目标管理:评估能力、指定目标、评估目标
    • 最重要的事情只有1件事,同时只做1件事

业务分析与设计

  • 黄金圈法则:也叫做2W1H,为什么(Why)、怎么做(How)、做什么(What)
  • UML建模工具
    • 用例图

      • 关系:包含(Include)、扩展(Extend)、泛化(Generalization)
    • 类图 :把用户根据用例图把参加抽象成磊,描述类的内部结构以及类与类之间的关系

    • 对象图:一组对象之间的关系,而不是类之间的关系

    • 状态图:一个特定对象所有可能的状态,以及各种时间引起的状态之间的转移和变化
      在这里插入图片描述

    • 活动图:是状态图的一种特殊图,其中的状态大多处于活动状态,本质是一种流程图,强调活动到活动的控制流
      在这里插入图片描述

    • 序列图:是交互图的一种,描述对象之间消息发送的先后关系,强调时间顺序。
      在这里插入图片描述

    • 协作图:是交互图的一种,描述了收发消息的对象的组织关系,强调对象之间的合作关系。
      在这里插入图片描述

    • 构件图:用来表示系统中构建与构建之间以及类或接口与构建之间的关系图
      在这里插入图片描述

    • 部署图:用于可视化部署软件的物理组件拓扑,并描述系统的静态部署视图

管理探秘

  • 满意的工作从两件事开始,一是有明确的目标,二是有实现这一目标的可操作性步骤。
  • 提供清晰的领导风格,并以信任感作为基石
    • 第一遍任务详细介绍
    • 让对方重复任务是什么
    • 谈论任务的目的
    • 明确风险和汇报标准
    • 让对方发挥主观能动性
  • 确定在做的事情符合自己的目标
    • 确定自己究竟想要什么
    • 把自己的目标写下来
    • 为自己的目标设定一个最后期限,并让大家知道
    • 将实现目标需要做的最重要的事情列出来
    • 每天都做一些接近自己目标的事情

实践思考

  • 内部在没有安排代码审查前,由于团队成员经验不同,导致经常出现一些简单弱智的代码,频繁被客诉。后续安排经验丰富的开发专责于代码审查,在这一步被拦截20%左右的bug;并能够在这一步推进团队代码文化建设。

  • 团队每月安排1次代码走查,团队全员参加,平均每次排查出20左右问题。

    • 优点:能够在出问题之前,提供通过审查代码的方式发现问题;
    • 缺点:每次需要审查的修改点过多,需要一整天评审。时间长了,团队成员投入的精力就不足了。
    • 后续改进:考虑由专家在每一周判断本周是否要发起代码评审,将时间周期缩短。
  • 如何做好对上的预期管理

    • 彻底理解需求
    • 学会站在老板的角度理解KPI,求同存异
    • 及时汇报
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

庄隐

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值