百度AI工程师训练营

人工智能海洋学 是机器人吗？

祝万事顺利！

祝学习一切顺利，尽管走一遍。

百度AI工程师训练营，AI的开始！

飞桨

最开始是想学前后端，但是发现自己不是很喜欢前后端，后来又接触到一点人工智能，就比较感兴趣，尤其是图像识别，机器学习和深度学习，加上比较喜欢数学，所以更希望学一些这方面的知识，不过是零基础，这一个月也有课设，但是我会尽量跟着老师和各位大佬学习的，希望最后的项目可以跟大家一起做完，不求拿奖，重要的是积累经验，加油！

推荐贾壮的深度学习一书，很适合入门

软件设计的目的： 为了使软件在长期范围内能够容易的进行变化；

软件设计原则：高内聚  低耦合；

Clean Code

单元测试：更早发现问题+更容易集成+更安全的代码修改

重构：1.业务导向  2.小步快跑（主干、分支）3.演进式设计 4.正交设计原则

配置化架构

产品目标：1.满足用户诉求是产品的基础功能

                 2.好的产品目标是具体的、可衡量的、相对稳定的

研发工具链：

1. 用“精益”指引产品规划
2. 用“敏捷”加速迭代开发
3. 用“数据”驱动持续改进

持续化交付：持续交互是一个完全自动化的过程，当业务开发完成的时候，可以做到一键部署。持续交付提供了一套更为完善的解决传统开发流程的方案。

百度AI工程师训练营 

训练营笔记Day1

一、软件设计原则

1. 软件设计的目的：使软件在长期范围内能容易的进行变化，可从变化、容易、长期三个方面解读。变化，即软件的需求和所依赖的其它资源都是一直在变化的；容易，即尽可能降低变化的成本；长期，即需要更好的软件设计来应对长期的软件维护。

2. 软件设计原则：高内聚，低耦合（紧密相关联的元素放在一起，单位之间尽可能少的关联）

二、Clean Code

1. 概念：直译为整洁代码，即代码要在尽可能短的时间内被别人读懂，且具有排版整洁、逻辑清晰、扩展性好等特点

2. 命名规则

3. 注释：版权信息、设计意图、警示信息

4. 函数：分为骨架函数（业务逻辑和算法的高层抽象）和步骤函数（业务逻辑和算法的实现细节）

5. 编码细节：使用自然的比较顺序，简化逻辑层次，不出现过于复杂的逻辑条件，控制变量的作用域

三、单元测试

1. 优点：更早发现问题，更容易集成，更安全的代码修改

2. 重要性：

3. 原则与模式：

四、重构

1. 业务导向：重构是为了解决实际业务问题

2. 小步快跑：随时对比主干与分支的情况，将代码分成多个小问题进行修改

3. 演进式设计：遵循高内聚低耦合、正交设计原则、SOLID原则

4. 正交设计原则：分离关注点，消除重复，缩小依赖的范围，向着稳定的方向依赖

五、配置化架构

1. 定义：以可配置的方式构建软件的方法，是在领域建模的基础上以配置表述业务和组织架构元素（如服务、组件、数据等）

2. 应用方法：

（1）业务配置化改造：组件配置化→构建DSL（Domain Specified Lanuage)

（2）提高配置的开发效率

（3）降低配置的维护成本：使部署、数据版本、业务属性、架构描述四个不同维度间的参数能够共用；配置支持合并；减少冗余信息；消除信息重复；使用默认配置值

飞桨官方的动手学习深度学习还是很值得推荐的

希望编程能力有大进步，能力大增进，但不想掉头发！

打卡第一天

哪里报名？

祝一切安康

打卡第一天

百度高效研发实战训练营
Step1
设计方法与实践介绍脚本
软件设计原则：
软件设计目的：使软件在长期范围内能够容易地进行变化
软件设计原则：高内聚，低耦合

高内聚：紧密相关联的元素要放在一起

低耦合：单位之间尽可能少的关联
clean code
1.概念：代码能够在尽可能短的时间内被别人读懂，排版整洁、逻辑清晰、扩展性好

2.命名规则：

表达是什么，不表达怎么做；
自注释；
使用有意义的循环迭代变量；
避免（尤其拼音）缩写；
不要使用非约定俗称的缩写；
避免使用魔法数；
不害怕长变量名
3.注释

好的注释一般包含：版权信息、设计意图、警示信息

不好的注释（一个或多个特点）：

同义反复；
隐晦关联关系；
套用模板；
提供历史修改记录；
注释掉的代码
4.函数（一般是被隐藏起来的）

