professional-programming - 面向程序员的全栈资源集合。

Created at: 2015-11-07 13:07:52
Language: Python
License: MIT

目录

专业编程 - 关于此列表

给我六个小时砍一棵树,我会用前四个小时磨斧头。(亚伯拉罕·林肯)

面向程序员的全栈资源的集合。

此页面的目标是使你成为更熟练的开发人员。你只会找到我发现真正鼓舞人心的资源,或者已经成为永恒经典的资源。

本页并不全面。我想保持轻松,不要太压倒性。文章的选择是固执己见的。

项目:

  • 🧰 :资源列表
  • 📖 :书
  • 🎞 :视频/电影提取/电影/谈话
  • 🏙 : 幻灯片/演示文稿
  • ⭐️ :必读

为此列表做出贡献

随时打开 PR 做出贡献!我不会添加所有内容:如上所述,我想使列表保持简洁。

必读书籍

我发现这些书非常鼓舞人心:

有一些免费书籍可用,包括:

必读文章

  • 给新软件工程师的实用建议
  • 论成为一名高级工程师
  • 软件开发中的经验教训:其中一篇为你提供多年来之不易的课程的文章,全部在一篇简短的文章中。必读。
  • 我艰难地学到的东西
    • 先规范,再编码
    • 测试使 API 变得更好
    • 未来思维就是未来垃圾
    • 文档是写给未来自己的情书
    • 有时,让应用程序崩溃总比什么都不做要好
    • 了解并远离货物崇拜
    • “适合工作的工具”只是推动议程
    • 学习函数式编程的基础知识
    • 始终使用时区作为日期
    • 始终使用 UTF-8
    • 创建库
    • 学习监控
    • 显式比隐式好
    • 公司寻找专家,但留住通才的时间更长
    • 处理用户数据的最佳安全方法是不捕获它
    • 该停下来的时候,该停下来了
    • 你负责使用你的代码
    • 当它没有时,不要告诉“它完成了”
    • 注意人们对你的 React
    • 谨防微攻击
    • 保留“我不知道的事情”列表
  • 表明你是一个优秀的程序员
  • 表明你是一个糟糕的程序员的迹象
  • 作为初级开发人员我忘记的 7 个绝对真理
    • 在职业生涯的早期,你可以在 1 年内在支持团队中学到比自己编码多 10 倍
    • 每个公司都有问题,每个公司都有技术债务。
    • 在你缺乏实际经验的话题上过于固执己见是非常傲慢的。
    • 许多会议演讲涵盖概念验证,而不是现实世界的场景。
    • 处理遗留问题是完全正常的。
    • 建筑比吹毛求疵更重要。
    • 在适当的情况下,重点关注自动化而不是文档。
    • 有一些技术债务是健康的。
    • 高级工程师除了编程之外,还必须发展许多技能。
    • 在某些领域,我们都还很初级。
  • 如何构建好的软件
    • 对基本工程实践的良好高级总结。
    • 糟糕软件的根本原因与特定的工程选择关系不大,而与开发项目的管理方式有关。
    • 没有柏拉图式的好工程:这取决于你的需求和你遇到的实际问题。
    • 软件不应被视为静态产品,而应被视为开发团队集体理解的活生生的体现。
    • 软件项目很少失败,因为它们太小了;他们失败了,因为他们变得太大了。
    • 当心伪装成问题陈述的官僚主义目标。如果我们的最终目标是改善公民的生活,我们需要明确承认使他们的生活变得更糟的事情。
    • 构建软件不是为了避免失败;它是关于尽可能快地在战略上失败,以获得构建好东西所需的信息。

其他一般材料和资源清单

公理列表:

  • 戒律 - 乌尔比特
    • 数据比代码更好。
    • 正确性比性能更重要。
    • 确定性胜过启发式。
    • 一百行简单胜过二十行复杂。
    • 如果你的抽象正在泄漏,那不是由于宇宙的某种定律;你只是在抽象方面很糟糕。通常,你没有足够狭隘地指定抽象。
    • 如果你因为害怕唤醒其中的恶魔而避免更改一段代码,那么你就生活在恐惧中。如果你停留在你编写或熟悉的一小部分代码的舒适范围内,你永远不会写出传奇代码。所有代码都是由人类编写的,可以由人类掌握。
    • 如果显然有正确的方法做某事和错误的方法,那就以正确的方式去做。编码需要令人难以置信的纪律。
    • 获得正确答案的最好方法是以错误的方式尝试。
    • 实践告诉你,事情是好是坏;理论告诉你为什么。
    • 没有资格解决问题,不是不解决问题的理由。
    • 如果你不了解你正在使用的系统,你就无法控制它。如果没有人了解系统,系统就处于控制之中。
  • 嵌入式经验法则
  • 改变我生活的50个想法
  • 对 10,000 小时编程的反思
  • 我在20年的软件工程师生涯中学到的20件事

