简介

古人说：“活到老，学老。”日新月异，许多工程师不堪㊣　重负，抱怨不断。以至于长期以来一直存在一个普遍的误解：35 岁是程序员工作的终点。

如何在忙碌的工作中积累技术，打造个人核心竞争力，相信是很多工程师都在思考的问题。这篇◇文章是我自己的一些总结，试图从三个方面来回答：

如何学习

在忙碌的工作中，坚持不懈、不断学习进步是一项艰巨的任务，需要坚强的毅↑力和坚定的决心。如果方法不对，效果会更差。幸运的是，我们古今的哲学家总结了许多优秀的研究方法，这里有一些重要的原则。遵循这些方法，将对大家的工作和学习大有裨益。

你在坚持

据悉，过去几十年的知识量超过□了前几千年的知识量。计算机领域绝对是现代知识更新最快的领域之一。因此，工程师必须接受他们现在拥〖有的深度知识系统很快就会过时︻的现实。如果你想在计算机领域继续成为一名优秀的架构师，你必须不断学习并掌握最新的技术。毕竟是学不来的。

所谓“冻三尺，非一日之寒，一滴水一石，非一日之功”，建筑师之路漫长而艰辛。如果你轻易放弃，你所有的努力都会在瞬间∩付诸东流。 如果你想成为一名优秀的建筑师，你需要持之以恒！

虽然知识更新很快，但卐基础理论变化很慢。这就是“道”与“象”的关系。世间虽有万象，但道始终如一。对于那些非常基础的理论知识，我们需要经常复习，也就是“时不时的学习和学习”。

注意练习

古人说：“纸上谈兵，浅尝辄止，无所不知，必练。”学习领域有一个所谓的721模式：个人◣成长的70%来◣自于在职实践，20%来自于向他人学习，10%来自于培训。尽管这个理论是有争议的，但工程师通☆常最好根据实践、学习和培训来●排列他们的重要性。因此，重视实践，在实践中成长是最重要的学习原则。

人类的认知有两种：感性认知和理性认知☆。这两种认知是不可替代的。很大程度上，实践来自感性学习，而阅读更像是理性学习。以学开车为例，很难想象有人会通过学习书本知识来开车。

书本知识主要是╲说教——讲¤抽象原型，而对其具体应用场景的描述往往比较模糊，抽象原型之间的关系也很浅薄。使用相同的精确语言来ㄨ描述应用场景和关系会失去焦点和混淆。所以，读书成长就像单腿走路。

正确的学习方式是重视实践，充分发挥感性认知潜能，在项目中磨练自己。在实践中，对一些关键动作进行刻意练习，也会达到事半功倍的效果。

价值沟通

牛顿说：“如果我比别人看『得更远→，那是因为我站在巨人的肩膀上。”我们需要向别人学习。向老师、领导、同事、下属甚至对手学习，是快速成♀长的重要手段。

向♀老师和领导学习已经成为人们生活的一部分♀。但向同事甚至对手学习也很重要，因为这些人与我们更相似。所以，要多观察，取其长，舍其短。对于团队的◣小兄弟和属下，也“不耻下问”。

此外，积极参与项目中具体选项的讨论非常重要。参与者对相∑　关背景有先验感知，所讨论的想法和建议是演讲者多种知识和技能的结合。因此，讨论让参与者以非常全面和立体的方式理解书籍知识。同时与专家※讨论，他们的意见会像剪▓枝机一样，快速斩断自己知识领域的疑惑。

注意总结和输出

工程师在实践中会掌握很多细节，但即使掌握了所有细节，在没有深入总结和思考的情况下也会陷入“学习思考”。不思则无动于衷”。成长的“量变”来自于对细节的渐进深入的把控，而真正的“质变”来自于对“道”的更深理解.

输出经验，接受别人的考验，是一个高层次的总结。这种输出不仅对↙别人有帮助，对自己也有很大的好处。总结的方法有很多，包括组织分享、写技术文章等〗等。当然，“一日三餐”也是一个很好的】概括方式。总之，多多总结，多多分享，太好了！

回答别人的问题也是个人成长的重要手段。有时候，我对某个问题不太了解』，但是当我向别人解释时，它突然变得清晰了。所以，“教人孜孜不倦”是利人利己。

专注于规划

对外一切都是成立的，如果」没有伏笔，就会失败。一个好的㊣计划是长期学习生涯成功的一半。

长期规划

长期规划的实施需要毅力和决心，但做正确的长期规划也需要远见、超敏感的神经和中⌒　大奖的运气。对大多数人来说，长远规划主要是“定方向”。但是，遵循以下原则可以降低出现方向错误的概率：

