前言

学习是一种基础性的能力。然而，“吾生也有涯，而知也无涯。”，如果学习不注意方法，则会“以有涯随无涯，殆矣”。

学习就像吃饭睡觉一样，是人的一种本能，人人都有学习的能力。我们在刚出生的时候，什么也不知道，是一张真正的白纸，我们靠学习的本能，学会了走路、说话、穿衣服…后来，我们上学了，老师把书本上的知识一点一点灌输到我们的脑子里，我们掌握的知识越来越多，与此同时，我们学习能力却好像越来越差了，习惯了被别人喂饱，似乎忘记了怎么来喂自己了。

学习本来只是一种本能，算不上什么能力，然而，经过二十多年的不断学习，学习反而成为了一种真正的能力，因为我们慢慢失去了它，它就更显得珍贵。

作为一个程序员，不断的学习更是重要，不学新的知识就迟早会被淘汰掉

我们都有一个共同的梦想——成为更棒的程序员，但是如何做？如何学习和精进自己的技术？如何做业务分析和架构设计？如何做技术管理？本文就广大程序员都很关注的问题提供一些思路和方法。

不想当工程师的程序员不是好民工。会编程不代表会工作，工程能力包含软硬技能，面向的是实际应用。从程序员变为工程师，得先“入门”，然后才是“上道”，从而成为“工型人才”。有人工作几年还没入门，只会简单开发；有人开发技能娴熟，却找不到进一步成长的路径，陷入迷茫之中；更有不少人自诩为IT精英，却不了解行业格局、发展趋势，很快就遇到职业发展瓶颈，蹉跎了岁月，虚度了青春。

在我看来，好的程序员应该是“工型人才”。所谓“工型”，是指从下到上的能力提升过程。具体来说，就是先要具备完成完整应用的能力，包括：线上运维，成为熟手，这是下面的一横；在某些领域足够深入，成为高手，这是中间的一竖；在达到更高的水平之后，兼通很多领域，比如业务、产品、项目管理、测试、运维、团队组织，成为驱动者和领导者，这是上面的一横。

每个人的成长都是不断打怪升级的过程，既要掌握技术和工具，又要学习方法和理论、积累实战经验，更要思考和沉淀。先进技术只是工具，最终目标是解决问题。经验丰富的工程师就像MMA（MixedMartial Arts，综合格斗）高手，精通综合技巧，活学活用，不拘泥于流派。在勇猛、精进之外，踏实、靠谱更为重要。踏实，是有自己的方向，知道差距；靠谱，是能把活儿干好，值得大家信赖，大家都乐于和你合作，放心把有挑战的任务交给你。

本文汇聚了多位资深技术老炮儿压箱底的傍身秘技，兼顾软硬技能，贯通了程序员从基础到进阶再到突破的各个阶段，道出了成长的真谛，更手把手地指引我们前行。有道是“师傅领进门，修行在个人”，徘徊在门外或者迷茫在路口的新同学，从此不必再上下求索、苦苦寻觅。一文在手，夫复何求？

希望你能通过本文，提升程序员的大局观，在成为“工型人才”的路上迈出坚实的一步，并穿越众妙之门，通达三千世界。

主要内容

本文内容分为三大篇：第1篇介绍程序员的技能成长路径，介绍如何通过学习来加速成长，并讲解非常重要的业务分析和设计知识；

第1章程序员技能与成长；时至今日，所言非虚。PC 早已广泛普及，智能手机、iPad 和智能终端已经“飞入寻常百姓家”。计算机课程教育虽然与时俱进，但离实际的企业应用还有很大的距离，仍有大量的内容需要在企业的项目、产品中进行实践，比如代码规范、软件测试、软件调试方法等。

本文大部分作者从业十多年，经历了从程序员到架构师，再到 TL、公司总监的转变，相信本书的内容会让读者有所受益。

**第2章加速成长与学会学习；**为什么要谈持续学习这个话题？因为知识总是会过时的，比知识更重要的是思维方式；另外，大部分人的聪明程度相差不大，有足够的练习和实践是必需的，终身学习才是成功者的必备法宝。

