:::info 《代码大全》也可以当做程序开发者的 Bible 来查阅了。 :::

这里摘录一些我在阅读这本书的收获,与君共勉 ~ —— 2021-05-20

image.png

  • 理解了标准软件的构建过程
  • 理解使用隐喻(Metaphor)对软件研发的重要性,使用隐喻让工程师更容易理解,让编码的结构和设计更加好理解,一直强调「概念一致性」对于团队的重要性。
    • 比如最近团队一直在强调「模块化」的概念,但是我相信每个人眼中对模块化的理解都是差异出入很大的,所以需要设计文档,概念文档,拉齐特定范围内的认知。
  • 三思而后行,编码和程序设计一直在强调这个点
  • 不同的系统做了分类:商业系统、使命攸关的系统、性命攸关的系统
    • 前者强调速度和快速适应变化,后者强调形式验证和稳定安全,所以对应的软件研发的手段和策略会大相径庭,互联网的绝大部分系统都是商业系统
  • 需求变更的高成本效益必须被强调
    • PD 们,变更需求就必须打钱 😎💰
  • 大于 200 行的 Function 体(子程序),超过请务必小心其引入的复杂性和维护成本问题。

    防御式编程

防御式编程:I/O 保护、断言、异常处理、隔离和降级。错误处理预期会发生的错误,断言来处理绝对不应该发生的错误。考虑断言后续如何在前端项目中使用,尤其是底层库值得后续思考 & 设计。

React 源代码里面的 invarant() 就是一个典型 Case

如何优雅地替换 if-else

表驱动法:直接访问表索引访问表阶梯访问表(适当使用二分查找) —— 一种编程模式 Programming Scheme,用于查找替换 if-else。

而设计模式和重构中所提及的:以多态取缔条件表达式 Replace Conditional Expressions via Polymorphism 也是一种替换思路。

寻找缺陷的艺术

一般修复缺陷的过程是:

  • 将错误稳定下来(可稳定复现)
  • 确认错误的来源(查到根本原因)
    • 收集缺陷的数据
    • 分析数据,提出假设
    • 确认如何证实这个假设,并进行测试和检查源代码
    • 给出最终结论
  • 修复缺陷
  • 补充测试
  • 检查是否还有类似的错误

一些寻找缺陷的有趣 Tips:

  • 控制好心态和节奏,不要蛮力解问题,有时候抛开问题,休息一下会有奇效
  • 构造假设的时候考虑所有可用数据
  • 用好调试工具提升查找效率,对源代码进行二分查找是一个比较好的套路
  • 尝试采用不同的方式重现错误,因为很多时候错误的原因不是单因子的
  • 检查近期修改过的代码范围
  • 不要一开始就怀疑是平台层或者中间件等稳定部件的问题,先从业务开查

优化运行速度

需要明白:「不是任何程序都应该去追求极致速度」,应根据 2/8 原则,用好 Profiler,集中优化最关键的部分。

一些性能优化的伎俩:

  • 根据概率,来调整判断顺序
  • 使用查询表来代替复杂表达式
  • 使用惰性求值 Lazy Evaluation
  • 循环展开和合并,尽可能减少循环内做的事情
  • 用好索引和缓存机制
  • 设计巧妙的数据结构,比如:整数型优先,降低数组维度等
  • 利用好恒等代数式做变换,优化复杂表达式
  • 使用查询表(预计算出结果)削弱硬计算强度,比如:sin(x)
  • 使用低级语言重写高性能实现
  • 关注集成

  • 集成的方式需要关注 => 阶段式、增量式等等都需要关注实现模式

  • DevOps:YYDS 😎,持续集成,稳步快跑,适合敏捷模式
  • 增量集成的模式:自顶向下,自底向上,三明治,T 型等等,找到合适的集成方式

编程工具:或不可缺

  • IDE、Diff & SourceControl、Linter、Documentation、Scanfold
  • 设计工具:UML、Sketch、Draw.io
  • 质量管理工具:Metrix Reporter 质量报告工具,性能分析器,内存管理 & 监控
  • 反汇编工具
  • 项目特有插件,VSCODE plugin ~ 多写一写解决真正的业务问题。
    • 比如之前做过一个针对搭建平台的代码同步编辑 Chrome 插件,就挺有意思的!

程序员分级

书里面聊到了程序员的分级模式:

  • 入门级(P5 及其以下):入门者会利用某种语言的基本功能,编写类、子程序、循环和条件等,会使用语言的基本功能解决业务问题。
  • 中级:度过了入门期,能够得心应手地操作语言完成编程任务。
  • 熟练级:对语言和环境有着更深层次的技能,是一些能够精通 J2EE 盘根错节的设计,或者是把 Advanced C++ Ref Manual 如数家珍。这些程序员往往在公司是「活宝」,很多程序设计师再也无法超过这个层次。
  • 技术带头级:具备第三级的专业技能,真正明白和人,和业务打交道的重要性。一般只花费 30% 的时间单独工作,和计算机打交道的时间则更少。技术带头人,会为人写代码,而非为机器。真正高手所写的代码,像水晶一样晶莹剔透,还有配套文档。他们可不会浪费宝贵的脑力,去重新组织用一句注释就可以说清楚的某块代码逻辑

结合下面 👇 聊到的问题分层思路,其实技术带头级别的人更需要关注 L3 ~ L4 结构的设计,面向人编程!而一些专业属性强的角色,也就是团队的手术刀,需要去钻入 L0 ~ L2 的基础建设中。

编程匠艺

  • 征服复杂性
  • 为软件开发选择合适的开发过程
  • 为人写程序,而非计算机
  • 深入一门语言去编程,而非停留在表面
  • 借助规范、模式和原则等等集中注意力
  • 基于问题域编程,将问题分离为不同的层次去治理,书里面给了一种问题分层抽象的思路
    • L0操作系统和机器指令级
    • L1编程语言结构和工具级
    • L2低层 LowLevel 结构(基础数据结构、算法、工具)级,对现在而言,更像是库、框架、中间件等技术结构
    • L3低层问题域,更像是业务技术和基础技术的连接层,为业务上层提供解决方案的基础能力,可以表现为业务框架、业务中台、DDD 域服务和抽象等等
    • L4高层问题域,提供了对具体的问题的抽象能力,高效解决具体的业务问题。
  • 对于长生命周期的项目,在迭代之中,不断进化自己,无论是技术还是业务,逐渐认清本质,抽离不变性
  • 适当地采取「技术折中主义」,在不断权衡中,找到 ROI 的最佳点,牵动业务快速成功。