《代码的艺术》笔记

---

title: 《代码的艺术》笔记
date: 2020-02-22 22:20:35
categories:

• 代码
  tags:
• 整理

---

这周，看了下章淼老师的视频，写个笔记，做一些整理。微信公众号：章老师说，也可以关注了解下。个人感觉蛮好。

结合自身，我是软件工程专业毕业，理解软件工程师不等于码农，也不等同于程序员。举个例子，建房子，可以是平房也可以大厦，做个普通的平房一般的泥瓦匠可以完成，而摩天大楼则不光需要泥瓦工，还需要建筑设计师。这些设计师的图纸，既要满足功能性需求，也要有美感的要求。类比而言，软件工程师，需要思考得更加全面，而非仅仅是某个单一功能是如何完成的。虽然个人不喜欢夸夸其谈什么系统架构，但是视频中章老师谈及到系统架构，所以这里将其中有意思的部分分享出来。

系统架构是什么？

wiki定义

A system architecture is the conceptual model that defines the structure, behavior,and more views of a system.

系统架构描述的几个要素

• 静

  系统是如何组成，功能在这些组成部分之间是如何划分的。（这里如果想划分合理更像是领域驱动设计）

• 动

  各个系统如何联动，如何完成任务/流程。（系统子模块如何协作与交互）。

• 细

  不同的角度，更详细的刻画系统的全貌。（我理解是子模块内部是如何运作的，细化到方法）。

系统架构在不同层次的体现

• 总体设计
• 模块设计

系统设计的方法（要求）

1. 每个组件/模块的功能都应该足够专注和单一。（软件设计的单一职责原则）
2. 子系统/模块 关系简单清晰。（高内聚、低耦合）
3. 需求是系统设计决策的来源。（这里，我觉得软件工程师，不光得逻辑好，而且语文（哲学）也得好）
   • 在设计中，经常要做trade-off
   • 需求是决策的重要依据。
4. 模型/抽象的思维能力。
   • 思考的重点：概念、模型、数据结构、算法。
   • 需要脱离开代码的细节：函数、语言。（看到这里，想起来我实习的时候，带我的老阿里，他和我说，设计的时候不要想细节如何完成，因为详细设计里会有而且肯定可以实现。我想起，读书阶段看到的一个例子，比如说系统设计的时候，某个同学出门，不需要思考到他是如何出门的，是拉开门还是推开门还是别人帮忙用钥匙开门。）

延伸阅读（很赞！）

• 来自Google的3大系统的经典论文
  • GFS
  • BigTable
  • MapReduce
• 关注点
  • 如何描述问题和出发点
  • 如何描述模型
  • 如何描述系统设计
• 这里我只能记录个Action。因为上面的文章我也没有阅读过，后续读完也会写出来。

谈谈代码

代码是写给人看的，好的代码可以清晰的反应业务流程、设计思路。近期看了一些代码，憋出内伤，业务service里写大量的set变量，冲淡了真正的业务逻辑。Don’t make me think!

写程序是以数据为中心考虑，封装数据是一种必要的能力。我看到有的方法数据很难扩展，一个方法入参高达6、7个。

三个误区

1. 所有代码放在一个模块，是因为规模太小。

   反驳：切分模块的原则和代码规模没有关系。

2. 所有附加功能放到util包里。

   反驳：util的存在和模块划分的原则是矛盾的，至少要细化到fileUtil的粒度。

3. 从“过程”的角度出发考虑模块的划分

   反驳：首先从数据的角度考虑。

写好程序的秘诀

1. Bug往往出现在非常长的函数（方法）里。《代码整洁之道》中说，方法长度越短，生命周期越长。
2. 出现危险的根源，往往是过于自信

怎样修炼成为优秀的软件工程师？

一名优秀的软件工程师，是我的短期目标。章老师的分享里是这么写的。

一个好的软件工程师和以下因素没有必然联系。

• 写过多少年的程序
• 写了多少行代码
• 曾经在哪里上学、在哪里工作。

以下三个方面（当然，个人觉得有点大，需要落实的Action，不然很容易流于形式）

• 学习-思考-实践
• 知识-方法-精神
• 基础乃治学之根本（看来我还要再翻翻《Java编程思想》）

附录：延伸阅读中的文章

链接:https://pan.baidu.com/s/17Dc2VjWVkyL0iA51D4aUMA 密码:x1o8

最后，感谢章老师的分享。