**第3章业务分析与设计；**业务分析指应用特定的方式或方法，把复杂的需求拆解成简单且容易理解的对象，并找出这些对象之间的关系。业务分析也是系统开发中最重要、最困难的阶段，只有依据业务分析的结果，运用合理的思想和方法，才能设计出理想的系统架构。如图所示，业务分析与设计是程序员进阶时要具备的最重要的能力，是从产品需求到编码实现的重要手段。

第2篇详细介绍了架构修炼中的必备架构思维模式、架构设计过程，还通过真实案例剖析了架构设计的核心要素及关注点，以及如何通过架构设计来把控质量和风险；

**第4章架构思维；**软件架构是一个系统的草图，描述了组成架构的组件及各个组件之间的关系，组件和环境之间的关系，以及设计组件的原则。组件可以是子系统、模块、类、方法等。

架构设计是架构决策的过程，涉及系统分解、接口定义、通信协议定义、交互关系和集成方式确定。架构决策指在架构设计中统筹全局并做出决定、权衡和取舍，比如将系统拆分为几个子系统，子系统的职责是什么，子系统之间如何交互，如何调用和采用什么集成机制，使用什么开发语言和技术框架。

**第5章架构设计；**在架构设计过程中，我们会根据需要做出不同的架构设计，而在设计时需要涉及一定的架构设计核心要素。

架构设计是从业务需求到系统实现的一个转换，是对需求进一步深入分析的过程，用于确定系统中实体与实体的关系，以及实体的形式与功能。架构可根据从业务需求到系统实现的不同需要分为：业务架构、应用架构、数据架构、技术架构。

第6章架构的保障:质量与风险；

6.1内建质量体系

6.2从黑天鹅事件到墨菲定律

6.3软件质量稳定性之殇

6.4从康威定律和技术债看研发

6.5求解质量嫡

6.6踩过的坑和经验总结

6.7故障复盘流程及模板

6.8监控与告警

6.9应急处置

第3篇总结了做技术管理的诀窍，揭秘如何从准备做技术管理到实现自我管理再到实现团队管理。

**第7章为成为技术主管做准备；**笔者在这个行业里面耕耘 10 年有余，在跟年轻朋友交流的时候，很多朋友都会问笔者一个问题：“我用什么方法才能成为像我主管那样的人？”

这个问题回答起来有点尴尬，因为很难用只言片语说清楚应该用什么样的既定方法去实现。“主管”这个人设被赋予了大量的标签和职能，其修炼并非一朝一夕即可完成，与其自身的思考深度及机遇也有很大关系。笔者思考良久，决定记录并分享自己的成长，希望对朋友们有所帮助。

**第8章从自我管理转为管理团队；**敏捷大师琳达·瑞思（Linda Rising）是变革模式（FearlessChange Pattern）的提出者，她曾说过：“我提出的这些变革模式的确看起来非常直白，但是直白绝不意味着简单。我努力在做的，就是让大家不但能够理解这些模式，还能够应用这些模式。”

程序员需要突破技术桎梏，在带人和带团队上不断成长，这似乎看起来也非常直白，却做起来绝对不简单。

俗话说，学而优则仕。在如雨后春笋般出现的各互联网和软件公司中，有越来越多的技术达人因为在技术上的优异表现，晋升为技术团队的管理者和领导者，这也被人们戏称为“编而优则仕”。然而，对于这些技术达人来说，从单枪匹马的个人贡献者突然被提拔为一呼百应的技术团队领导者时，随之而来的，除了兴奋，还有各种困惑和不适“症状”。因为，对于技术专家而言，在大多情况下做好自我管理就可以取得成功；而对于团队管理者而言，把一个队伍带好，注定是超越自我管理的挑战。

接下来就从对什么是领导力的追问开始，一步步探究技术团队管理者从自我管理到带好团队这一转变的背后，到底需要怎样的能力支撑。