课程

主题

算法和数据结构

其他资源:

  • 算法,杰夫·埃里克森

老实说:算法可能是一个非常枯燥的话题。这个 quora 问题列出了一些更有趣的学习替代方案,包括:

实现示例:

原料药设计与开发

一般 REST 内容:

示例指南:

更具体的主题:

态度、习惯、心态

  • 掌握编程,肯特贝克。
  • 熟练程序员的特质
  • 编程之道:一组关于编程的寓言。
  • 拥有所有权是获得你想要的东西的最有效方式
  • 找时间成为更好的开发人员
  • 每天十分钟:亚历克斯·阿兰如何在不到200小时内写出一本书,每天写10分钟。
  • 软件工程师的关心和喂养(或者,为什么工程师脾气暴躁)
    • 在软件、产品经理、设计师和软件工程师的三驾马车中,只有工程师才能关闭他们的创造性思维,只生产。
    • 工程师和产品经理都倾向于错误地认为产品规格或要求等同于宜家的家具手册。
    • 这是让工程师脾气暴躁的首要事情之一:不断变化的优先级。
    • 尽管许多工程师会抱怨产品经理改变主意,但几乎没有人会在他们的时间估计中考虑到这一点。
    • 计算机科学课程并不是让你为你将在工业中面临的任务做好准备。
    • 当工程师的数量超过可以使用的数量时,工程时间最终会从开发转向规划、同步和协调。
    • 让工程师参与创作过程
    • 为工程师提供发挥创造力的机会。
    • 鼓励休假。
    • 让他们编码
    • 表达感谢
  • 具有产品意识的软件工程师Gergely Orosz
    • 伟大的产品工程师知道,最小的可爱产品需要正确的深度
    • 具有产品意识的工程师可以快速绘制出边缘案例,并想出减少工作的方法:通常提供不需要工程工作的解决方案
    • 参与用户研究和客户支持
    • 提出有充分依据的产品建议
    • 提供产品/工程权衡
  • 40年的40个教训,史蒂夫·施拉夫曼
    • 如果你想在最重要的事情上取得进展,你需要决定你会让谁失望。这是不可避免的。
    • 你能做的最好的投资是你自己的教育。永远不要停止学习。你可以做出的第二项最佳投资是通过真实而有意义的互动来建立你的网络。这是你所知道的和你认识的人。
    • 你永远不会得到你不要求或积极寻求的东西。去吧!
    • 这与隧道尽头的光无关。是隧道。每天出现并享受这个过程。
    • 一个伟大的队友总是把组织及其目标放在自己的利益之上。
    • 选择你的位置。我们的时间有限,我们的大脑只能处理这么多。专注是关键。明智地选择。
    • 每个人都可能在为某事而苦苦挣扎。要善良。乐于助人。
  • 关于编码、自我和注意力
    • 初学者的头脑接受绝对知识是无限的事实,因此保持分数是浪费时间。
    • 掌握只是动力的积累,而不是知识的积累。
    • 处理自我分心教会了我喜欢解决问题的过程。它教会了我热爱和尊重学习过程。结果,我的工作效率更高。我没那么着急了。我是一个更好的队友。我是一个更好的朋友和一个更好的思想家。
  • 固定与增长:塑造我们生活的两种基本心态
  • 一个伟大的软件工程师是什么样的?
  • 好睡眠,好学习,好生活
  • 🎞 史蒂夫·乔布斯:如果你不寻求帮助,你就不会走得很远
  • 编程报价
  • 善待
    • 善良从根本上说是对你对周围人的影响负责。
    • 它要求你注意他们的感受,并考虑你的存在如何影响他们。
  • 沃伦·巴菲特说,这个简单的习惯将成功人士与其他人区分开来
    • 成功人士和真正成功人士的区别在于,真正成功人士几乎对所有事情都说不。
  • 如何走运?
  • 程序员应该停止庆祝无能,DHH
    • 编程的魔力很大程度上只是你还不知道的事情。
    • 如果你打算把编程作为你的职业,认为你不应该走上一些精通的道路是不好的。
  • 没有速度限制

