编程资源
June 24, 2026 · View on GitHub
本文档整合了以下源文件:programming.md
来源:programming.md
概述
本文档是一份面向程序员的职业发展与技术学习资源汇编,涵盖从编码技能到系统架构、从职业成长到软技能提升的全方位内容。所有资源均经过筛选,侧重经典与实用。
图例说明:
| 标记 | 含义 |
|---|---|
| R | 资源列表 |
| B | 书籍 |
| V | 视频/演讲 |
| S | 幻灯片/演示文稿 |
| P | 论文 |
必读书籍
| 书籍 | 说明 |
|---|---|
| The Pragmatic Programmer | 最具启发性的编程实践书籍 |
| Code Complete | 软件构建的实用手册,提供代码讨论的必要框架 |
| Release It! | 生产就绪软件的最佳实践,相当于约3年的实战经验 |
| Scalability Rules | 50条Web扩展原则 |
| The Linux Programming Interface | Linux与UNIX系统编程手册,理解软件演进与接口设计 |
| SICP(免费) | MIT经典教材,计算机科学最有影响力的教科书之一 |
免费书籍资源:
| 资源 | 链接 |
|---|---|
| Professional Software Development | 链接 |
| 免费编程书籍(vhf) | GitHub |
| 免费编程书籍(EbookFoundation) | GitHub |
必读文章
| 文章 | 核心要点 |
|---|---|
| Practical Advice for New Software Engineers | 新手工程师实用建议 |
| On Being A Senior Engineer | 如何成为高级工程师 |
| Lessons Learned in Software Development | 多年经验浓缩的教训 |
| Things I Learnt The Hard Way | 规格先行、测试造就更好的API、文档是给未来自己的信、始终使用UTF-8和时区 |
| 7 absolute truths I unlearned as junior developer | 每家公司都有技术债;架构比细节争论更重要;高级工程师需要编程之外的多种技能 |
| How to Build Good Software | 软件项目的失败原因往往在于管理方式而非技术选择;软件应被视为团队理解的活体体现 |
| Expert Generalists | 提出"T型工程师"的新视角:好奇心、协作性、注重基础、兼顾通才与专才 |
| A Bunch of Programming Advice I'd Give To Myself 15 Years Ago | 评估质量与速度的权衡;磨刀不误砍柴工;调试要深入一层 |
通用资源
资源列表与路线图
| 资源 | 链接 |
|---|---|
| 开发者路线图 | kamranahmedse/developer-roadmap |
| 每个程序员应知之事 | mtdvio/every-programmer-should-know |
| 软件开发著名定律 | Famous Laws |
| Amazon Builders' Library | 链接 |
| 程序员常犯的错误认知 | kdeldycke/awesome-falsehood |
| 编程演讲合集 | hellerve/programming-talks |
| CS专业学生应知之事 | 链接 |
补充书籍
| 书籍 | 说明 |
|---|---|
| The Imposter's Handbook | 面向无CS学位开发者 |
| The Computer Science Book | 计算机科学入门 |
| The Software Engineer's Guidebook | 软件工程行业完整指南 |
公理与经验法则
| 来源 | 核心观点 |
|---|---|
| Urbit Precepts | 数据优于代码;正确性优于性能;确定性优于启发式;100行简单代码优于20行复杂代码 |
| Embedded Rules of Thumb | 嵌入式开发经验法则 |
| Reflections on 10,000 Hours of Programming | 万小时编程反思 |
| 20 Things I've Learned in my 20 Years as a Software Engineer | 20年软件工程经验 |
课程
| 课程 | 说明 |
|---|---|
| Google Tech Dev Guide | Google技术开发者指南 |
| The Missing Semester(MIT) | CS教育中缺失的课程:Shell、编辑器、Git、调试、安全等 |
| Mathematics for the adventurous self-learner | 自学数学指南 |
| coding-interview-university | 完整的CS学习计划 |
| Teach Yourself Computer Science | 精选CS学习资源 |
| ossu/computer-science | 免费自学CS教育 |
主题分类资源
算法与数据结构
| 资源 | 类型 | 说明 |
|---|---|---|
| CLRS算法导论 | B | 算法经典教材,配套OCW课程 |
| The Algorithm Design Manual | B | Skiena的算法设计手册 |
| Project Euler | 练习 | 算法练习平台 |
| CS 61B Spring 2023 | 课程 | UC Berkeley数据结构课程 |
| Grokking Algorithms | B | 算法图解 |
| Data Structure Visualization | 工具 | 数据结构可视化 |
| Visualizing Algorithms | 文章 | 算法可视化 |
| B-trees and database indexes | 文章 | B树与数据库索引 |
| Big O visualizations | 工具 | 大O复杂度可视化 |
| Raft Consensus Algorithm | 文章 | 分布式系统中的Raft共识算法 |
实现参考:
- trekhleb/javascript-algorithms -- JavaScript算法与数据结构实现
- The Algorithms -- 多语言算法实现
API设计与开发
| 资源 | 说明 |
|---|---|
| Roy Fielding的REST论文 | REST架构风格的原始论文 |
| REST API设计最佳实践 | Stack Overflow Blog |
| Microsoft REST API Guidelines | 微软API设计规范 |
| Zalando RESTful API Guidelines | Zalando API规范 |
| Google API Design Guide | Google网络API设计指南 |
| AIP-1 | Google API改进提案 |
| Why links not keys in APIs | 用链接而非外键表达API关系 |
| Give me /events, not webhooks | 事件优于Webhook |
态度、习惯与思维模式
| 资源 | 核心观点 |
|---|---|
| Mastering Programming | Kent Beck论精通编程 |
| The traits of a proficient programmer | 熟练程序员的特质 |
| Taking Ownership | 主动承担责任是达成目标的最有效方式 |
| The Product-Minded Software Engineer | 产品思维工程师:了解边界情况、参与用户研究、提出产品/工程权衡 |
| On Coding, Ego and Attention | 初学者心态、精通是动量的积累、处理自我干扰 |
| Fixed vs. Growth Mindset | 固定型思维vs成长型思维 |
| Don't Wait for Motivation, Act for Momentum | 不要等动力,从微小任务开始积累动量 |
| High Agency | 高自主性 |
| The Grug Brained Developer | 自我觉察的程序员习惯 |
关于拖延症:
- News is bad for you -- 新闻误导、浪费时间、抑制思考、扼杀创造力
认证与授权
| 资源 | 说明 |
|---|---|
| Authorization in a microservices world | 微服务中的授权 |
| Authorization Logic | 授权逻辑:规则随时间演进 |
| The Copenhagen Book | Web应用认证实现指南 |
职业成长
| 资源 | 核心要点 |
|---|---|
| Don't Call Yourself a Programmer | 重新定义程序员的职业定位 |
| Ten Principles for Growth as an Engineer | 工程师成长十大原则 |
| The career advice I wish I had at 25 | 职业是马拉松不是冲刺;成功来自重复而非新事物;管理是关于人而非事物 |
| What's a senior engineer's job? | 高级工程师不仅仅是个人贡献者 |
| The Well Rounded Engineer | 全面发展的工程师:多语言范式、多数据库、多协议、构建工具、调试、部署、架构 |
| Some career advice | 建立声望储备;优秀的关系会跟随你;早期尽量尝试不同类型的公司 |
| The Forty-Year Programmer | 越优秀越与众不同;通过基础学习深层原理 |
| Stop Avoiding Politics | 好的政治就是战略性地经营关系和影响力 |
| Publishing your work increases your luck | 发布作品增加运气 |
通往Staff工程师:
| 资源 | 说明 |
|---|---|
| 14 lessons to FAANG Staff Engineer | 5年成为FAANG Staff工程师的经验 |
| staffeng.com | Staff-plus工程角色指南(Will Larson) |
| Staff archetypes | Staff工程师原型 |
代码审查
| 资源 | 核心要点 |
|---|---|
| Google代码审查指南 | Google工程实践文档 |
| How to Make Your Code Reviewer Fall in Love with You | 先自我审查;写清晰的变更描述;自动化简单检查;用代码回答问题;缩小变更范围 |
| How to Do Code Reviews Like a Human | 像人类一样做代码审查 |
| Maslow's pyramid of code reviews | 代码审查的马斯洛金字塔 |
| No code reviews by default | 责任优于约定 |
编码与代码质量
| 资源 | 核心要点 |
|---|---|
| Write code that is easy to delete | 编写易于删除而非易于扩展的代码 |
| The Ten Commandments of Egoless Programming | 无我编程十诫 |
| Clean Code | 敏捷软件工艺手册 |
| Naming boolean variables | 布尔变量命名:用is/has前缀;避免否定;避免自定义前缀 |
| kettanaito/naming-cheatsheet | 语言无关的变量命名指南 |
| Cognitive Load | 认知负荷才是关键 |
| How to create software quality | 如何创造软件质量 |
设计(视觉、UX、UI)
| 资源 | 说明 |
|---|---|
| The Non-Designer's Design Book | 非设计师的设计书,提供可操作的设计建议 |
| The Visual Display of Quantitative Information | 数据可视化经典 |
| 10 Usability Heuristics | 10条可用性启发式原则 |
| Visual design rules | 可安全遵循的视觉设计规则 |
| bradtraversy/design-resources-for-developers | 开发者设计资源合集 |
设计(OO建模、架构、模式)
必读书籍:
| 书籍 | 说明 |
|---|---|
| Design Patterns (GoF) | 设计模式经典,核心思想:组合优于继承 |
| Patterns of Enterprise Application Architecture | 企业应用架构模式 |
| Domain-Driven Design | 领域驱动设计 |
| Clean Architecture | 整洁架构,利用单一职责原则 |
| Game Programming Patterns(免费在线) | 游戏编程模式 |
关键文章:
| 文章 | 核心观点 |
|---|---|
| No Silver Bullet | 软件的四大难题:复杂性、一致性、可变性、不可见性 |
| Out of the Tar Pit | 本质复杂性与偶然复杂性的区分;函数式编程有助于避免状态衍生的复杂性 |
| Cognitive load is what matters | 认知负荷是关键;精心设计的单体架构往往比微服务更灵活 |
| CUPID | 可组合、Unix哲学、可预测、惯用、基于领域 |
| Simple Made Easy | Rich Hickey重新定义简单与容易的区别 |
数据库Schema设计:
| 资源 | 核心建议 |
|---|---|
| A humble guide to database schema design | 至少使用第三范式;用约束创建最后防线;永远不要将完整地址存在单个字段 |
| YAGRI: You are gonna read it | 存储created_at、created_by等字段 |
开发环境与工具
| 工具 | 说明 |
|---|---|
| Glances | 系统监控 |
| HTTPie | 人性化的HTTP客户端 |
| jq | 命令行JSON处理器 |
| tmux | 终端复用器 |
| htop | 交互式进程查看器 |
| Visual guide to SSH tunnels | SSH隧道可视化指南 |
| casey/just | 命令运行器(Rust编写) |
Docker
| 资源 | 核心要点 |
|---|---|
| Best Practices with Docker Compose | 使用Override文件避免双Compose文件;利用别名和锚点减少重复;在Compose中定义HEALTHCHECK |
| Docker Best Practices for Python | 多阶段构建;利用层缓存;最小化层数;使用非特权容器;COPY优于ADD;日志输出到stdout/stderr |
| Docker Containers Security | Docker容器安全 |
文档
| 资源 | 核心要点 |
|---|---|
| Writing automated tests for your documentation | 测试文档中的代码示例确保不过时 |
| Keep a Changelog | 变更日志规范 |
| Architectural Decision Records (ADR) | 架构决策记录方法 |
| The documentation system | 文档系统四分类:教程、操作指南、技术参考、解释 |
| Diataxis | 技术文档系统化方法 |
| ARCHITECTURE.md | 架构文档 |
| Best practices for writing code comments | 代码注释最佳实践 |
| Always be quitting | 记录知识、培训替代者、通过"可替代"释放自己做高影响项目 |
编辑器与IDE
| 资源 | 说明 |
|---|---|
| VSCode | 当前最流行的文本编辑器之一 |
| Seven habits of effective text editing | Vim作者关于高效文本编辑的习惯 |
Vim学习路径:
| 资源 | 说明 |
|---|---|
| Is Vim Really Not For You? | Vim新手指南(共6篇系列文章) |
| Practical Vim | Vim实战 |
| Learn Vimscript the Hard Way | Vim脚本学习 |
| VimGolf | Vim挑战练习 |
| Vim anti-patterns | Vim反模式 |
数据库
| 资源 | 说明 |
|---|---|
| CAP Theorem简介 | CAP定理通俗介绍 |
| PACELC定理 | 无分区时延迟与一致性的权衡 |
| Zero downtime database migrations | 零停机数据库迁移 |
| Readings in Database Systems | 数据库系统读物 |
| How does a relational database work | 关系数据库工作原理 |
| Use the index, Luke | 索引使用指南 |
| Why you should probably be using SQLite | SQLite的适用场景 |
| Database Internals | 数据库内部原理 |
Postgres专题:
| 资源 | 说明 |
|---|---|
| Safe Operations For High Volume PostgreSQL | 高流量PostgreSQL安全操作 |
| Transaction Isolation in Postgres | Postgres事务隔离级别 |
| PostgreSQL exercises | PostgreSQL练习 |
| Postgres: don't Do This | Postgres不要做的事 |
| Postgres lock explained | Postgres锁详解 |
| Just use Postgres | "直接用Postgres"系列文章 |
NoSQL:
| 资源 | 说明 |
|---|---|
| NOSQL Patterns | NoSQL模式 |
| NoSQL Databases: a Survey | NoSQL数据库综述与决策指南 |
| Redis Explained | Redis原理详解 |
调试
| 资源 | 核心要点 |
|---|---|
| Rubber Duck Problem Solving | 橡皮鸭调试法 |
| Five Whys | 五个为什么根因分析法 |
| The Infinite Hows | 批评五个为什么方法,倡导用"如何"替代"为什么"进行更广泛的探索 |
| Debugging zine | 调试指南 |
| The Thirty Minute Rule | 卡住超过30分钟就求助 |
| How to create a Minimal, Reproducible Example | 如何创建最小可复现示例 |
| Some ways to get better at debugging | 学习代码库、系统、工具、策略;积累经验 |
| The Saff Squeeze | 系统化删除代码直到测试和代码足够小以理解 |
| tcpdump is amazing | tcpdump的强大之处 |
| Troubleshooting: The Skill That Never Goes Obsolete | 故障排除:永不过时的技能 |
事件响应(值班、告警、故障、事后复盘)
| 资源 | 核心要点 |
|---|---|
| Incident Response at Heroku | 事件指挥官角色 |
| Google SRE Book - Oncall | Google SRE值班章节 |
| Writing Runbook Documentation | 运维手册降低压力和MTTR |
| Incident Review Best Practices | 事件审查最佳实践 |
告警哲学:
| 原则 | 说明 |
|---|---|
| 告警应紧急、重要、可操作、真实 | 来自 My Philosophy On Alerting |
| 宁可减少噪音告警 | 过度监控比监控不足更难解决 |
| 基于症状优于基于原因 | 症状能更全面地捕获问题 |
事后复盘模板:
| 章节 | 内容 |
|---|---|
| 执行摘要 | 影响、根因 |
| 影响 | 受影响用户数、收入损失、持续时间、团队影响 |
| 时间线 | 检测、解决 |
| 根因分析 | 如五个为什么方法 |
| 经验教训 | 做得好的、做得差的 |
| 行动项 | 预防、检测、缓解任务 |
学习与记忆
| 资源 | 核心要点 |
|---|---|
| How I Rewired My Brain to Become Fluent in Math | 理解的基石是记忆和重复 |
| One Sure-Fire Way to Improve Your Coding | 阅读代码 |
| Stop Learning Frameworks | 停止学习框架 |
| Learning How to Learn | Coursera学习如何学习课程 |
| Why books don't work | 书籍作为媒介在传递知识方面出奇地差 |
| How to Remember Anything Forever-ish | 关于学习的漫画 |
| Against 3X Speed | 学习是间隔重复而非暴读 |
间隔重复与闪卡策略:
| 策略 | 说明 |
|---|---|
| 添加图片 | 大脑视觉化处理有助于记忆 |
| 不添加不理解的内容 | 确保理解后再记忆 |
| 不记忆整个列表 | 避免枚举型卡片 |
| 手写 | 手写过程具有冥想效果 |
| 持续问"为什么" | 追根溯源 |
| 康奈尔笔记法 | 阅读时在边栏写问题自测 |
| 假设要教给别人 | 教学是最好的学习 |
费曼学习策略:
- 持续问"为什么"
- 学到能向孩子解释的程度
- 寻找让事物显而易见的解释
机器学习/AI
| 资源 | 说明 |
|---|---|
| Transformers from Scratch | 从零理解Transformer |
| A Gentle Introduction to Graph Neural Networks | 图神经网络入门 |
| The Math Behind AI | AI背后的数学 |
性能
| 资源 | 核心要点 |
|---|---|
| Numbers Everyone Should Know | 每个程序员应知的延迟数字 |
| Rob Pike's 5 Rules of Programming | 无法预知程序耗时在哪里;先测量;n通常很小时简单算法更好;数据结构主导 |
| Four Kinds of Optimisation | 四种优化类型 |
可靠性
必读书籍:
| 书籍 | 说明 |
|---|---|
| Site Reliability Engineering(Google) | Google SRE团队著作,全面分析软件生命周期 |
| Incident Metrics in SRE | TTD/TTM/TTR/TBF的规范定义 |
关键文章:
| 文章 | 核心观点 |
|---|---|
| How Complex Systems Fail | 灾难需要多重故障;"根因"归因从根本上是错误的;安全是系统的特性而非组件的特性 |
| Production Oriented Development | 生产中的代码是唯一重要的代码;买几乎总是优于构建;让部署变得简单 |
| MTTR vs MTBF | MTTR比MTBF更重要 |
集成模式(依赖管理):
| 模式 | 说明 |
|---|---|
| Circuit Breaker | 断路器模式 |
| Rate limiter algorithms | 限流算法 |
| Good Retry, Bad Retry | 关于重试、断路器、截止时间的洞察 |
系统架构
必读书籍:
| 书籍 | 说明 |
|---|---|
| Designing Data-Intensive Applications | 数据密集型应用设计 |
| Building Microservices | 微服务构建 |
| Building Secure and Reliable Systems(Google,免费) | 构建安全可靠的系统 |
关键资源:
| 资源 | 说明 |
|---|---|
| system-design-primer | 大规模系统设计学习 |
| The twelve-factor app | 十二要素应用方法论 |
| The Log | 实时数据统一抽象的日志 |
| Fallacies of distributed computing | 分布式计算谬误 |
| Patterns of Distributed Systems | 分布式系统模式 |
| ConwaysLaw | 康威定律 |
| C4 model | 软件架构可视化C4模型 |
| AWS Well-Architected Framework | AWS架构良好框架 |
微服务vs单体:
| 资源 | 核心观点 |
|---|---|
| Monolith First | Martin Fowler:先用单体 |
| Don't start with microservices | 生产环境不要从微服务开始 |
| Introducing domain-oriented microservice architecture | Uber:面向领域的微服务架构 |
| Monoliths are the future | 单体是未来 |
| Death by a thousand microservices | 千微服务之死 |
安全
| 资源 | 说明 |
|---|---|
| OWASP Top Ten | Web应用十大安全风险 |
| OWASP Cheat Sheet Series | OWASP安全速查表系列 |
| API Security Checklist | API安全清单 |
| Secure by Design | 安全代码与好的软件设计有大量重叠 |
| Hacksplaining | 安全培训 |
| API Tokens: A Tedious Survey | API令牌综述:不要使用JWT |
测试
| 资源 | 核心要点 |
|---|---|
| Testing strategies in microservices | 微服务测试策略 |
| Why bother writing tests at all? | 测试锁定行为;测试给你信心去修改别人的代码 |
| The practical test pyramid | 实用测试金字塔 |
| Write tests. Not too many. Mostly integration. | 写测试,不要太多,主要写集成测试 |
| Software testing anti-patterns | 软件测试反模式 |
| Just say no to more end-to-end tests | 对更多端到端测试说不 |
部署与发布
| 资源 | 说明 |
|---|---|
| How to deploy software | 如何部署软件 |
| BlueGreenDeployment | 蓝绿部署 |
| Move fast and break nothing | 快速行动但不破坏 |
| Feature Toggles | 特性标志完整指南:发布切换、实验切换、运维切换、权限切换 |
版本控制:
| 方案 | 链接 |
|---|---|
| SemVer(语义化版本) | semver.org |
| CalVer(日历版本) | calver.org |
版本控制(Git)
| 资源 | 说明 |
|---|---|
| Git Book | Git官方书籍 |
| Git from the inside out | 从内部理解Git |
| Atlassian Git Tutorials | Atlassian Git教程 |
| Learn Git Branching | 交互式Git分支学习 |
| Oh My Git! | Git学习游戏 |
| How to Write a Git Commit Message | 如何写Git提交信息 |
| Conventional Commits | 约定式提交规范 |
| Oh Shit, Git!?! | Git急救指南 |
Shell(命令行)
| 资源 | 说明 |
|---|---|
| the-art-of-command-line | 一页掌握命令行 |
| Minimal safe Bash script template | 最小安全Bash脚本模板 |
| Command Line Interface Guidelines | CLI设计指南 |
| Effective Shell | 高效Shell |
| Awk in 20 Minutes | 20分钟学会Awk |
SQL
| 资源 | 说明 |
|---|---|
| SQL styleguide | SQL风格指南 |
| Best practices for writing SQL queries | SQL查询最佳实践 |
| Reasons why SELECT * is bad | SELECT * 的性能问题 |
| Animate SQL | SQL动画学习 |
| Joins 13 Ways | 13种JOIN方式 |
函数式编程
| 资源 | 核心要点 |
|---|---|
| Functional Programming Fundamentals | FP基础简介 |
| OO vs FP | OO是对函数指针的纪律约束;FP是对赋值的纪律约束 |
| Parse, don't validate | 解析而非验证;用数据结构使非法状态不可表示 |
| Monads in 15 minutes | 15分钟理解Monad |
| functional-programming-jargon | FP术语通俗解释 |
编程语言
推荐学习路径:
| 类别 | 推荐语言 | 原因 |
|---|---|---|
| 解释型语言 | JavaScript + Python/Ruby | 快速自动化脚本、面试最快、JavaScript无处不在 |
| 编译型语言 | Java/C/C++ | 理解编译与类型系统 |
| 现代语言 | Go/Swift/Rust/Elixir | 了解行业趋势 |
| 函数式语言 | Haskell/Scala/Clojure | 一流的FP支持 |
关键文章:
| 文章 | 说明 |
|---|---|
| Learn more programming languages | 学习更多语言以获得新视角 |
| The seven programming ur-languages | 七种编程元语言:ALGOL、Lisp、ML、Self、Forth、APL、Prolog |
| Static vs. dynamic languages | 静态vs动态语言文献综述 |
可观测性(监控、日志、异常处理)
日志:
| 资源 | 核心观点 |
|---|---|
| Do not log | 日志在监控和错误追踪中意义不大;使用更好的工具 |
| Lies My Parents Told Me About Logs | 日志并不便宜;分级日志不是分离信息的好方法 |
| Structured Logs Guide | 结构化日志指南 |
错误/异常处理:
| 资源 | 说明 |
|---|---|
| Writing Helpful Error Messages | 解释问题、解释解决方案、清晰书写 |
| The Error Model | 编程语言层面的错误建模 |
监控:
| 资源 | 核心要点 |
|---|---|
| Google SRE - Monitoring | Google SRE监控章节 |
| How to Monitor the SRE Golden Signals | SRE黄金信号:延迟、流量、错误、饱和度 |
| USE Method | 利用率、饱和度、错误 |
| RED Method | 速率、错误、持续时间 |
低级编程与汇编
| 资源 | 说明 |
|---|---|
| Back to Basics | 学习低级编程的重要性 |
| The Elements of Computing Systems | 从第一原理构建现代计算机 |
| Memory Allocation | 内存分配(交互式文章) |
| Putting the "You" in CPU | CPU工作原理 |
| Why does 0.1 + 0.2 = 0.30000000000000004? | 浮点数原理 |
网络
| 资源 | 说明 |
|---|---|
| Everything you need to know about DNS | DNS完整指南 |
| Computer Networking Fundamentals | 计算机网络基础 |
| How Does the Internet Work? | 互联网工作原理 |
| Choosing an HTTP Status Code | HTTP状态码选择指南 |
编译器
| 资源 | 说明 |
|---|---|
| The Compiler Writer Resource Page | 编译器编写者资源页 |
| kanaka/mal | 实现一个Lisp |
| Let's Build a Compiler | 构建编译器 |
正则表达式
| 资源 | 说明 |
|---|---|
| The Best Regex Trick | 最佳正则技巧 |
| regex101 | 正则表达式构建、测试与调试 |
技术债
| 资源 | 核心观点 |
|---|---|
| TechnicalDebt | Martin Fowler的技术债定义 |
| Ur-Technical Debt | Ward Cunningham发明债务隐喻是为了向经理解释迭代开发 |
| 3 Kinds of Good Tech Debt | 三种好的技术债 |
练习与项目
| 资源 | 说明 |
|---|---|
| build-your-own-x | 从零重建你喜爱的技术 |
| Challenging projects every programmer should try | 文本编辑器、太空入侵者、编译器、迷你OS、电子表格、游戏机模拟器 |
| More challenging projects | 光线追踪、键值存储API、Web浏览器、股票交易机器人 |
| 7 GUIs | 7个GUI项目学习UI编程基础 |
| Fly.io Distributed Systems Challenge | 分布式系统挑战 |
| CodinGame | 编程游戏 |
| Codewars | 编程挑战 |
| Exercism | 编程练习 |
写作与沟通
| 资源 | 核心要点 |
|---|---|
| Writing Well Handbook | 写作指南:构思、初稿、改写、风格、练习 |
| Write Simply | Paul Graham论简洁写作 |
| It's time to start writing | Bezos禁止PPT的原因:好的4页备忘录比20页PPT更能促进深入思考 |
| George Orwell's Six Rules for Writing | 避免陈词滥调;能用短词不用长词;能删就删;用主动语态 |
| Technical Writing One(Google) | 语法、主动语态、清晰简短的句子 |
持续更新
网站与RSS:
| 来源 | 说明 |
|---|---|
| Hacker News | 技术新闻 |
| High Scalability | 系统架构博客 |
安全:
| 来源 | 说明 |
|---|---|
| Schneier on Security | 安全专家博客 |
| Krebs on Security | 安全调查报道 |
通讯:
| 来源 | 说明 |
|---|---|
| Bytes | JavaScript |
| PyCoders | Python |
| Tech Talks Weekly | 技术演讲 |
核心概念速查
| 概念 | 说明 | 链接 |
|---|---|---|
| BDD | 行为驱动开发 | Wikipedia |
| CAP定理 | 一致性、可用性、分区容错性不可兼得 | Wikipedia |
| DDD | 领域驱动设计 | Wikipedia |
| DRY | 不要重复自己 | Wikipedia |
| GRASP | 通用职责分配软件模式 | Wikipedia |
| KISS | 保持简单 | Wikipedia |
| OOP | 面向对象编程 | Wikipedia |
| SOLID | 五大设计原则 | Wikipedia |
| TDD | 测试驱动开发 | Wikipedia |
| YAGNI | 你不会需要它 | Wikipedia |
| 两将军问题 | 分布式共识的基本限制 | Wikipedia |
关键要点总结
- 基础优于工具:深入理解原理(操作系统、网络、数据结构)比追逐框架更重要
- 简单优于复杂:能用单体解决的问题不要用微服务;100行简单代码优于20行复杂代码
- 先测量再优化:不要过早优化,先用数据说话
- 代码是负债,业务价值是资产:代码应易于删除而非易于扩展
- 持续学习是必须的:行业知识每年都在过时,保持初学者心态
- 沟通与写作是核心技能:好的4页文档胜过20页PPT
- 测试给你信心:主要写集成测试,不要太多,不要写端到端测试
- 故障是学习机会:事后复盘应无指责,关注系统改进而非个人追责
- 买优于构建:组织的专业能力有限,不要把精力花在非竞争优势上
- 记录一切:文档是给未来自己的信,也是团队知识传承的基础