短期规划

一个好的短期规划应该在生活、成长、绩效和晋升之间取得平衡。大多数公司都会有一个评估周期——短则一个月，长则一年。因此，建议将评估周期用作短期学习计◤划周期。规划本质上是一个多目标优化问题，有一系列理论解，这里不再详述。根据◇相关理论，我给出一■个简单易行的方案：

对于这个计划№，请注意以下几点：

此外，短期规划还可以从以下几个方面进行优化：

那些纠结▽的困惑

人生是一场○马拉松，漫漫长路难免有很多迷茫。迷茫就像桎梏让我们跌跌撞撞，迷茫是让我们停滞不前的僵局。

接下来，我将总结一些我在工作中遇到和看到的典型困惑。这些困惑一直困扰着作者本□人，或者困扰着身边的同事和╳朋友。当这些迷惘一扫而空，每个人都仿佛重新得到了释放，为下一阶〗段的旅程提供了满满的正能量。人生就像一场旅行。你不必关心目的地。你在意的应该是沿途的风景和看风景的心情。良好的心态是科技之旅的最佳伴侣。希望通过这次解谜之旅，让大家有愉快的心情体验漫长的学习之旅。

学习没有①尽头吗？

我们必须承认一∩个残酷的现实：人的生命是有限的，但知识是无限的。用有限的生命学习无限的知识♂是不可能完成的任务。想到这里，一些工程师不禁有些悲□　观。如果你做得对并且足够勤奋，你就不必难过。

虽然，人类的整体知识体系一直在扩展。然而，在许多◥重要的工程细分领域，基础理论并不先进。在计算的许多重要领域，工程师都有能力在有限的时间内掌握核心关键点。

例如，密码学被认为是一门非常高级的学科，但是一大类密码技术是基于数论中一个非常简◣单的理论——素数分解：给定★两个素数，很容易计算它们的乘积，但是，给定两个素数的乘积，分解的计算量惊▂人。

“一致性”可以说是计算机领域最经典的问题。它是所有分布式系统的基础，从多核多CPU到多线程，从跨机到跨机房，无处不在，几乎所有的计算机从业者都在研究这个问题，但Paxos有一个优雅的解决方案。

权限管理是很多工程师的噩梦，但如果你能处理好“基于（ABAC）”和“基于角色（RBAC）”，你可◣以达到相当高的高度。

另外，技术学习是一场竞技游戏，虽然学习无止境，但超越大多数对】手是一种胜利。因此，通过正确的学习方法，长期投资将形¤成核心竞争力。

没有绝对精湛的技术，只有真正的大∩师

致力于技术成就的工程师都梦想有朝一日成为技术大师。但对于技术大师的标准却存在不少争议。这是一个由来已久的误解：掌握某项技术是评判技术高手的标准。我经常遇到这样的情况：有的工『程师因为掌握了某种技术，就自称是专≡家，比如Kafka等。有的工程师仰望另一个团队，因为那个团队使用了某种技术。

造成这种误解◥有几个原因：首先，技能越多，技能越好。掌握很多技巧的人，自然不是菜鸟。其次，在互联网时⌒　代到来之前，获取信息的成本非常高。这导致掌握一种技能，可以为个人甚至整个公司带来优势。互联网时代，各种框架的出现和开源的△普及迅速淘汰或降低了很多技能的价值，同时也降低了很多技术的学习门槛。因此，目前♀掌握一定的技能知识只能是短期目标。对某些技能自满的人需要记住：骄傲是让你退缩的▓原因。

所谓麻雀虽小，五脏俱全。如果你是创造者，那么设计麻雀和设计大象在复杂性上没有显◣着差异。一个看似很小的业务需求，要想做到极致，所需要的技术和能力都非常全面和先进。真正的主人不是用掌握的技术去满足客户的需求，而是倾听客户的需求，给出更好的解决▼方案。满足客户需求是●一场竞技场比赛，真正的高手会出招。

不做项目就不能成长吗？

在项︻目中学习是最快的成长方式之一，许多工程师都非常喜欢这个过程。但是全年都在做项目，你可能在一家外包公司。对于一家产品公司来说，如果是从年初到年末都在做项目，或者处于创业初期，或者做过很〗多失败的项目，都不＠是特别理想的状态。通常，项目之间会有一些非项目时间。在此期间，有些学生会出现迷茫，成长非常缓∮慢。