冒名顶替综合症被低估了:很多谈话都在讨论克服冒名顶替综合症。我说拥抱自我怀疑,每天怀疑自己。在一个快速发展的行业中,你的很多知识每年都在过期,即使是你周围资历最浅的人也会不断地培养你没有的技能;你可以通过以新手的决心(甚至恐惧)申请来保持竞争力。这台跑步机的好处是每个工程师都在上面:仅仅因为你是一个冒名顶替者并不意味着其他人比你更值得,因为他们也是冒名顶替者。你应该为自己辩护,承担风险,在事情进展顺利时拍拍自己的背,当你开始建立解决问题的记录时,相信你的技能和适应能力。不要搞错了:你只和你解决的最后一个问题一样好。

Dan Heller,在软件领域建立职业生涯

我已经学会了永远不要清空我写作的井,而是总是在井的深处还有东西时停下来,让它在晚上从喂养它的泉水中重新填充。--海明威

身份验证/授权

自动化

超越软件工程和随机

偏见

偏见不仅适用于招聘。例如,当在完全不同的上下文中批评某人很久以前编写的代码时,基本的归因偏见也适用。

缓存

职业发展

前往员工工程

字符集

代码审查

编码和代码质量

编译 器

配置

数据库

另请参阅 SQL 部分。

习题:

NoSQL:

数据格式

数据科学/数据工程

调试

设计(视觉、用户体验、用户界面、排版)

我强烈建议阅读The Non-Designer's Design Book。这是一本非常短的书,将为你提供一些非常可行的设计建议。

文章:

资源:

设计(OO 建模、架构、模式、反模式等)

以下是好书清单:

关于架构的绝对参考之一是Martin Fowler:查看他的软件架构指南

文章:

你可以在绘图台上使用橡皮擦或在施工现场使用大锤。(弗兰克·劳埃德·赖特)

资源:

设计:数据库架构

  • 数据库模式设计的谦虚指南,Mike Alche
    • 使用至少第三范式
    • 使用约束创建最后一道防线
    • 切勿在单个字段中存储完整地址
    • 切勿在同一字段中存储名字和姓氏
    • 建立表名和字段名的约定。

设计:图案

设计:简约

  • 简单变得简单🎞,丰富的小嗝嗝。这是一个令人难以置信的鼓舞人心的演讲,重新定义了简单性,易用性和复杂性,并表明看起来简单的解决方案实际上可能会损害你的设计。

开发环境和工具

工具

关于工具的文章:

  • 花哨工具的回归
    • 简单的工具让你思考更多
    • 德鲁克:“我写下来不是为了以后记住它,我把它写下来是为了现在记住它。
    • 无摩擦记笔记会产生笔记,但不会产生记忆。

多元化与包容性

查看我的管理资源列表

docker

另请参阅charlax/python-education中的Python特定部分。

  • 有关使用 Docker Compose 的生产就绪 Web 应用的最佳做法
    • 避免使用覆盖文件为 Dev 和 Prod 编写 2 个文件
    • 使用别名和定位点减少服务重复
    • 在 Docker Compose 中定义你的 Dockerfile
      HEALTHCHECK
    • 充分利用环境变量
    • 使用多阶段构建优化映像大小
    • 以非 root 用户身份运行容器
  • 适用于 Python 开发人员的 Docker 最佳实践
    • 使用多阶段构建
    • 密切注意 Dockerfile 命令的顺序以利用层缓存
    • 较小的Docker镜像更加模块化和安全(但要注意Alpine)
    • 最小化层数 (, ,
      RUN
      COPY
      ADD
      )
    • 使用非特权容器
    • 首选
      COPY
      ADD
    • 将 python 包缓存到 docker 主机
    • 首选数组而不是字符串语法
    • 了解 和 之间的区别
      ENTRYPOINT
      CMD
    • 包括说明
      HEALTHCHECK
    • 请尽可能避免使用该标记。
      latest
    • 不要在映像中存储机密
    • 使用文件(包含等)
      .dockerignore
      **/.git
    • 检查和扫描你的 Docker 文件和图像(例如
      hadolint
      )
    • 登录到标准输出或标准输出
  • docker 容器安全

文档

最苍白的墨水比最强大的记忆更可靠。-- 中国谚语

点文件

文章

编辑器和 IDE

具体关于 Vim:

