git版本控制 回忆上次内容
- 上次我们了解了 try 的完全体
- try
- 尝试运行
- except
- 发现异常时运行的代码块
- else
- 没有发现异常时运行的代码块
- finally
- 无论是否发现异常最终都要运行的代码块
添加图片注释，不超过 140 字（可选）
- 发现导入部分
- 可以再分为两个子模块
- 一个输入 a
- 一个输入 b
- 可以再拆分么？
观察结构
- 这是test目录目前的结构
添加图片注释，不超过 140 字（可选）
- 想把get_fruits.py再拆成两个
- get_apples.py - 输入apple数量
- get_bananas.py - 输入banana数量
尝试保存版本
- 再继续之前
- 先把 目前的test目录 备份起来
- 使用 git 进行版本控制
# 先进入test cd test # 观察位置 pwd # 初始化 git init #把目前apple文件夹下所有的都备份 git add . # 备份 git commit
- commit 遇到问题
- 你是谁的问题
问题
添加图片注释，不超过 140 字（可选）
- 提示需要用户名和邮箱
- 因为工程可能是个多人合作的
- 需要知道提交是谁做的
- 如何设置用户名和邮箱呢？
第一次提交
- 按提示录入邮箱和用户名
- 这邮箱和用户名
- 不一定是注册过的
- 只是一个标记
添加图片注释，不超过 140 字（可选）
- 然后git commit
- 第一次 提交
第一次提交的注释
- 终端会自动打开vim
- 要求对提交做注释
- 没有具体的要求
- 写点什么提示之类的就行
- 完成后:wq
- 退出
添加图片注释，不超过 140 字（可选）
- 这就把 代码目前的这个状态
- 备份下来了
- 这是 第一次提交
查看版本 #查看提交版本的日志 git log
- 目前有一个提交 commit
添加图片注释，不超过 140 字（可选）
开始修改
- 在test目录下
- 新建get_apples.py
添加图片注释，不超过 140 字（可选）
- :r get_fruits.py
- 读取get_fruits.py
- 到当前文件缓存
最终效果
添加图片注释，不超过 140 字（可选）
- 把输入模块再拆分
- 输入 apple数量 、get_apples.py
- 输入 banana数量 、get_bananas.py
- 调整输入函数
- 这样可以运行么？
尝试运行
添加图片注释，不超过 140 字（可选）
- 试验成功！
- 可以正确执行
- 但是这么写是有问题的！
- 为什么？
- 因为它不符合禅意
- 啊？
zen 禅
- Flat is better than nested.
- 扁平胜于嵌套
- 现在的控制结构:
- 中控 main
- 输入 get_fruits
- 输入 a
- get_apples
- 输入 b
- get_bananas
- 处理 process
- 输出 outprint
- 结构太多出现了三层
添加图片注释，不超过 140 字（可选）
- 好的程序是
- 并排很多的
- 而串起来的并不深
- 高内聚
- 低耦合
过度抽象
- 没有必要嵌套成三层
- 我们应该更多使用扁平
- 两层能轻松解决的
- 别弄到三层
- tcp/ip 四层就能搞定的事
- osi 非要搞到七层，一定不好做
- 层与层之间的接口是很容易固化的
- 这不是教条
- 而是实际开发中的经验
- 你见过那种层层传递过程中的繁琐和损耗么？
- 想回滚到初始状态(init)
- 还好做了版本控制
第二次提交
- 先把当前的这个修改提交了
git add . git commit git log
- 提交新Commit
添加图片注释，不超过 140 字（可选）
- 系统还是会自动开vim来记录本版本的注释
- :wq就可以保存注释
添加图片注释，不超过 140 字（可选）
- 完成第二次提交
查看两次提交
- git log
添加图片注释，不超过 140 字（可选）
- 我们可以看到有两次提交
- 第一次
- 红框以内
- 提交信息为 init
- 特征码为 3153a6e...
- 第二次
- 黄框以内
- 提交信息为 add two python files
- 特征码为 1f6de17...
回滚 #查看commit提交的简写形式 git log --pretty=format:"%h - %an, %ar : %s" #签出原来的提交 git checkout 第一次提交的特征码...
添加图片注释，不超过 140 字（可选）
- 然后再签出老的那个
- 3153a6e
前后对比
添加图片注释，不超过 140 字（可选）
- 硬盘回到初始状态了
- 新保留的分支 就不要了
- git 就是这样的 版本控制软件
- 可以恢复到
- 任何 commit 过的时间点
- 甚至是
- 任何人 在任何时间点 commit 过的版本
- 仿佛一个时光机
- 在不同时间和不同人提交的版本间穿梭
- 这次 为什么要 回到过去？
- 这次回去的 原因 是
- 扁平胜于嵌套
复杂
- 多余的层级
- 是 繁琐的
- 奢华繁复
- 是 堕落的开始
添加图片注释，不超过 140 字（可选）
- 追求 美之为美
- 孔雀为了美
- 进化到了什么样子
- 尾大不掉
- 这种美并不符合
- 客观规律
- 繁文冗节只会造成辞藻的堆砌
- 陷入到文字割裂的离散世界中去
- 可世界本是连续的
- 真善美中
- 真 排第一
美之为美
- 凡尔赛和圆明园
- 都不是 励精图治的审美
添加图片注释，不超过 140 字（可选）
- 金玉其外
- 败絮其中
- 金玉满堂
- 莫之能守
- 什么是能够自强的审美呢
简单
- 断舍离
- 枯山水
- 说的都是化缘
- 为道日损，损之又损，以至于无为
- 无为而无不为
添加图片注释，不超过 140 字（可选）
- 致虚极守静笃
- 为的是蓄势待发
添加图片注释，不超过 140 字（可选）
- 静观其变
- 要留白 才能作画
- 代码的演化 本身就是一种涅槃
- 消珥过去的自己
- 在迭代中获得新的生命
无为
- 为无为
- 才能 全面观察和蓄力
- 味无味
- 才能 有敏感的味觉
- 事无事
- 才能 有机敏的反应
添加图片注释，不超过 140 字（可选）
- 静下来 品味
- 禅茶一味
- 感觉是一致的
一致
- Explicit is better than implicit.
- 明了胜于晦涩（优美的代码应当是明了的，命名规范，风格相似）
- Simple is better than complex.
- 简洁胜于复杂（优美的代码应当是简洁的，不要有复杂的内部实现）
- Complex is better than complicated.
- 复杂胜于凌乱（如果复杂不可避免，那代码间也不能有难懂的关系，要保持接口简洁）
- Flat is better than nested.
- 扁平胜于嵌套（优美的代码应当是扁平的，不能有太多的嵌套）
- 以上说的都是一回事：
- 简单而且明确！
- 形成了上面的观念就会发现代码的美与丑
- 代码的审美来自于以上的判断
添加图片注释，不超过 140 字（可选）
- Beautiful is better than ugly.
- 优美胜于丑陋（Python 以编写优美的代码为目标）
- 审美僵化是 可怕的
- 保持 简单 且 明确
- 就可以保持 天真的状态
总结
- 使用了版本控制 git
- 制作备份
- 进行回滚
- 尝试了 嵌套的控制结构
- 层层 控制
- 不过 非到不得以
- 尽量不要 太多层次的嵌套
- 虽然这样 从顶到底
- 含义 明确
- 扁平 难道就不能
- 含义明确么？
- 还可以 做点什么？
- 让程序更加明确呢？
- 我们下次再说！
- 蓝桥->https://www.lanqiao.cn/courses/3584
- github->https://github.com/overmind1980/oeasy-python-tutorial
- gitee->https://gitee.com/overmind1980/oeasypython