转自http://www.cnblogs.com/zhengyun_ustc/p/upgrade.html
认真学习数据库原理、操作系统、TCP/IP、组网、算法等等基础知识的英文原版书摞起来就等身，认认真真看完，各种上手实践，入行后，读遍 C++ 各种经典著作，读遍各种协议原文，认认真真打基础。
何谓知识体系？
几年前，前支付宝架构师姚建东曾经在我们公司做过技术人员如何规划自己的分享讲座，他是这么论述的：
技术与技巧包括：
- 计算机基础理论
- 计算机模型：内存/IO/时钟/CPU……
- 算法
- 专项技术领域：
- 数据挖掘
- 数据管理
- 智能推荐
- 搜索
- ……
- 语言与工具
- 语言与相关体系
- 开发工具，分析工具，代码管理工具
- HTML/CSS/JS/Ajax
- 常用框架与第三方类库
- 调试与测试
- 调试方法和哲学
- 定位问题
- BUG管理工具
- 单元测试
- 集成测试
- 性能测试
- 安全测试
- 兼容性测试与方法
- JS/Ajax测试与方法
- 服务层测试
- Web层测试
- 网络与系统
- TCP/IP协议与模型，HTTP/SMTP等协议
- Linux系统，网络分析工具，系统分析工具
- 容量，流量与负载均衡
- 应用部署、规范、规划
- 安全
- 监控与故障分析
- 磁盘与存储
- Shell
- DNS与域名
- 缓存，反向代理
- 图片服务器（海量小文件）
- 需求挖掘与分析
- 需求文档格式
- 需求访谈
- 需求分析方法，需求分析工具
- 领域知识与经验
- 系统分析与设计
- UML语言与模型
- 分析模式
- 设计模式，领域驱动
- 系统分析文档格式
- 系统设计文档格式
- 功能性需求与非功能性需求
- 数据与系统
- 数据库
- 可伸缩策略，扩展策略，备份，容灾，性能，安全，高可用……
- 数据设计与范式，SQL/NoSQL，Cache，分布式文件
- 架构设计
- 架构模式，典型互联网公司架构演进历史
- 架构原则，常用策略
- 架构设计方法
- 非功能性理解
- 扩展性
- 伸缩性
- 稳定性
- 一致性
- 性能
- 吞吐量
- 容量预测与规划
- 架构体系与相关技术
- 过程与管理
- 分析过程
- 研发过程
- 评审过程
- 测试过程
- 发布过程
- 回滚过程
- 文档管理
- 知识管理
- 项目管理
以上其实就是一份从业基础知识清单，你可以按图索骥，阅读相关书籍。
第二阶段 顺着一个Topic钻进去，锻炼自己的预研能力
无论公司业务还是自己喜欢做的事，都可以抽象出通用性课题，然后以做论文的方式杀进去。这个事情得反复操练，有意识操练。
做事方式为：
- 抽象出 Topic——如分布式锁，分布式并行计算引擎，防CSRF的FormToken自动生成框架，定时任务管理与调度平台，分布式跟踪，等等
- 向功课好的学生学习——有针对性地深入了解业界其他公司是如何分析问题和解决问题的，汇总各种方案，站在巨人的肩膀上
- 分析特定应用场景，技术选型
- 兼顾高可用性和可伸缩，做设计评审
- 做测试自证靠谱，梳理知识点，开技术分享会
- 上线商用，总结经验教训，开经验分享会
- 为什么要写出来、讲出来呢？因为有一个学习金字塔理论，如下图所示：
我们读过的事情能够记住学习内容的10%，我们听过的事情能够记住20%，我们看过的事情能够记住30%，我们听过和看过的事情能够记住50%——如看影像/看展览/看演示/现场观摩，我们说过的事情能够记住70%——如参与讨论/发言，我们说过和做过的事情能够记住9%——如做报告，给别人讲，亲身体验，动手做。这也就是我在《窝窝研发过去几年做对了哪些事》中阐述的管理方法：我们从入职之后就有意识地训练大家，让大家能够公开陈述、清晰表达。所以，试用期内，新人必须做一次技术分享和一次技术评审，面对各方的 challenge；预研的中间和结尾都要有分享会；平时也要定期组织技术讲座。
第三阶段 疯狂回答技术问题
知识体系慢慢构建，与业务相关的抽象 Topic 也在探索中。
但这还不够。
因为你亲身接触到的世界太小，可能不足以构成挑战，你可能意识不到自己缺多少知识和技能，不利于你分析问题、提出问题和解决问题的能力培养。
所以，要主动出击：
疯狂回答问题。
试着攻克那些疑难问题，或者离奇故障，绝对不会浪费你的时间。
为什么？
因为你要信奉：
你学过的每一样东西，你遭受的每一次苦难，都会在你一生中的某个时候派上用场。——佩内洛普·菲兹杰拉德 《离岸》Everything that you've learnt and all the hardships you've suffered will all come in handy at some point in your life.
第四阶段 RCA/总结
现在是你把经验教训变为财富的时刻了。
什么是好的技术 Leader？
随便一个业务需求或业务场景讲出来，你立刻把它抽象为几个模块/系统/Topic，然后侃侃而谈，业界都是怎么解决的，我们以前又是怎么分析怎么解决的，现在咱们这种情况下应该如何设计，可能会遇到什么问题，我们应该做哪些预防设计，blabla。
这就是我们的 RCA（Root Cause Analysis）制度，截止到目前已经收集整理了近两百个详尽的 RCA 报告。』
RCA 报告格式为：
- 背景知识（Optional）
- 问题现象
- 影响范围
- 问题原因
- 问题分析过程（Optional）
- 解决办法
- 后续处理措施：如线上脏数据如何修复，如对用户造成的影响如何弥补等（Optional）
- 经验教训
- RCA类型：如代码问题、实施问题、配置问题、设计问题、测试问题
第二，写总结。
话说，要经常拉清单。
侃侃而谈得有资料，这些都得是你自己写才能印象深刻，关键时刻想得起来。
-------------------------------------------------------------------------
1.就我感觉吧，现在阶段要好好去学习专业知识，特别是基础课程，有时间就去多读一些还没有开始的基础课，或开设的课没有讲到的地方。
2.积极去拓宽自己的知识领域
3.积极的帮其他人解决问题，并将他们常犯的的错误进行总结
4.在学习过程中，去找刚兴趣的 Topic进行研究
5.积极的去总结自己的知识