随意检查我的 vim 配置和我的 vim 备忘单

电子邮件

工程管理

查看我的管理资源列表

习题

最好的学习方法是边做边学。

实践:

函数式编程 (FP)

  • 再见,面向对象编程
  • 函数式编程和Haskell 🎞:学习FP的一些很好的理由!
  • 函数式编程基础:FP及其优势的简短介绍。
  • OO vs FP, Robert C. Martin, The Clean Code Blog.OOP专家对OOP和FP之间差异的一个非常有趣的看法。
    • OO与状态无关。对象是函数包,而不是数据包。
    • 函数程序,如OO程序,由对数据进行操作的函数组成。
    • FP对任务施加纪律。
    • OO 对函数指针施加纪律。
    • 无论你的编程风格如何,软件设计的原则仍然适用。你决定使用没有赋值运算符的语言这一事实并不意味着你可以忽略单一责任原则。
  • 解析,不验证
    • 使用使非法状态无法表示的数据结构
    • 尽可能向上推举证责任,但不要再进一步
    • 让你的数据类型通知你的代码,不要让你的代码控制你的数据类型
    • 不要害怕在多次传递中解析数据
    • 避免数据的非规范化表示,尤其是在数据可变的情况下
    • 使用抽象数据类型使验证器“看起来像”解析器
  • 🏙 函数式编程
  • 15分钟内完成单子
  • hemanth/函数式编程术语:函数式编程世界的简单术语

硬件

HTTP

幽默

事件响应(随叫随到、警报、中断、消防、事后分析)

  • 希罗库的事件响应
  • 我的警报哲学
    • 页面应该是紧急的、重要的、可操作的和真实的。
    • 在消除嘈杂警报方面犯错 - 过度监控比监控不足更难解决。
    • 症状是用更少的努力更全面、更有力地捕获更多问题的更好方法。
    • 在基于症状的页面或 dashboard 中包含基于原因的信息,但避免直接针对原因发出警报。
    • 你的服务堆栈越高,你在单个规则中发现的问题就越明显。但不要走得太远,你无法充分区分正在发生的事情。
    • 如果你想要安静的待命轮换,则必须有一个系统来处理需要及时响应但并非迫在眉睫的关键事项。
    • 这篇经典文章现在已成为谷歌SRE书中的一个章节
  • 谷歌 SRE 书中关于随叫随到的章节
  • 在 SRE 时编写运行手册文档
    • 行动手册“减轻压力、平均修复时间 (MTTR) 和人为错误的风险。
    • 使用模板可能是有益的,因为从空白文档开始是非常困难的。
    • 内识的诅咒是一种认知偏差,当某人与他人交流并在不知不觉中假设他们正在与之交流的人的知识水平时,就会发生这种偏见。
    • 使你的内容易于浏览。
    • 如果脚本长度超过一行,请将其视为代码,并将其签入存储库以进行源代码管理并可能进行测试。
  • 事件回顾和事后分析最佳实践,Gergely Orosz

死后的

“让我们为一个我们都像今天一样愚蠢的未来做计划。

– 丹·米尔斯坦

验尸大纲示例:

  • 摘要
    • 冲击
    • 根源
  • 冲击
    • 受影响的用户数
    • 收入损失
    • 期间
    • 团队影响
  • 时间轴
    • 检波
    • 分辨率
  • 根本原因分析
    • 例如,使用5个为什么方法
  • 经验 教训
    • 事情进展顺利
    • 事情进展不顺利
  • 操作项(包括指向任务跟踪工具的直接链接)
    • 改进预防的任务(包括培训)
    • 改进检测的任务(包括监视和警报)
    • 改进缓解措施(包括应急响应)的任务

互联网

面试

注意:这是关于你作为受访者,而不是作为面试官。要查看我的面试官资源列表,请转到我的工程管理存储库

另请参阅本文档中的练习部分。

Kubernetes

学习和记忆

