《10x程序员工作法》
- 介绍：极客时间专栏《10x 程序员工作法》读书笔记 。
- 评价：这个专栏真心还不错，介绍了很多程序员相关的方法论，非常实用！不过，对于其他行业来说，这些方法论也是通用的，比如说以终为始、任务分解......。
- 作者：Guide哥
软件行业里有一本名著叫《人月神话》，其中提到两个非常重要的概念：
- 本质复杂度（Essential Complexity）
- 偶然复杂度（Accident Complexity）
简单来说，本质复杂度就是解决一个问题时，无论怎么做都必须要做的事，而偶然复杂度是因为选用的做事方法不当，而导致要多做的事。
大多数人工作低效是由于工作中偶然复杂度太多造成的，只要能够更多地将注意力放到本质复杂度上，减少偶然复杂度造成的消耗，我们“真实”的工作效率自然会得到大幅度提升。
思考框架
1975 年，弗雷德里克·布鲁克斯（Frederick Brooks）出版了软件行业的名著《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的 10 倍。40 多年过去了，这个数字得到了行业的普遍认同。
一个常用的思考框架：
- Where are we?（我们现在在哪？） ：现状
- Where are we going?（我们要到哪儿去？） ：目标
- How can we get there?（我们如何到达那里？） : 实现路径
示例：
- 我现在是个什么水平？
- 我想达到一个什么水平？
- 我将怎样到达那个目标？
给出思考框架是为了让你明白为什么要提出问题，而具体问题要怎么问，就可以遵循下面这四项思考原则：
- 以终为始 ： 在工作的一开始就确定好自己的目标
- 任务分解 ：将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作
- 沟通反馈 ：保证自己的信息能够传达出去，保证我们能够准确接收外部信息。
- 自动化 ： 将繁琐的工作通过自动化的方式交给机器执行。
思考框架是道，原则是演化下的术，我们从 A → B，有无穷无尽的路径，最有效的唯有那条直线。本质上，各个维度、原则（不限于作者提到的四项原则）都是帮助我们更好地定位 A 在哪里，B 在哪里，那条直线在哪里。
面对问题时，用思考框架问问自己，现状、目标和路径。
以终为始
以结果为导向考虑事情
践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。
举两个例子：
- 考研 ： 先要想清楚考研能够给自己带来自己需要的东西， 再去思考如何准备考研，最后才是开始准备考研。
- 找工作 ：先搞清楚自己要找什么工作，然后根据招聘岗位的要求梳理一份技能树，根据技能树写好最终的简历，最后再按照建立的要求去学习和提升。
确定验收标准
对于功能需求/迭代的完成，不同的人或者角色之间可能会存在理解偏差。因此， 在做任何事之前，先定义完成的标准/验收的标准。
持续集成
什么是集成？
集成就是把团队不同开发人员的代码集中在一起，使之成为一个可工作软件。
我们应该把开发的完成定义为代码已经集成起来，而站在个体的角度，我们应该尽早提交自己的代码，早点开始集成。
什么是持续集成？
持续集成是一种 DevOps 软件开发实践。采用持续集成时，开发人员会定期将代码变更合并到一个中央存储库中，之后系统会自动运行构建和测试操作。持续集成通常是指软件发布流程的构建或集成阶段，需要用到自动化组件（例如 CI 或构建服务）。持续集成的主要目标是更快发现并解决缺陷，提高软件质量，并减少验证和发布新软件更新所需的时间。
为什么需要持续集成？
过去，一个团队的开发人员可能会孤立地工作很长一段时间，只有在他们的工作完成后，才会将他们的更改合并到主分支中。这使得合并代码更改变得困难而耗时，而且还会导致错误积累很长时间而得不到纠正。这些因素导致更加难以迅速向客户交付更新。
持续集成的工作原理是什么？
- 开发人员使用诸如 Git 之类的版本控制系统，将更新频繁提交到共享存储库中。
- 每次提交前，开发人员可以选择在集成前对其代码执行本地单元测试，这是第一层保障。
- 持续集成服务在新代码更改上自动构建和运行单元测试，以立即发现任何错误。
产品经理不靠谱咋办？
很多人想进入 IT 行业，一看程序员需要会写代码，觉得门槛高，那就从产品经理开始吧！这些人对产品经理岗位职责的理解是，告诉程序员做什么。
在当下，产品经理并不是一个有很好行业标准的职位。
当你被要求开发一个新特性/功能的时候，可以问产品经理/业务分析师这些问题：
- 为什么要做这个功能，它会给用户带来怎样的价值？
- 什么样的用户会用到这个功能，他们在什么场景下使用，他们又会怎样使用它？
- 达成这个目的是否有其它手段？
- 这个功能上线之后，怎么衡量它的有效性？
问了这些问题之后，你既可以知道这个新功能的价值，又可以避免产品经理/业务分析师是拍脑袋想出来的。
如果产品经理使出了必杀技：“这是老板的需求”。那咱们就一起去老板那里探讨一下呗？
当你和产品理论的时候，他可能经常会拿出来一个现有的产品给你看:“人家怎么就能做到，人家能做到说明技术上是可行的，做吧。”时间久了你会发现他的需求全是抄的的别的 APP，然后就觉得别人能做到的我们也一定能做。
这种情况下， 你需要分清楚两件事，技术与需求。要做什么是需求，能不能做是技术。与产品经理要确认的是需求是否合理，技术上能不能实现是技术团队要考虑的问题。如果需求合理，技术上难以实现，或成本太高，就把决策上升一级，由上一层领导帮忙确认，此时此刻，在现有资源约束的情况下，是不是要做这么做，同时，最好提供一个可替换的简单方案，让领导有选择。
别把自己局限在“程序员”这个角色里
程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。
技术是一把利刃，程序员相信技术可以改变世界，但并不是所有问题都要用技术解决。
每一个人都希望自己在职业的阶梯上步步高升。假如今天就让你往上走一个台阶，比如，你原来在项目里打杂，现在成为项目的主力，或者，你已经对项目细节驾轻就熟，即将委任你为项目负责人。你是否能胜任呢？
不同角色工作真正的差异在于上下文的差异。 举个例子：你在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的。所以说无论单点有多努力也只是局部优化，很难达到最优的效果。
想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。
扩大自己的上下文，目光不再局限于自己的一亩三分地，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。
想清楚了再写代码
想清楚了才能写清楚，这是我在编程工作非常认可的一句话，并且我也认为它是区分合格与不合格开发工程师的重要区别。软件开发过程中，最常见的例子就是拿到需求后不管三七二十一，上来就开始撸代码，但最后往往返工不断，质量问题层出不穷，而且加班没完没了，这里面一个根本原因就是没有系统地想清楚，但很多人都觉得前期澄清需求、分析设计是浪费时间，只有编码才是真正的创造价值，这就是差距。
项目准备好的实践：迭代 0。
迭代 0 指的是在正式开发迭代开始之前，进行一些基础准备的实践。
迭代 0 准备清单参考 ：
这份清单包含了需求和技术两个大方面，你可以参照它设计你自己的迭代 0 清单。
即便你做的不是一个从头开始的项目，对照这个清单，也会发现项目在某些项上的欠缺，可以有针对性地做一些补充。
任务分解
任何领域都适用的一个理论。
软件开发的任务分解
把一个大问题分解为小问题，这样可以更容易解决/得出答案。
任务分解和敏捷开发的用 user story 是相似的,首先我们会定义大的 feature,这个是大的产品经理关注的,然后我们基于 feature 分解成不同的 user story,最后每个 story，再分解成一个个具体的 task,我们程序员就主要解决 task。
示例：假如你要修复一个 rpc 接口的 bug。你可以先列出每个代码的修改点，要修改的测试，要增加的测试，合并到哪个分支，修改 rpc 文档，文档中有哪些点要修改。每一步都非常容易执行，看起来每多少必要，但在我当前的工作环境特别有用：1）事前思考，不会造成遗漏，2）任务实施过程中经常被打断，比如，测试有疑问和你讨论，主管找你谈事，紧急会议来了，这种“硬中断”完全打破了节奏，而任务列表，让我知道清楚当前做了多少，该从哪一步继续。
任务分解的好处总结：
- 大问题简化成小问题便于解决
- 让自己的工作可以被量化。
- 可以加强对任务工作量估算的能力。
- 可以掌控项目的进度。
- 每完成一组任务就可以提交一个 PR，这时就可以去休息一下。之前是一直坐到「天荒地老」...而且
写好测试
在软件开发中有一个重要的概念：软件变更成本，它会随着时间和开发阶段逐步增加。也就是说我们要尽可能早地发现问题，修正问题，这样所消耗掉的成本才是最低的。
对于每个程序员来说，只有在开发阶段把代码和测试都写好，才有资格说，自己交付的是高质量的代码。
测试模型：
- 蛋卷
- 金字塔
听说过冰淇淋蛋卷测试模型的人并不多，它是一种费时费力的模型，要准备高层测试实在是太麻烦了。
测试金字塔这种测试模型是行业里的最佳实践。
从这个模型中我们可以看出单元测试覆盖面是最大的，我们在平时开发过程中也要多写单元测试。
Mike Cohn 在自己的著作《Succeeding with Agile》提出了测试金字塔，但大多数人都是通过 Martin Fowler 的文章知道的这个概念。
想要理解测试金字塔成为行业最佳实践的缘由，我们需要理解不同层次测试的差异。越是底层的测试，牵扯到相关内容越少，而高层测试则涉及面更广。 比如单元测试，它的关注点只有一个单元，而没有其它任何东西。所以，只要一个单元写好了，测试就是可以通过的；而集成测试则要把好几个单元组装到一起才能测试，测试通过的前提条件是，所有这些单元都写好了。
除此之外，测试金字塔还是我们之前提到的持续集成的基础。
不愿主动写测试代码的程序员，不太可能是优秀的程序员
测试驱动开发
一些优秀的程序员不仅仅在写测试，还在探索写测试的实践。有人尝试着先写测试，于是，有了一种实践叫测试先行开发。还有人更进一步，一边写测试，一边调整代码，这叫做测试驱动开发，也就是 TDD。
TDD 的节奏：“红 - 绿 - 重构”。
TDD 在很多人眼中是不实用的，一来他们并不理解测试“驱动”开发的含义，但更重要的是，他们很少会做任务分解。而任务分解是做好 TDD 的关键点。只有把任务分解到可以测试的地步，才能够有针对性地写测试。
任务分解真实案例 : Wiki 的发明者 Ward Cunningham 每天拿到一个需求，他并不急于写代码，而是先进行任务分解，分解到每个任务都很清晰了，才开始动手做。接下来就简单了，一个任务一个任务完成就好了。在开始工作之前，很多觉得非常难以解决的问题，结果一路分解下来，每一步都是清晰的，也没遇到什么困难就完成了。
需求优先级
需求分解之后，最重要的是，排列需求的优先级。优先级的排列方式有很多，我们可以借鉴时间管理的方法，把事情按照重要和紧急的维度进行划分，得到了四个象限。我们要尽可能把精力放在重要的事情上，而不是把紧急的事情当成优先级排序的方式。
需求为什么要区分优先级？
因为时间是有限的，有限的时间内你能完成工作的上限是一定的。怎么充分利用好有限的时间，这其实是一个时间管理的问题。所以，我们完全可以借鉴时间管理领域的一些优秀实践，帮助我们更有效地明辨优先级。
最小代价产品
产品同样需要分解，目前在探索产品的不确定性上的最佳实践是精益创业，而精益创业就包含了将庞大的产品分而治之的方式：最小可行产品（Minimum Viable Product，MVP）。最小可行产品就是“刚刚好”满足客户需求的产品。
Q&A
1.在一个自己不熟悉的，充满未知的项目中该怎么更好地进行任务分解？
先把它变成你熟悉的技术。通过一次技术 Spike ，学习新技术；
2.项目时间紧，该怎么办？
先搞清楚项目当前时间紧的问题，然后进行改进。
沟通反馈
我们努力地学习各种知识，为的就是更好地理解这个世界的运作方式，而沟通反馈，就是我们与真实世界互动的最好方式。
代码
代码是程序员与机器沟通的桥梁，写好代码是每个程序员的追求，一个专业程序员，追求的不仅是实现功能，还要追求代码可维护。如果你想详细学习如何写好代码，我推荐你去读 Robert Martin 的《代码整洁之道》（Clean Code），这本书几乎覆盖了把代码写好的方方面面。
命名，是写程序中最基础，也是一个程序员从业余走向专业的门槛。一个好的命名需要你对业务知识有一个深入的理解，遗憾的是，这并不是程序员的强项，需要我们额外地学习，但这也是我们想写好代码的前提。现在，你已经理解了，取个好名字，并不是一件容易的事。
可视化
图像能够更直观地展示信息。
举例：ThoughtWorks 技术雷达（将技术趋势可视化）、项目看板（将我们正在进行的工作变得可视化）。
复盘
什么是复盘？ 把一件事情的过程还原，进行研讨与分析的方式，找到改进的方法，就是复盘。
为什么要经常复盘？ 在软件研发中，许多问题是反复出现的，很多开发团队会因此陷入无限“救火”中，解决这种问题一个好的办法就是复盘。
复盘是为了找出问题的所在，而不是为了责备别人。
要让团队认识到复盘的重要性。让每个人都深入思考项目运作过程中遇到了哪些问题。才能做好复盘。
关于复盘，孙陶然曾经说过，如果他有所成就，一半要归功于复盘。他提出了几个步骤供大家参考。首先，先对比实际结果和起初所定目标之间有什么差距。其次，情景再现，回顾项目的几个阶段。然后，对每个阶段进行得失分析，找出问题原因。最后，总结规律，化作自己的技能沉淀，再次遇到时可以规避。
推荐一个比较实际的每日复盘方法（可根据自身情况修改完善）：
- 身体 ：也就是我的身体健康，其中包括运动，饮食，睡眠，还有冥想。因为好的身体，才是一切的动力来源。
- 认知和学习 ：比如像通过极客时间专栏的学习，对认知的提升，还有英语的学习和技术的学习。
- 工作 ：对前一天工作的总结，并且提炼出成就事件和需要改进的方面。
- 业余生活 ：业余时间干了什么，对自己是否有意义。
- 人际关系 ：也就是如何和自我相处，如何和他人相处，如何维持好的人际关系
- 投资理财 ：就是自己在理财知识方面的学习和一些理财实践。
走近用户
作为一个程序员，欠缺用户视角，在与产品经理的交流中，你是不可能有机会的，因为他很容易用一句话就把你打败：“这就是用户需求。”
无论是自己做用户，还是找机会接触已有用户，亦或是没有用户创造用户。只有多多听取来自真实用户的声音，我们才不致于盲目自信或是偏颇地相信产品经理。 谁离用户近，谁就有发言权，无论你的角色是什么。
尽早暴露问题
试想一下：当你在一条错误的道路上走到尽头才暴露问题好还是一开始就暴露错误好？
把事情往前做，尽早暴露问题。越早发现问题，解决的成本就越低，不仅仅是解决问题本身的成本，更多的是对团队整体计划的影响。
一方面，事前我们要通过“以终为始”和“任务分解”早点发现问题；另一方面，在做事过程中，一旦在有限时间内搞不定，尽早让其他人知道。
这个原则在写程序中的体现就是 Fail Fast，很多程序员因为没有坚持这个原则，不断妥协，造成了程序越来越复杂，团队就陷入了无尽的泥潭。
原则很简单，真正的挑战在于克服自己的心理障碍。很多人都会下意识地隐瞒问题，但请相信你的队友，大家都是聪明人，问题是藏不住的。
精彩留言：
- 程序员通常都有这种缺点：遇到自己不会的技术后，碍于面子，打心眼里不愿意求助别人，更不想把这种状态让领导知道，因为自认为这是一种低能的表现，导致最后被动的被别人发现。提早的主动暴露问题，确实能规避很多问题，让项目朝良性发展方向，但是这是有前提的，除非你的老板是个开明的人，否则你主动暴露问题，不开明的老板就认为你能力欠缺，最终的绩效评估受伤的还是你自己啊……
- 及早暴露问题其实是反人性的，因为意味着要向领导或众人展示自己的无知。回顾过往某个项目的时候，发现自己其实在过程中已经意识到存在问题，但因此要暂停项目、产生更多成本，就会下意识安慰自己说，其实问题没那么严重，就这么来吧，问题会解决的。现在想想，这种心态真是要不得。及早承认问题，袒露自己的不足，并积极寻找解决方案，才是成熟的标志
如果今天的内容你只记住一件事，那请记住：事情往前做，有问题尽早暴露。
写文档也是一种学习方式
程序员对文档有着一种矛盾的情感，一方面，需要依赖于文档获得知识，另一方面，很少有人愿意写文档。
文档在程序员心目中“形象不佳”，主要是传统的流程写了太多无用的文档。但对更多人来说，不愿意写文档，本质上是因为知识不能很好地结构化。
有结构的知识会让新知识的学习变得更加容易，今天很多人抱怨新知识层出不穷，就是因为知识过于零散，当知识有结构之后，学习新知识就只是在学习增量，效率自然就会大幅度提升。
输出是一种很好的方式，帮助你把知识连接起来，写作和做公开演讲都是很好的输出方式。
阻碍很多人进行知识输出的一个重要原因是缺乏输出的模型，金字塔原理就给出一个从中心论点到分论点，再到论据的模型，帮助我们将知识梳理出来。
而想要做好知识输出，还需要不断地进行练习，写作和做公开演讲都是可以通过练习提高的。
多输出，让知识更有结构。
Q&A
1.老板参加复盘，不敢说真话怎么办？
回顾会议的目的在于改进，它不仅仅在于让大家参与进来，更重要的是让团队成员能够敞开心扉，把问题暴露出来。暴露问题，是改进的前提条件。
对于很多人来说，敢不敢暴露问题是个心理问题。你会发现，同事之间聊天，普遍是没有任何压力的，你几乎可以放心大胆地谈论各种问题，而一旦有领导在，很多顾虑就会出现了。
于是，问题就变成了怎么能够让大家放心地把问题暴露出来，一个办法就是设置一个安全的环境。怎么设置一个安全的环境呢？
对于标准的回顾会议来说，第一步应该是做安全性检查。先由大家投票，最简单的方式是就是，给当前的环境打分。你觉得可以畅所欲言就打 1 分，你觉得还好，就打 0 分，如果你觉得不方便表达，比如，你看领导在，很多问题不适合反馈，就打 -1。每个与会者都投出属于自己的一票。然后，主持人根据投票结果决定回顾会议是否进行，比如，有人投 -1 就不能继续。
当老板离席之后，我们再进行一轮投票，判断环境是否变得安全了。如此反复，也许要进行几轮投票，直到大家觉得安全了。当然，也有可能进行多轮，有人始终觉得不安全，那可能最好的选择是，取消今天的回顾会议，换个时间地点从头再来。而项目负责人则需要私下里解决一下团队内心安全的问题。
2.国内的技术信息落后吗？
过去，学习新知识确实要多看看英文网站，当时的信息传播速度不快，中文技术网站不多。
现在，显然已经不是这样了。你通过国内的已经有的资源完全可以了解到最新的技术信息，比如前面介绍的ThoughtWorks 技术雷达。
国内程序员真正落后的不是信息，而是观念。
自动化
“懒惰”应该是所有程序员的骄傲
Perl 语言的发明人 Larry Wall 曾经说过，优秀程序员应该有三大美德：懒惰、急躁和傲慢（Laziness, Impatience and hubris）。
- 懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
- 急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
- 傲慢，极度自信，写出（或维护）别人挑不出毛病的程序
想要成为一个优秀的程序员，就要让机器为自己很好地工作，而这需要对自动化有着很好地理解。
我们学习自动化，先要知道哪些东西不要自动化，尽最大的努力不做浪费时间的事。一方面，我们要从需求上规避那些没必要做的事；另一方面，我们也从自身防止 NIH 综合症（Not Invented Here Syndrome），争取做一个懒惰的程序员。
NIH 是什么意思？ 就是有人特别看不上别人做的东西，非要自己做出一套来，原因只是因为那个东西不是我做的，可能存在各种问题。
程序员怎么学习运维知识？
持续交付
什么是持续交付？ 简言之，它就是一种让软件随时处于可以部署到生产环境的能力。
一般来说，在构建持续交付的基础设施时，会有下面几个不同的环境。
- 持续集成环境，持续集成是持续交付的前提，这个过程主要是执行基本的检查，打出一个可以发布的包。
- 测试环境（Test），这个环境往往是单机的，主要负责功能验证，这里运行的测试基本上都是验收测试级别的，而一般把单元测试和集成测试等执行比较快的测试放到持续集成环境中执行。
- 预生产环境（Staging），这个环境通常与生产环境配置是相同的，比如，负载均衡，集群之类的都要有，只是机器数量上会少一些，主要负责验证部署环境，比如，可以用来发现由多机并发带来的一些问题。
- 生产环境（Production），这就是真实的线上环境了。
如果把由人决定的是否上线变成自动化的，就成了另外一个实践：持续部署。
DevOps 是一种软件交付的理念和方法，目的是增强软件的可靠性。从名字便不难发现，DevOps 是将开发（Development）和运维（Operations）组合在了一起。
不要用了用技术而用技术
为了技术而技术的程序员不在少数，过度使用技术造成的结果就是引入不必要的复杂度。即便用了牛刀杀鸡，因为缺乏真实场景检验，也不可能得到真实反馈，对技术理解的深度也只能停留在很表面的程度上。
拿淘宝来说，淘宝的工程师之所以要改进系统，真实的驱动力不是技术，而是不断攀升的业务量带来的问题复杂度。
评估系统当前所处的阶段，采用恰当的技术解决，是我们最应该考虑的问题。
综合运用
新入职，如何快速进入工作状态？
运用上面介绍的思考框架：
- Where are we?（我们现在在哪？） ：对公司业务有一个简单地了解
- Where are we going?（我们要到哪儿去？） ：把第一步的目标制定成能够达到上手工作的程度
- How can we get there?（我们如何到达那里？） : 分解如何达到这个目标。
技术解决的是“怎么做”的问题，而我们第一个应该了解的问题是“做什么”。一个软件到底在做什么，能够回答这个问题的就是业务。所以，我们排在第一优先级的事情应该是业务。
了解业务和技术都只是让你扮演好你个人的角色，但我们通常都是在一个团队内工作的，所以，还要解决好与其他人协作的问题，这就需要我们了解团队本身是如何运作的。
这样的话，上手工作这个大目标就被分解为了三个小目标：
- 业务；
- 技术；
- 团队运作。
附赠一点小技巧：使用“行话”。在交流的过程中，学习一点“行话”。这会让人觉得你懂行，让你很快得到信任，尽早融入团队。
面对遗留系统怎么做？
庞大的遗留系统可能存在各种问题比如代码腐化、稳定性不够。
面对庞大的遗留系统，我们可以再次回到思考框架上寻找思路：
- Where are we?（我们现在在哪？） ：分析遗留系统存在问题的根因
- Where are we going?（我们要到哪儿去？） ：我们的目标是解决这些存在的问题。
- How can we get there?（我们如何到达那里？） : 分解如何达到这个目标。
对于改造遗留系统，有几个小建议：
- 构建测试防护网，保证新老模块功能一致；
- 分成小块，逐步替换；
- 构建好领域模型；
- 寻找行业中关于系统构建的最新理解。
如果今天的内容你只能记住一件事，那请记住：小步改造遗留系统，不要回到老路上。
如何保持竞争力？
T 型人
什么叫 T 型人？ 简言之，一专多能。
有了“一专”，“多能”才是有意义的，否则，就是低水平重复，而这正是很多人职业生涯不见起色的真正原因。
**这里的“专”不是熟练，而是深入。**你可能是个有着 10 年丰富经验的程序员，但实际上只不过是重复了 10 年解决同样难度的问题而已，这根本就不算深入，也就没有做到真正意义上的“一专”。
你会发现很多优秀的人，在很多方面都会很优秀，这是“一专”带来的触类旁通。
学习区成长
Noel Tichy 提出了一个“学习区”模型，如下图所示：
- 舒适区（Comfort Zone） ：置身其中会让人感觉良好，但也会因为没有挑战，成长甚微，你可以把它理解成做你最熟悉的事情。
- 恐慌区（Panic Zone） ：这是压力极大的地方，完全超出了你的能力范围，你在其中只会感到无比的焦虑。
- 学习区（Learning Zone） ：事情有难度，又刚好是你努力一下可以完成的，这才是成长最快的区域。
结束语
这个专栏真正探讨的主题是： 有效工作 。
有效工作，需要我们把力量聚焦到正确的地方，做本质复杂度（Essential Complexity）的事情，少做无意义的事情。
怎么才能有效工作呢？
- 拓展自己的上下文，看到真正的目标，更好地对准靶子，比如，多了解用户，才不至于做错了方向；站在公司的层面上，才知道哪个任务优先级更高；站在行业的角度，而不局限于只在公司内成为高手，等等。
- 去掉不必要的内容，减少浪费，比如，花时间分析需求，不做非必要的功能；花时间做好领域设计，别围着特定技术打转；花时间做好自动化，把精力集中在编码上，等等。
要想有效工作，有两点非常重要。一方面，意识上要注意自己工作中无效的部分。另一方面，要构建自己关于软件开发的知识体系，这是要花时间积累的。在这个专栏中，我给你讲了很多最佳实践，就是让你知道，在某些方面，有人已经做得很好了，花时间学习，比自己从头摸索好很多。
更新: 2022-02-18 12:57:53
原文: https://www.yuque.com/snailclimb/to3hqu/ytgyz2