每个函数只做一件事，每个函数都是单一职责的
骨架函数：业务逻辑和算法在高层次上的抽象描述

步骤函数：业务逻辑和算法的实现细节

5.编码细节

使用自然的比较顺序
简化逻辑层次，避免多层嵌套
三元表达式不出现复杂的逻辑和过长的条件
控制变量的作用域，越小越好
单元测试
测试（底层-高层）：单元测试、基于模块和组件级的测试、基于系统级的测试
单元测试：更早发现问题；更容易集成；更安全的代码修改

单元测试原则与模式：

原则：

将单元测试视为文档工作
自检性
不可破坏性
间接性
网络安全性
定位缺陷
用写代码的方式进行测试
快速且可重复
模式：

四部测试法
状态验证与行为验证法
双重测试法
重构
业务导向：为了解决实际的业务问题而重构

‘小步快跑’

演进式设计

正交设计原则

配置化架构
定义

以可配置的方式构建软件的方法。在领域键模的基础上，以配置表述业务，以配置组织架构元素（服务、组件、数据登），进行规范化、自动化的管理
应用配置化架构

业务配置化改造

组件配置化
构建DSL（Domain Specified Language）
提高配置的开发效率
降低配置的维护成本

部署、数据版本、业务属性、架构描述四个不同维度间参数共用
配置支持合并
减少冗余信息
消除信息重复
使用配置的默认值
高效研发流程脚本
1.从产品目标到产品路线图

满足用户诉求是产品的基础职能
产品的目标：收益、市场份额、流水（考虑产品的商业模式和所处的阶段）
好的产品目标：具体的、可衡量的、相对稳定的
2.从产品路线图到发布计划

用户故事地图

一步一步写出故事
组织情节
探索替代故事
提取故事地图的主干
且分出能达成特定目标的任务
指定发布计划

Big Story进行细化讨论
按照价值和重要程度进行版本规划
确定每个版本的期望达成目标
确定每个版本的内容
团队达成公式
3.从发布计划到迭代计划

集中发布式模式：一次发布，四次迭代，一次版本
用户故事拆分
用户故事优先级
用户故事估算（工作量的估算）
迭代计划指定
4.从迭代计划到迭代的落地执行

研发工具链介绍
iCafe（用精益指引产品规划）项目管理工具

需求管理

最好：用户故事地图高效管理方式

迭代计划

进度跟踪

站会
卡片墙
燃尽图
持续改进
iCode（用敏捷加速迭代开发）代码管理工具

基于主干的工作流
基于分支的工作流
评审：

代码扫描
持续集成
人工评审
iPipe（用数据驱动持续改进）交付平台

固化端到端的交付流程
插件化现有工具（maven、docker、jenkins、git）和服务
数据度量驱动过程改进
持续交付方法与实践
持续交付的原因：
传统软件交付的问题和困境：

表现层：

进度不可控

流程不可靠

环境不稳定

协作不顺畅
根源上：

分支冗余导致合并困难

缺陷过多导致阻塞测试

开发、测试、部署环境不统一导致的未知错误

代码版本提交混乱无法回溯

等待上线周期过长

项目部署操作复杂经常失败

上线出现问题需要及时回滚

架构设计不合理导致发生错误之后无法准确定位等

软件交付能力指标：

仅涉及一行代码的改动需要花费多少时间才能部署上线（核心指标）
开发团队是否在以一种可重复、可靠的方式执行软件交付
怎么做：
使用持续交付方法
持续交付、持续集成、持续部署
构建一个可靠可重复的流水线
使用交付流水线落地方案和工具

落地方案：GoCD、Jenkins、Spinnakeer

工具：iPipe
持续部署：

容器技术：持续部署方案

Kubernetes + Docker
Matrix
部署原则：

部署包全部来自统一的存储库
所有的环境使用相同的部署方式
所有的环境使用相同的部署脚本
部署流程编排阶梯式晋级，在部署过程中设置多个检查点，一旦发生问题可以有序地回滚
整体部署由运维人员执行
仅通过流水线改变生产环境，防止配置漂移
不可变服务器
蓝绿部署或金丝雀部署

蓝绿部署：新旧两个部署版本，通过域名解析切换的方式切换到新版本，出现问题快速回滚
金丝雀部署：新版本让少量的用户使用，出现问题及时处理重新发布
部署层次（不是部署一个可工作的软件，而是部署一套可正常运行的环境）

Build：将软件编译形成RPM包或Jar包
Ship：将所需的第三方依赖和插件安装到环境中
Run：在不同的地方启动整套环境
 

学习