学习如何学习!

  • 我如何重新连接我的大脑以流利地使用数学:副标题 理解的基石是记忆和重复
  • 改进编码的一种可靠方法:阅读代码!
  • 学习编程的技巧
  • 你可以提高你的智力:最大化你的认知潜力的5种方法:原谅点击诱饵标题,它实际上是一篇好文章。
  • 如何提出好问题,朱莉娅·埃文斯。
  • 停止学习框架
  • 学习如何学习:强大的心理工具,帮助你掌握困难的科目
  • 为什么书不起作用,安迪·马图沙克。
    • “作为一种媒介,书籍在传达知识方面出奇地糟糕,读者大多没有意识到这一点。
    • “在学习科学中,我们称这种模式为”传输主义”。这是一种观念,即知识可以直接从老师传给学生,就像将文本从一页转录到另一页一样。要是这样就好了!
    • “通过重新测试自己在不断扩大的时间间隔内学到的材料,你可以廉价而可靠地将大量信息投入到长期记忆中。
  • Anki的策略,提示和技巧:这些建议实际上适用于任何工具
    • 添加图像。我们的大脑是视觉连接的,所以这有助于保留。
    • 不要添加你不理解的东西。
    • 不要添加记住整个列表的卡片。
    • 写出来。对于错误的答案,我会写在纸上。写作的行为是冥想的。我真的很喜欢这个。
    • 继续问自己为什么?为什么会这样?为什么它以这种方式工作?强迫自己理解主题的根源。
    • 康奈尔方法:阅读主题时,在空白处写出问题来测验自己。
    • 假装你必须教它
    • 将 PEMDAS 等助记词用于列表和其他难以记忆的主题。
    • 删除没有意义或你不想再记住的卡片。
  • 有效学习:形成知识的二十条规则
    • 以基础为基础
    • 坚持最少信息原则:你学到的材料必须以尽可能简单的方式制定
    • 完形填空删除既简单又有效:Kaleida的使命是创建一个...它最终产生了一个,叫做Script X。但花了三年时间
    • 图形删除与完形填空删除一样好
    • 避免设置集
    • 避免枚举
    • 战斗干扰 - 即使是最简单的物品,如果它们与其他物品相似,也可能完全难以处理。使用示例,上下文提示,生动的插图,提及情感和你的个人生活
    • 个性化并提供示例 - 个性化可能是建立其他记忆的最有效方式。你的个人生活是一座事实和事件的金矿。只要你为自己建立一个收藏,就可以丰富地使用个性化来建立良好的记忆
    • 提供资源 - 资源可帮助你管理学习过程,更新你的知识,判断其可靠性或重要性
    • 优先次序 - 有效的学习就是确定优先次序。
  • 如何记住任何你真正想记住的东西,有科学的支持
    • 测验自己
    • 总结并与他人分享。
    • 将你刚刚学到的知识与你以前拥有的体验联系起来。
  • 如何永远记住任何事情:关于学习的漫画
  • 通过学习事物的工作原理来更好地编程
  • 如何自学困难的事情
  • 建立自己的个人学习课程
  • 总是做额外的事情
    • 额外的是完成这两个屏幕,然后研究一个新的库进行表单验证,这可能会减少样板代码。
    • 额外工作必须与正常工作相平衡。
    • 额外必须与你的正常工作保持一致。
  • 针对 3 倍速度
    • 当讲座只是课堂体验的一部分时,讲座最有效
    • 学习是间隔重复,而不是狂读书籍
  • 刻意练习的问题
  • 为什么隐性知识比刻意练习更重要
  • 赞美记忆
    • 没有知识就无法准确推理
    • 记忆组织你的知识
    • 它留在你身边
  • 庆祝微小的学习里程碑,朱莉娅·埃文斯。
    • 保持吹牛的文件
    • 你可以“偶然”做很多事情
    • 修复错误可能是里程碑式的

关于Zettelkasten和PKM(个人知识管理):

理查德·费曼的学习策略:

  1. 第 1 步:不断问“为什么?
  2. 第 2 步:当你学到一些东西时,把它学到可以向孩子解释的地方。
  3. 第 3 步:与其随意记住东西,不如寻找使其显而易见的解释。

大多数人高估了他们在 1 年内能做什么,低估了他们在十年内能做什么。–比尔·盖茨

不过,坦率地说,我认为大多数人能学到的东西比他们想象的要多得多。他们卖空自己而不尝试。一点建议:重要的是要将知识视为语义树 - 确保你理解基本原则,即树干和大树枝,在你进入细节/叶子之前,否则没有什么可以抓住的。— 埃隆·马斯克

“经验是你直到需要它之后才会得到的东西。”

告诉我,我忘记了。教我,我记得。让我参与进来,我就会学习。–本杰明·富兰克林

教育是点燃火焰,而不是装满容器。–苏格拉底

我们坚持做的事情对我们来说变得更容易做;不是事物本身的本质被改变了,而是我们做事的能力增加了。– 拉尔夫·沃尔多·爱默生