更多的项目㊣真的更好吗？答案显然是否定的。重复的项目不会给工程师带来新的增长。不断地做项目，没有时间学习新√知识，会导致“不学则做”。真正让工程师出类拔萃的是项目的深度，而不是不间断的♀项目。因此，在项目之间的间隙，工程师应该珍惜难得的喘息之机，深入思考，把项目做的更深更好。

如何增加项目的深度？一般来说，任何ξ　项目都有一个目标，当项目◥完成后，目标就基本实现了。但客户真的满意吗？系统的可用性、可靠性、可扩展性和可维护性是否●做到了极致？这些问题的答案始终是否定的。因此，对于任何有价值的项目，你总是可以深挖。深入项目，深入思考，也能锻炼工程师的创造力。一个希望继续做项目的人，比如一个致力于培训更多千里马的人，是无法发明汽♀车的ぷ。发挥创造力不是一朝一夕♀就能完成的事情。需要很长时间才能思考。总之，工程师应该始终觉得时间是不够的，毕竟时间╳是最宝贵的资源。

责╳任真的很小吗？

很多时候，工程师负责的系统数量和团队规模与其“江湖地位”正相关。然而，江湖的地位与技术的成长并不必然相关。提高技术能力的关键是项目的深度和客户的ξ洞察力水平。项目越多，花在单个项目上的时间就越少，很容易陷入肤浅。尤其需要避免的是“在位不当权”的情况。团队越大it工程师，管理它所花费的精力就越多。在管理技能不成熟、技术眼光不够高的︼前提下，强行执掌一个大∩团队，可能会导致个人不堪重负，团队失败。最后“一将无能，三军精疲力尽”，效果可能适得其反。

从技术发展的角度，技术管理者要关注自己能控制的活跃项目的数量，致力于提升活跃项目的影响力和技术深度。团队的规模要与个人的管理能力、计划能力和需求控制能力相适应。一项工作是由多人完成的，每个人的成长都◤是有限的。每个人都在》做简单的重复工作，对技术的发展没有好处。团队管理和项目管理要循序渐进，切忌“拔苗助长”。

你一定要当老板吗▓？

有些工程师的人生理想★是成为团队中的技术负责人，这当然是一个值得称赞的理想。但是，如果整个团队的技术能力一般，发Ψ展潜力一般，而你是技术最强的，这与其说是幸运，不如说是悲哀。这种场景叫做“武大郎开店”。团队中顶尖的技术专家做这件事并非不可能，但▃要想不断成长，必须满◣足以下条件：

否则，加入更强的技术团队可能是更好的选择，至少不是什么值得骄傲的事情。

平台化的传奇

平台化是“高大上”的代名词，很多工程师为↘了参与“平台化”而绞尽脑汁。但是，与其他业务需求相比，平台需求并没有根本的不同。无论是平台需求还是普通业务需求，其价值都来自于客户价值。区别如下：

说到底，平台化是一个普遍的需求。在实施︻平台化之前，必须避免以下两个误╱区：

所以平台化的最佳实践是投入最少的资源，解决最多的问题。平台解『决一切，客户∑享受成功。

从事基础技术一定要厉害吗？

我经常听到学生对基础「技术系的学生表示钦佩，但对从事商业技术的学生表示鄙视。相信存储、消息队列、服务治理框架（如美团点评内部使用的OCTO）等都可以称为真正的技术。事实并非如此，更基础的不一定更深△刻。

比如下面这段流传已久的一段话：语言越高级，技术含量越少。但真的←是这样吗？以Java和C为例，这是两种完全不同的语言，需要完全不同的技能。 C可能更接近操作系统，有更多机会处理CPU和内存。但是为了用好Java，程序员必须非常精通面向对象、设计模式和『框架技术。 Java工程师转C确实不●容易，但是笔者也看到很多C转Java的工程师不满意。

基础技术和业务应用技术难免有不同的↑关注点，没有高低之分●。造成这种误解的原因有两个：

相比之下，业务技术和基础技术各有优缺点。但真正的高手专注于解决问题，所有技ζ术都是技能。

可行性研究的那些坑

在工作中〓进行可行性研究时有发生。在进行可行性研究时，应避免以下几种情况：

可行性研究的结论应该是收益和成本之间的折衷。 p>在实践中，由沟通引起的问题层出ㄨ不穷。许多工︽程师比较内向，总是被贴上“沟通不畅”的标签。事实上，沟通能力是工程师最重要的能力之一。良好的沟通是高效工作和学习∞的基础，也可以通过学习来掌握。下面我来说说工程师语言的交流体验。

第一个常见问题是通信的可靠性。从可靠性的角度，通信分为TCP模式和UDP模式。 TCP模式的形象是：我知道你知道。 UDP模式的形象表达是：希望◥你知道。当然，TCP方式更可靠，但成本相对较高。 UDP模式成本低，但不可靠。通信可靠性有两☆个常见错误：

