今日总结
上午复习了上周的docker知识，并顺利完成了上周作业。并编写了
readme ，但是在push到github上时出现了各种奇怪的问题，还待解决。
我的github博客
下午有部门经理来进行了我们研发中心的情况介绍，重点在于开源的企业级PasS平台，猪齿鱼开源社区。
敏捷开发
之后介绍敏捷开发的相关知识：
学习敏捷，构建高效团队。团队合作至关重要。
传统软件开发方式存在很多问题，如瀑布式开发是前置设计模式的。
- 需求不清晰，容易分析瘫痪。但是实际情况下，需求常常变化
- 需求常常变化会带来各种各样的问题，客户得不到想要的东西
- 这样会导致项目时间越来越长
- 没有时间测试，质量无法得到保证
敏捷开发适合大部分软件项目，不适合结构化的项目，比如造房子。
价值观：
1.个体和互动高于流程和工具
2.工作的软件高于详尽的文档
3.客户合作高于合同谈判
4.响应变化高于遵循计划
敏捷原则
交付项目
1.尽早交付有价值的软件
2.欣然面对需求变化，即使是在开发后期
3.频繁交付软件，周期越短越好。
推进项目：
1.可工作的软件是衡量进度的首要标准
2.可持续开发
3.追求技术和设计卓越。
Scrum进行敏捷开发管理
自组织和集体承诺
目标：可见-检查-调整，来管理复杂性和变化
角色列表：
1.产品所有者（PO）：项目愿景所有者/客户代表
2.开发团队：定义任务，预估工作量，开发产品，确保质量
3.ScrumMaster 服务型领导，团队保护者
Scrum站立会：
昨天做了什么？今天准备做什么？
15分钟以内，站着开会（不说废话）
避免90%完成，**DONE**最重要
冲刺评审会：
非正式，可以邀请感兴趣的人一起讨论。
只展示完成的该功能特性
更有趣，更快乐的团队。
极限编程（XP）
代码异味
1.代码重复
2.长方法
3.太多参数
4.超长标识符..
代码重构：增加可读性优化，并不影响输出结果
推荐书籍
凤凰项目--偏小说
CI持续交付，发布可靠软件的系统方法
晚上
听同学分享上周作业的完成情况，发现大家遇到的问题我也遇到过，好在最后都在查阅资料中解决了。我发现博客的修改和配置都没有怎么提到，自己也没有很注意。还要继续加强学习。
Enumerating objects: 72, done.
Counting objects: 100% (72/72), done.
Delta compression using up to 4 threads.
Compressing objects: 100% (53/53), done.
Writing objects: 100% (70/70), 848.39 KiB | 12.66 MiB/s, done.
Total 70 (delta 20), reused 0 (delta 0)
error: RPC failed; curl 56 OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054
fatal: The remote end hung up unexpectedly
fatal: The remote end hung up unexpectedly
Everything up-to-date
上述的问题是缓存区过小，下着下着网断了，需要使用ssh进行。使用
$ git remote set-url origin [email protected]:Suzuku/07-15.git
重要： 不仅readme.md需要，.gitignore也很重要，上面的内容是不需要上传到github上的内容。下次作业记得提交