一个聪明的人可以从一个愚蠢的问题中学到更多,而不是一个傻瓜可以从一个明智的答案中学到更多。–李小龙

讲座被很好地描述为教师的笔记成为学生的笔记而不经过任何一方的头脑的过程。— 莫蒂默·阿德勒

傻瓜从经验中学习。我更喜欢从别人的经验中学习。— 俾斯麦

许可证(合法)

Linux(系统管理)

低级,组装

数学

网络

  • 关于 URI 的巨大困惑
    • URI 是标识资源的字符串。它的语法是 ,其中只有 和 是强制性的。URL 和 URN 是 URI。
      <scheme>:<authority><path>?<query>#<fragment>
      <scheme>
      <path>
    • URL 是标识位于计算机网络上的资源的字符串。它的语法取决于它的方案。例如.
      mailto:billg@microsoft.com
    • URN 是唯一标识资源的字符串。其语法为 。例如
      urn:<namespace identifier>:<namespace specific string>
      urn:isbn:9780062301239

可观测性(监视、日志记录、异常处理)

伐木

  • 不要记录某些日志记录反模式。
    • 日志记录在监视和错误跟踪中没有多大意义。请改用更好的工具:错误和业务监视,包括警报、版本控制、事件溯源。
    • 日志记录大大增加了体系结构的复杂性。它需要更多的测试。使用体系结构模式,使日志记录成为合同的明确部分
    • 日志记录本身就是一个完整的基础结构子系统。而且相当复杂。你必须维护它或将此作业外包给现有的日志记录服务
  • 我父母告诉我的谎言(关于日志)
    • 原木很便宜
    • 我可以自己跑得更好
    • 分级日志记录是分离信息的好方法
    • 日志与事件基本相同
    • 标准的日志记录格式就足够了
  • 测井 - OWASP 备忘单系列

错误/异常处理

监测

操作系统

过度设计

“一个有效的复杂系统总是被发现是从一个简单的有效的系统演变而来的。从头开始设计的复杂系统永远无法工作,也无法修补以使其工作。你必须重新开始,从一个工作简单的系统开始。

——约翰·加尔(John Gall),《一般系统滑稽学》(General systemantics),一篇关于系统如何工作的文章,尤其是它们是如何失败的......,1975年(这句话有时被称为“加尔斯定律”)

“软件工程是当你增加时间和其他程序员时编程发生的事情。

——Rob Pike,Go at Google: Language Design in the Service of Software Engineering

你不能把向前看的点连接起来;你只能向后连接它们。所以你必须相信这些点会以某种方式连接在你的未来。你必须相信一些东西——你的直觉、命运、生命、业力等等。这种方法从未让我失望,它改变了我的生活。

— 史蒂夫·乔布斯

性能

个人生产力

查看我的管理资源列表中的此部分,“个人生产力”。

透视

  • 31岁的我只剩下几周的生命了。这是我想传递的内容
    • 首先,感恩的重要性。
    • 第二,一个生命,如果活得好,就足够长了。
    • 第三,让自己变得脆弱并与他人建立联系很重要。
    • 第四,为他人做点什么。
    • 第五,保护地球。
  • 人生不短
    • “最令人惊讶的是,你不会让任何人偷走你的财产,但你总是让人们偷走你的时间,这要有无限的价值。”

解决问题

项目管理

请参阅我的工程管理资源列表中的项目管理部分

编程语言

我建议学习:

  • JavaScript,也许还有另一种解释型语言(Python,Ruby等)。解释性语言对于快速的一次性自动化脚本很有用,并且编写面试速度最快。JavaScript无处不在。
  • 一种编译语言(Java,C,C++...)。
  • 一种更新的语言,以了解行业的发展方向(截至撰写本文时,Go,Swift,Rust,Elixir......)。
  • 一种对函数式编程具有一流支持的语言(Haskell,Scala,Clojure...)。

多读一点:

只有两种语言:人们抱怨的语言和没有人使用的语言。

- Bjarne Stroustrup(C++创作者)

对于Python,请随时查看我的专业Python教育存储库

JavaScript

JavaScript 是一种如此普遍的语言,它几乎是必需的学习。

垃圾回收

编程范式

  • Imperative vs Declarative Programming,Tyler McGinnis。
    • 我在声明性和非声明性之间划清界限,以确定是否可以在代码运行时跟踪代码。正则表达式是 100% 声明性的,因为它在执行模式时是不可追踪的。
  • 🎞 命令式编程与声明式编程