第二种沟通问ξ　题是及时性。在时效性上，通信分为：同步方式和异步方式。同步通信就像：你现在听我』说。异步通信的形象表▲达是：记得替我做。沟通及时性有两个常见▲错误：

有效沟通的一个重要原则是提前沟通。通信的本质是信息的交换和处理，被通信的对象可以比作一个CPU，进行◥串行信息处理。提前通信意味着尽快将处理请◣求放入处理队列。下面这个例子让很多工程师感到厌恶：一个需※求计划1个月，产品设计2周。开发工程师第一次听说这个需求时，发现开发时间是2天。工程师争辩说他会加班一周来完成它。最后得出的结论是，工程师们效率很低，不合作。就像工程师讨厌类似的要求一样。协调一个↑大项目，希望得到别人的≡合作，也是要尽快沟通。

有效沟通的另一个关键是“不要跑题”。许多看起来非常接近的问题本质上是完√全不同的问题。例如：一个会议的主题↘是“如何执行一个程序”，但有人可能会问“该程序是否应该执行”。 “如何实施”和“应不应该实施”是两个完全不同的问题，很多看似相关的问题其实都离题很远。 “跑题”是导致沟通不〒畅的重要原因。

良好沟通的秘诀在于能够把握TCP模式和UDP模式的本质，正确判断问题的紧◤迫性，尽可能提前沟》通，避免跑题。

带领人№的方式

一些初任导师的工程师担心毕业生的能力太弱。 同样的㊣　事情也发生在许多只管理小团队的工程师身上。他们的最终结果：写完所有的代码，让下属没有代码可写。当然，“动手”是很糟糕的。到最后，往往团队整体业绩不高，团队成员№成长缓慢，你累了。

古人云：“勿用疑人，勿用疑人。”这句卐话不是“一刀切”。在古代，受通信技术的限制，反馈时延显着，信息传输过程中噪声★很大，变形严重。在这种情况下it工程师，如果根据短时间内▃收集到的少量变形信息做出快速决策，很容易草率行事。在公司里，这句话更适合选拔过程，应该改为：不录用，疑不录用。

考虑到招聘成△本，即使是在招聘◆层面，有◆时这也是不可能的。作为一个小团队的管理者，你可以快速准确地获得团队成员的各种反馈信息，绝对没有必要“用人不疑，不为可疑”。真正的用人ξ理论基础来自“探索利用”（和）。不能↑让下属做他能做的事，更不能因为下属失败就不给机会。

根据经典的“探索利用”（和）理论，好的用人方式应〓该是：

效率、效率、效率

经常看到一些同学把自己的表现评为100分——满分，因为过去太难了，但最后的表现却很一般。天道酬勤勤奋，但天道酬勤。工程师都学过数据结构，不同□　算法在时间复杂度上的差异，仅仅靠加班是很难⌒弥补的。为了提高工作和学习的效率，我们需要注意以下几点：

架构ζ　师胜任力模型

我们已经讲了原理和一些困惑，那么工程师应该如何提高自己呢？

成为一名优秀的架构师是大多数初级和中级工程【师的阶段性目标。优秀的架构师往往具备七大核心能力：编程能力、调试能力、编译部Ψ 署能力、性能优化能力、业务架构能力、在线运维能力、项目管理能力、规划能力。

这些能力之间的关系大『致如下。编程能力、调试能力、编译部署能力属于最基◤本的能力。不掌握这三个能力，就很难实现性能优化能力和业务架构能力。只有具备一定∴的性能优化能力和业务架构能力，才能在在线运维能力和项目管理能力上表现出色。团队管理能力是最高能力，更依赖于项目管理能力。

编程能力

对于工程师】来说，编程是最基本〓的能力，也是必不⊙可少的技能。其本质是一种翻译能力，将业务需求翻译成机器可以理解的语言。

有很多书籍可以提高您的编程技能▓。精通面??向对象和设计模式是高效编程的基础。初级工程师应该编写更多︽代码并阅读更多代码。找高手做Code，也是提高编程水平的捷径。

调试能力

程序代码是系统的静态形式。调试卐的目的是通过查看程序的运行状态来验证和优化系统∞。本质上，工程师可以通过不断的调试∞，不断加强对静态代码运行状态的预测能力。因此，调试能力也是工程师提高编程能力的关键手段。很久以前有一个传说：“调试能〓力有多强，编程能①力就有多强。”不过现在很多编辑器功能非常强大，调试能力的门槛已经大大降低了。

