1. 行为准则2. 管理者是做什么的2.1. 与你的管理者构建工作关系将有助于你发展你的职业生涯、减少压力，甚至交付可靠的软件2.1.1. 必须了解你的管理者需要什么，这样你才能帮助他们2.2. 管理者们似乎总是在开会，但他们实际上在做什么并不明显2.3. 工程经理的工作是关于人、产品和流程的2.4. 管理者们构建团队、指导和培养工程师，并进行人际关系的动态管理，工程经理还计划和协调产品的开发2.5. 管理者通过与高管的关系和沟通进行向上管理2.6. 管理者是普通工程师和负责商业决策的高管之间的沟通渠道，向上管理对于获得资源（资金和工程师）以及确保你的团队可以得到认可、赞赏和倾听至关重要2.7

1. 可演进的API1.1. 随着需求的变化，你需要改变你的API，即代码之间的共享接口1.2. 改变API很容易，但很难做到正确1.3. 保持API小巧1.3.1. 小巧的API更易于理解和演进1.3.2. 只添加即刻需要的API方法或字段1.3.3. 带有许多字段的API方法应该有合理的默认值1.3.3.1. 开发人员可以只专注于和自己相关的字段，因为它们会继承其他字段的默认值1.3.3.2. 默认值可使大型API在感觉上很小巧1.4. 公开定义良好的服务端API1.4.1. 切记使用标准工具来定义服务端API1.4.1.1. OpenAPI通常用于RESTful服务1.4.1.2. no

1. 行为准则2. 需求的不确定性2.1. 不断变化的客户需求2.2. 软件项目无法避免的挑战2.3. 产品需求和环境会随着时间的推移而改变，你的应用程序也必须随之改变2.4. 不断变化的需求会导致不稳定性，使开发工作偏离轨道2.5. 通过构建可演进的架构来适应不断变化的需求2.5.1. 可演进的架构可避免复杂性，复杂性是演进性的敌人2.5.2. 矛盾的是，在软件中实现简洁性会很困难3. 复杂性3.1. 复杂系统的特点3.1.1. 高依赖性3.1.1.1. 致软件依赖于其他的API或代码行为3.1.1.2. 依赖性显然不可避免，甚至是可取的，但必须取得平衡3.1.1.3. 高依赖性的系统很难修

Readingpackagelists...DoneE:Failedtofetchhttps://mirrors.ustc.edu.cn/ubuntu-ports/dists/focal/main/binary-amd64/Packages404NotFound[IP:2001:da8:d800:95::110443]E:Failedtofetchhttps://mirrors.ustc.edu.cn/ubuntu-ports/dists/focal-updates/main/binary-amd64/Packages404NotFound[IP:2001:da8:d800:95::11044

先上效果👇代码在下面，流程我放最下面了，思路就是创建一个和自己同名的仓库，要公开，创建的时候会提示小彩蛋你的reademe会展示在你的首页，或许你在这个readme里面的修改都会在你的主页上看到了👀👋Hey!I'mXuenew.🐘❤️🍦🍓🍉🍋🥛☕🍗🍟🎮💻🎶💰-🔭你好呀！💡-🤔这里是忆阳的大象耳朵，会点小爬虫，想做一个有意思的前端工程师-⚡Funfact:喜欢看动漫，喜欢看小说，喜欢听音乐，喜欢看电影，喜欢做游戏[![GitHub](https://img.shields.io/badge/GitHub-181717?style=flat-square&logo=github&logoColor

1. 行为准则2. 设计过程的螺旋式上升2.1. 圆锥体中的箭头进一步螺旋式上升2.2. 你现在更确定你理解了问题空间2.3. 你的原型为你的解决方案提供了越来越多的信心2.4. 随着每一次迭代，设计文档变得更加清晰和详细3. 技术设计流程3.1. 当被要求对系统进行修改时，大多数入门级工程师会直接跳入编码环节3.2. 技术设计流程可以帮助每个人就某项大型变更的设计达成一致3.3. 正确地完成、参与和领导技术设计工作是很有意义并且有价值的3.4. 单独的深入思考和协作的小组讨论3.4.1. 研究、头脑风暴和写作构成了深度工作3.4.1.1. 外界干扰是深度工作的“杀手”3.4.1.2. 避免所

1. 行为准则2. On-Call工程师2.1. On-Call工程师是应对计划外工作的第一道防线，无论是生产环境问题还是临时支持请求2.2. 将深度工作与运维工作分开，可以让团队中的大多数人专注于开发任务2.3. On-Call工程师只需专注于不可预知的运维难题和支持任务3. On-Call的工作方式3.1. On-Call的开发人员根据时间表进行轮换3.1.1. 每名合格的开发人员都会参与到轮换工作中3.2. On-Call人员的大部分时间用来处理临时性的支持请求3.2.1. bug报告、关于他们团队的软件如何运行以及使用的问题3.3. 大概每名On-Call人员最终都会遇到一起运维事故（

1. 部署环节1.1. 部署软件是指将软件包送到它们需要运行的地方的行为1.2. 移动应用的部署与核反应堆的部署不同，但同样的基本原则都适用1.3. 自动部署1.3.1. 使用脚本而不是手动步骤来部署软件1.3.2. 自动部署的可预测性更高，因为脚本的行为是可以重复的，并且有版本控制1.3.3. 当事情出错时，运维人员能够推理出部署行为1.3.4. 脚本比人更不容易犯错，而且它们消除了在部署过程中去手动调整系统、登录计算机或复制软件包的诱惑1.3.5. 高度发展的自动化催生了持续交付1.3.5.1. 通过持续交付，人力被完全从部署环节中移除1.3.5.2. 打包、测试、发布、部署，甚至展开环节

1. 行为准则2. 软件交付2.1. 你应该了解你的代码最终是如何出现在用户面前的2.2. 当软件在生产环境中稳定运行，并且被客户真实使用时，它就被交付了3. 软件交付流程3.1. 交付阶段并没有行业标准的定义3.1.1. 从打包到展开，统称为发布(release)3.1.1.1. 打包一个构件称为发布3.1.2. 把构件交付下载的过程称为发行(publishing)3.1.3. 直到一个特性在生产环境中被打开时才能称其为被“发布”了，而在这之前的一切行动都是部署(deploy)3.1.3.1. 部署的软件还不能被用户访问3.1.3.1.1. 只是被安装了而已3.1.3.2. 一旦部署，软件就

1. 行为准则2. 代码评审2.1. 代码评审是一种给予和接受反馈的专门的形式2.1.1. 大多数团队会在合并代码的修改之前进行代码评审2.1.2. 评审不是一个证明你有多聪明的机会，也不是一个橡皮图章式的官僚主义障碍2.2. 高质量的代码评审文化有助于所有具有不同经验水平的工程师的成长，并促进他们对代码库的共同理解2.3. 糟糕的代码评审文化会抑制创新，减慢开发速度，并且导致滋生怨恨情绪2.3.1. 执行不力的代码评审会成为一种有害的阻碍2.3.2. 轻率的反馈不提供任何价值，还会拖慢开发人员的速度2.3.3. 缓慢的周转时间会使代码的变化停滞不前2.3.4. 如果没有正确的评审文化，开发人