:::info 《代码大全》也可以当做程序开发者的 Bible 来查阅了。 :::
这里摘录一些我在阅读这本书的收获,与君共勉 ~ —— 2021-05-20
- 理解了标准软件的构建过程
- 理解使用隐喻(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 的最佳点,牵动业务快速成功。