调试能力是项目能否按时※高质量提交的关键。即使是稍微复杂的项目，大多数工程师也无法在第一时间就完成。大型项目通过不断的调试得到优化和修正。所以调试能力是必不可少的能力。

编写更多的程序、解决bug、咨询更多的专家是提高调试能力的重要手段。

编译和←部署能力

在线编译和部署运行程序是系统启♀动的最后一个环节。随着SOA架构的普及和业务复杂度的增加，大部分系统只是一个▅完整业务的一部分。因此，本地编译运行并不能完全模拟系统的在线运行。为了快速验证编写的程序的正确性，在线编译和部署成为必要的环节。因此，编译和部署的能力是⊙必备技能。

保持许多相互交织的子系统正常运行可能是一Ψ项挑战。得益于SOA架构的普及和大量编译○部署工具的开发，大大降低了编译部署的门槛。基于应用层开发的公司，“编译器工程师”很少。但是对于初级工程师来说，编译和部署仍然不是一件容易的∴事╲。

性能优化功能

衡量系统成功与否的一个重要指标是使用情况。随着使用量①的增加和业务复杂性的增加，大多数系统最终都会遇到性能问题。性能优化能力是一种综合能力。因为：

可以说，性能优化能力是工程师的各种技能开始融入成长过程的标志。这方面可以参考之前的博文《常用性能优化策略总结》。市面上有很多与性能优〒化相关的书籍，可以参考。通过阅读更多关于开〖源框架中性能优化的文档和代码，这也是一个很好的改进方法。手工解ω　决在线性能问题，也是提升性能优化能力的关键。如果有机会，向专家学习，分析性能优化方案案例，也是快速提升性能优化能力的一种手段。

在线运维能力

如果说性能优化能力体现的是架构师的静态思维能力，那么在线运维能力考验的是动态响应能力。残酷的现实是，无论程序多卐么完美，错误总是存在的。同时，由于职位更高、责任更大，许多架构师负责非常重要的在线系统。对于线上故障○，如果不能及时预防和解决，损失可能难以想象。因此，在线运维能力是优秀架构师必备的技能。

为了快速处理线上故障，标准化的监控、上报、升级、基本的响应机制当然是非常重要的。通过观察◆到的现象快速定位、缓解和☆解决相关症状也很关键。这就需要架构师对故障系统的业务和技术有一个全面的了解。修复线路故障的︾建筑师就像 F1 比赛中的车手。赛车手必须了解自己、赛车、对手、同伴、天气、场地等，快速做出决定，不断调整。架构师必须了解所有技术细节、业务细节、处理规范、合作伙伴等诸多因素，快速决策并快速调整。

在线运维本质上是一个强化学习的过程。很多能力可以通过看ω书、查资料来完成，但是线上运维能力往往需要大量的实践才能提升。

业务架构能力

工程师抱∏怨产品经理的情况并不少见，抱怨最多的主要原因来自于需求的频繁变化。 There are two main of : the first is or , and the is . For the first , both and have no but to it. A good have the to the of by the .

There are two for the of -:

The first is that the are and . From the of , any is a of and . A needs to go at least three and from the to the and to the . Every time is , there is some loss and some noise, which leads to the fact that the do not meet the at all. In , the side and have weak in , , and cost , which will also lead to .

The is that the side has not about its own needs at all.

A good have the to real and fake . It take time to the real of , have , and the real needs of . The real of the is the . After the real needs of the , a smart have the to judge the 's for , , , etc., and be cost-. , of the and , the of is also the key to a . As the level , the faced by will more and more . To and is the only way for to .

There are some books on the on how to an that you can refer to. , to the , may be a more way. focus on pain than PRD , and focus on real . the and of is also a must for .

As a of the age, of labor and are into the genes of . also need to be for major in order to make a name for . To a as an , is of a must-have skill. In , of and cost is also very .

also means a big heart. Major many such as , , and . In the face of , it is to have a to to the of goals.

that need in : and good use of them, , , and to the truth.

Cost means of , and the need to be :

There are many books on . , is . in big and the way are is also a very means of .

Team

An who doesn't want to be a CTO is not a good . Going to be a plan for . A core of team is , which and . Good needs to the :

There are many books on on the that are worth . is a book, it is the basis of , so you may wish to read it more. from self-, more about other 's plans is also an means to .

总结

I was to share about " while ", the took a while to think about and the , and then kept every day And try to solve the , and then draw the model of based on , and the text.

The the , , and clear goals, to help in their work and study. It be that the of the is full of , and the so- model is also the 's . You are to share your in and in the .