代码的艺术

代码的艺术

---

概述

• 章淼《代码的艺术》分享会后笔记、感悟、理解
• 微信公众号：章老师说

---

前言

• 动机（Motivation）

• 写代码，学校和公司有很大的不同

  • 学校的代码不符合公司规范
    • 教科书上的函数方法命令命名很随意
    • 如：myFunction()，这个方法做了什么，通过方法名称无从知晓
  • 公司的代码规范是共用

• 码农35岁转管理的误解

  • 很多软件工程师没有做长线的职业规划
  • Go语言的开发者半百之后才创建这种语言

• 互联网公司应该加班加点

  • 不，国外的公司不加班，但依然高效
  • 不是加班就等于高效

• 明确修炼的方向

  • 很多人工作五六年后无方向，不知道如何成长
  • 不是没有时间学习，更多的是不知道学习什么

• 我们是软件工程师，不是码农；我们不是在编码，而是在改变世界

  • Software Engineer
  • RD ：Research and Development

---

第一节 概念

• 代码的艺术
  • 何为艺术
  • 编码是非常具有创造性的工作
  • 代码是人类智慧的结晶
• 培养方向
  • 编码
  • 项目管理能力
  • 设计能力
  • 技术
    • 编码能力、数据结构、算法
    • 数据结构、操作系统、分布式系统
  • 产品
    • 对业务的理解，交互设计，产品数据统计
  • 项目管理
    • 80%的人不会写代码
    • 90%不会写文档
      • 设计文档没有推理过程
    • 95%不会做项目管理
  • 研究和创新
    • 研发工程师
    • RD ： Research and Development
    • 但大多数开发都缺少 Research 研究，缺少学习的时间，没有学习的动力

举例：
项目研发过程中，产品开需求评审会
1.开发开始设计表，讨论各种技术实现的难度或细节
2.开发没有详细讨论每个逻辑，没有逐个分析每个业务逻辑是否走得通
3.开发过程中发现原本以为很简单的逻辑，突然走不通了，此时再去想解决方案，可能导致之前的代码重新开发
改进：
1.项目需求评审过程中不要以技术实现不了或目前系统不支持来干预或打断产品的设计思路，而是从一个用户的角度出发，考虑产品设计是否合理
2.系统设计文档，包括逻辑流程图、系统架构图、表结构设计文档

• 艺术的解读

  • 艺术，解读的角度
  • Coding is not so easy

• 编码过程

  • 从无序变为有序
  • 从现实世界的问题转化为数字世界的模型
  • 一个认识的过程，从未知变为已知

• 编码能力

  • 把握问题的能力
  • 建立模型的能力
  • 沟通协作的能力
  • 编码执行的能力

• 编码需要建立品味

  • 对自己写的很烂的代码无感，自己觉得很不错

---

第二节 实践

• 知道了概念，但如何去做

  • 实践

• 一流代码的特性

  • 正确：Solid and Robust
  • 高效：Fash
  • 简洁：Maintainable and simple
  • 简短 Small
  • 共享 Re-usable
    • 可复用
  • 可测试 Testable
  • 可移植 Portable
  • 可监控 Monitorable
  • 可运维 Operational
  • 可扩展 Scalable & Extensible

• 总结归纳

  • 正确和性能
  • 可读和可维护
  • 共享和重用
  • 运维和运营

• 不好代码的表现

  • 方法名称见名不知意
    • do()
  • 变量名称
    • a,b,c
  • 没有注释