读数

重构

  • 三法则,编码恐怖
    • 每个出生的程序员都认为,无论从他们的脑海中冒出来到他们的编辑器中,都是有史以来最通用、最灵活、最一刀切的解决方案。
    • 构建可重用组件的难度是一次性组件的三倍。
    • 可重用组件应在三个不同的应用程序中试用,然后才能足够通用以接受重用库。
  • 重构与重写
  • 绊倒太多图书馆的坑洼

正则表达式

发布和部署

版本控制:

清单:

功能标志:

生产测试:

  • 为什么我们在优步微服务架构中利用多租户
  • 在生产中开发
    • 复杂系统具有涌现行为,产生只有在足够规模下出现的附带现象。
    • 伍德定理:随着系统复杂性的增加,任何单个代理自己的系统模型的准确性都会迅速下降。
    • 为在系统中创建元素而添加的工具和代码越多,复制包含这些工具和代码的环境就越困难。
    • 生产测试的核心是将部署(工件)与发布(功能)分开的想法。
  • 生产中的测试:困难的部分,辛迪·斯里达兰
    • [实际的]分布式系统工程的全部意义在于,你假设你会在某个时间点失败,并且你设计系统的方式是,在每个点的损害最小化,恢复很快,风险与成本可以接受平衡。
    • 如何将类似事件的爆炸半径减少一半?
      • 区分部署(0 风险)和发布
      • 构建部署-观察-发布管道
      • 使增量部署成为常态(金丝雀、基于 % 的部署等)
      • 测试配置更改就像测试代码一样
      • 默认回滚,避免向前修复(慢!
      • 消除灰色故障 - 在某些情况下宁愿崩溃也不愿降级
      • 首选松散耦合的服务,但以牺牲延迟或正确性为代价
      • 使用毒物品尝器(隔离处理客户端输入)
      • 实现每个请求类的背压
      • 从客户端/最终用户的角度(客户端指标)获得适当的可见性
  • 生产测试,安全的方式

搜索

安全

开发人员培训:

资源列表:

命令行管理程序(命令行)

.SQL

系统管理

系统架构

阅读清单:

博客:

书:

文章:

微服务/拆分整体架构:

可扩展性

可靠性

  • 我已经提到了这本书 释放它!以上。还有作者的介绍
  • 服务恢复:回滚与前向修复
  • 复杂系统如何失败
    • 灾难需要多次失败 - 单点故障是不够的。
    • 复杂系统包含不断变化的故障混合物。
    • 事故后归咎于“根本原因”从根本上是错误的。
    • 事后诸葛亮偏向于事故后对人类表现的评估。
    • 安全是系统的特征,而不是其组件的特征
    • 无故障操作需要失败经验。
  • 🧰 测试分布式系统

弹性

站点可靠性工程 (SRE)

注意:本节仅介绍 SRE 作为角色。查看系统架构,了解更多与可靠性相关的内容。

书:

  • 📖 站点可靠性工程
    • 由 Google SRE 团队成员撰写,全面分析了整个软件生命周期 - 如何构建、部署、监控和维护大规模系统。

文章:

  • 从训练营毕业并有兴趣成为一名站点可靠性工程师?:了解 SRE 的大量资源。
  • 以可靠的方式操作一个大型的分布式系统:我学到的实践,Gergely Orosz。
    • 要实现的流程的良好摘要。
  • 以生产为导向的开发
    • 生产中的代码是唯一重要的代码
    • 工程师是他们编写的代码的主题专家,应该负责在生产中操作它。
    • 购买几乎总是胜过构建
    • 简化部署
    • 信任最接近刀具的人
    • QA 门使质量变差
    • 镗削技术很棒。
    • 非生产环境的收益递减
    • 事情总会破裂
  • 有意义的可用性
    • 良好的可用性指标应该是有意义的、相称的和可操作的。我们所说的“有意义”是指它应该捕捉用户体验。通过“成比例”,我们的意思是指标的变化应该与用户感知的可用性的变化成正比。通过“可操作”,我们的意思是该指标应该让系统所有者深入了解一段时间内可用性低的原因。本文表明,没有一个常用指标满足这些要求......
  • 🏙 高可靠性基础架构迁移,朱莉娅·埃文斯。
  • 🏙 警报悖论:为什么删除 90% 的寻呼警报可以使你的系统变得更好,以及如何制作工程师乐于加入的待命轮换。

可靠性是每个客户用户的一个特点。-- 一个身份验证 SRE。

资源:

技术债务

  • 技术债务,马丁·福勒。
  • 使用工程分配框架解决技术债务
    • 你无需停止交付功能即可解决技术债务
    • 传达业务价值
  • 你的技术债务
    • 今天,开发人员不喜欢的任何代码都被贴上了技术债务的标签。
    • 沃德·坎宁安(Ward Cunningham)发明了债务比喻,向他的经理解释说,迭代构建可以更快地为他们提供工作代码,就像借钱启动项目一样,但必须继续偿还债务,否则利息支付将使项目停滞不前。
    • 静态分析通常无法检测到你的技术债务。

测试

为什么要测试:

  • 为什么要费心写测试呢?戴夫·切尼。该主题的一个很好的介绍。
    • 即使你不这样做,也会有人测试你的软件
    • 大多数测试应由开发团队执行
    • 手动测试不应该是测试的大部分,因为手动测试是 O(n)
    • 测试是确保始终可以交付主分支的关键组件
    • 测试锁定行为
    • 测试让你有信心更改其他人的代码

如何测试:

测试金字塔:

端到端测试:

工具

版本控制 (Git)

学习 Git、课程和书籍:

备忘单:

更具体的主题:

职业道德、生产力和工作/生活平衡

  • 你的90%利用率的非线性问题,Jason Cohen:为什么持续以90%的利用率运行实际上会适得其反。
  • 关于如何在任何工作中取得成功的循证建议:大多数自助建议都不是基于研究的。本文中列出的是。
  • 深度工作的完整指南
    • 执行深度工作的能力变得越来越罕见,同时它在我们的经济中变得越来越有价值。
    • 选择你的深度工作策略
    • 建立深入的工作例程
    • 纪律#1:专注于极其重要的事物
    • 纪律#2:根据主要措施采取行动
    • 纪律#4:创建问责节奏
    • 我们的深度工作能力是有限的
    • 工匠选择刀具的方法
    • 停止使用社交媒体
    • 让你的老板参与深度工作
  • 我曾经有过的每一个生产力想法,尽可能简洁
    • 上下文意向性是家和地球上所有其他地方之间的关键区别
    • 规则是关于例外的
  • 创客们,不要让自己被迫进入“经理时间表”
    • 研究表明,制造商需要长达 30 分钟才能进入流程
    • 使用创客经理办公时间
    • 沟通可以以更安静的异步频率进行,形式是深思熟虑的书面讨论,而不是令人心碎的会议或不稳定的一次一行聊天消息
    • 建立团队知识库,以最大程度地减少重复性问题并允许自行入职。
  • 改善生活的100个技巧
    • 缺陷不会让你与众不同。你年纪越大,你无法做饭对人们来说就越是一个危险信号。
    • 历史会记住那些首先进入市场的人。让你的创作走向世界比让它完美更重要。
    • 纪律高于动机。前者可以训练,后者转瞬即逝。如果你只依靠动力,你将无法完成伟大的事情。
    • 你不生活在视频游戏中。如果你即将做一些愚蠢的事情,或者如果你已经朝着错误的方向走得太久,则不会弹出警告。你必须创建自己的警告。
    • 培养可靠的声誉。良好的声誉是有价值的,因为它们是罕见的(容易破坏和难以重建)。如果你的客户知道咖啡总是很热,你就不必冲泡最美味的咖啡。
    • 多赞美别人。许多人很难认为自己聪明、漂亮或善良,除非别人告诉他们。你可以帮助他们。
  • 🏙 2011 GTD完成任务
  • 围绕工作流构建工具,而不是围绕工具构建工作流
  • 重新思考最佳实践
  • 对完成宣言的崇拜

“做你喜欢的事情,直到你喜欢做”我经常想到@naval的“读你喜欢的,直到你爱读”的评论,这是一个很好的概括。我的经验是,教育一个实干家比激励受过教育的人更容易;在你开始努力之前,你必须相信你能做到。– 约翰·卡马克

网站开发

写作(沟通、博客)

➡️另请参阅我的工程管理列表

像亚马逊人一样写作

如果你想多了,写信。如果你考虑不足,请阅读。– @AlexAndBooks_

演示文稿的资源和灵感

保持最新状态

网站和RSS提要(我使用Feedly):

安全:

通讯:

概念

词汇表