当前位置：首页> 在做程序员的道路上，你掌握了什么概念或技术使你感觉自我提升突飞猛进？> 正文

在做程序员的道路上，你掌握了什么概念或技术使你感觉自我提升突飞猛进？

华为云开发者联盟
2024-02-03
112
共13人回复

「华为云开发者联盟」发表看法

2024-02-10

如题主所言，天赋异禀的大佬毕竟是少数人。对于我们大多数普通人来说，想要实现“逆袭”都不是一蹴而就的，需要不断提升、不断积淀，最终达到厚积薄发的效果，薪资只是能力的结果体现。在此跟大家分享一个普通程序员提升自己的过程，2024，一起学习，一起突飞猛进。

一、分阶段，根据不同需求按需提升

对于多数程序员来说，40岁之前赚到别人60岁的钱是普遍目标，不过职业的进阶也印证着人生的进阶，所以何时开始思考未来的职业规划，都不算早。

我们基于华为云各个产品线技术专家多年工作经验和心得体会，再经过层层筛选整理，推出了这份程序员进阶必读书单。

无论你是1年小白、5年资深还是10年技术专家，或者更高阶的CTO，都可以在书单中找到适合自己目前阶段的书，清晰化未来要走的方向，让你的路越走越宽，财富累积/技能累积/经验累积也会愈发顺利。

程序员的第一阶段：初级程序员（0-3年）

初级程序员工作经验在3年以下，处于打基础、定方向的阶段，这时候建议主要精力用于夯实基础，规范编程上，将会终身受益。

了解自己所在的领域，对吃饭的工具有清晰的认知代码是一个程序员的灵魂，每个优秀的程序员都应该认真对待亲手写出的代码从实际问题出发，让自己的编程语言和思维更上一层楼多学点算法和数据结构，提高编程水平初级程序员必备的软技能，学习做好职业规划、自我营销

程序员的第二阶段：中高级程序员（3-5年）

“代码有很多种坏味道，重复是最坏的一种”，先让你的代码更优雅总有不合理的软件项目存在，如何避免犯一些经典错误技术能力之外，提高工作效率很重要程序员职业生涯到了一定阶段，系统地思考职业发展培养专业的软件开发素养，具备良好的编程实践

程序员的第三阶段：全栈工程师/软件设计师（5-10年）

全栈工程师必备技能之协调客户、管理好项目全栈工程师培养可用性思维软件设计模式领域的里程碑著作转变一下程序员的思维，认识交互设计的重要性面对漫长的职业生涯，静下心来追求“良质”

程序员的第四阶段：架构师、CTO（10年以上）

为解决架构设计模式中的“疑难杂症”打开思路跟着国外技术大佬学团队管理带领团队完成敏捷转型从技术人员转型为领导者，系统提高技术领导力架构师也好，CTO也罢，管理团队有时候比技术能力更重要

这本书常年排在程序员必读书单TOP5内，作者用丰富的想象将看似繁杂的计算机工作原理阐述得通俗易懂。

二、代码是一个程序员的灵魂，每个优秀的程序员都应该认真对待亲手写出的代码

《代码整洁之道》豆瓣评分：8.6分

作者Jon Bentley可以说是计算机科学大家培养专业户，Java之父James Gosling就是他的学生。

他选取了典型的复杂编程和算法问题，生动描绘大师们在探索解决方案中发生的轶事、走过的弯路和不断精益求精的历程，总结了许多独特而精妙的设计原则、思考和解决问题的方法以及实用程序设计技巧。比如和Bob Martin讨论密西西比河一天流出多少水，用这样一个小问题引出粗略估算的技巧。

四、多学点算法和数据结构，提高编程水平

《数据结构和算法分析（套书）》豆瓣均分：8.7分

重构，就是在不改变外部行为的前提下，有条不紊地改善代码。本书凝聚了软件开发社区专家多年实践经验，解释重构的原理和最佳实践方式，并指出何时何地应该开始挖掘你代码以求改善。

整本书第三章“代码坏味”，写的很有用。什么是代码的坏味道，如何消除这些坏味道，这是一本关于代码美学的一本书，培养码农那高贵的code taste的不二选择。

二、总有不合理的软件项目存在，如何避免犯一些经典错误

《快速软件开发》豆瓣评分：8.4分

总结高效程序员在开发过程中的45个个人习惯、思想观念和方法，有助于开发人员在开发进程、编码工作、开发者态度、项目和团队管理，以及持续学习等方面积极修炼。

养成这些好的习惯，可以极大地提升自己的编程实力，更快速、更可靠地交付更高质量的软件，从而成为真正的高效程序员。

四、程序员职业生涯到了一定阶段，系统地思考职业发展

《软技能2：软件开发者职业生涯指南》豆瓣评分：9.0分

了解软件开发从业者需要具备的各种“软技能”，包括如何选择工作岗位、如何选择技术方向、如何拓展技术技能、如何与团队和领导融洽相处等等。

五、培养专业的软件开发素养，具备良好的编程实践

《程序员修炼之道：通向务实的最高境界（第2版）》豆瓣评分：9.2分

一本非典型的适合程序员阅读的哲学书，霍金、乔布斯都曾推荐过。书中讲述作者和儿子骑摩托车旅游路途所悟到的“禅”，其中最关键的就是“良质”。

举个例子，写程序跟维修摩托车一样，有时候会枯燥、机械且乏味，但如果用“良质”的境界用心去对待这件事，找到内心的平衡，最好能达到“物我两忘”的境界，最终的结果就是另一番局面了。

程序员的第四阶段：架构师、CTO（10年以上）

恭喜你，已经进阶到程序员的金字塔顶端了！入行有10多年经验的你，有过项目开发经历，精通多门编程语言且熟悉数据库，对行业、技术、产品都有了深层次的认识，带好团队成为更关键的业务能力。

一、为解决架构设计模式中的“疑难杂症”打开思路

《企业应用架构模式》豆瓣评分：8.3分

程序员办公室政治指南，谷歌技术大佬以自身的经历为基础，阐明了团队合作的重要性，提出了加强合作的具体方法，并辅以实例进行了深入分析。全文主要从三个角度介绍了团队合作的方法：如何处理团队中有关人的方面；如何在良好或不佳的公司中工作；如何与用户合作创造更出众的产品。

三、带领团队完成敏捷转型

《敏捷转型：打造VUCA时代的高效能组织》豆瓣评分：9.2分

为了帮助更多期待转型或者处于转型过程中的企业走出误区、突破阻碍，本书重点阐述了敏捷转型的步骤、方法和策略，用大量真实的案例，生动还原敏捷转型容易走入的误区，以及企业在转型过程中常见的疑惑。

四、从技术人员转型为领导者，系统提高技术领导力

《成为技术领导者》豆瓣评分：8.3分

从管理人力资源、创建健康的办公环境、雇用并留用正确的人、高效团队形成、改造企业文化和快乐工作等多个角度，阐释了如何思考和管理软件开发的最大问题——人（而不是技术），以得到高效的项目和团队。

本书的一个基本出发点就是，管理者不应该把员工看作冷冰冰的机器或可随时替换的零件，而应尊重他们的生物、社会属性，当成有血有肉的“人件”来管理。

结语：

以上列举的20本书，虽然不能做到面面俱到，但可以从“术”的层面，为想要摆脱焦虑、走上技术进阶之路的程序员指点迷津，钻研出职业进阶的“道”。

欢迎大家收藏本书单，阅读计划安排起来！

点击关注，第一时间了解华为云新鲜技术~

「阿斌预测」发表看法

2024-02-05

我是一个甲方的ERP程序员。公司刚引进ERP系统的时候，大家觉得神一样的存在，太复杂了。

上线以后，各种问题层出不穷，项目已经验收，乙方只要一听我们提问题，就两招：1）这个问题不在需求范围内，要解决需要付费；2）这个问题不在这个版本解决，下个版本可以解决。

明明是一个小问题，为什么就解决不了呢？最核心的原因：没有源代码，不知道从哪里下手。ERP说到底，就是数据库的增删改查，直到我明白这两点，ERP的“九字真言”，终于跨过了最前面的三个字。（所谓ERP九字真言，是：先僵化，后固化，再优化）。

我明白的这两点是：

1）真正懂ERP逻辑的人，其实在企业内部，不是搞计算机的，而是那帮业务骨干。ERP内置了最通用，最核心的业务逻辑，这些业务逻辑表现在操作流程和功能界面上，只有业务骨干，才会真正理解这么设计的必要性。

2）编程人员只要和业务骨干结合起来，虽然没有源代码，但有办法看到那些增删改查代码是如何操作数据库的，这就是SQL Profiler 跟踪器。

一旦这二者结合起来，ERP的维护就会变得非常简单了。毕竟，一个在市面上混了几十年的ERP产品，稳定性和继承性是非常好的。然后，各种个性化报表的开发就很简单了。

随着越用越熟，业务+编程这个团队会非常透彻的理解ERP产品，终于有一天。乙方要求增加维护费，我们想了想，不用了，我们自己维护吧。接着，我们把ERP的生产功能剥离出来，自己定制开发了，慢慢的改进，越来越有模样。这就到了九字真言最后一个阶段：优化。

当然，这个过程所以能实现，也要感谢大厂ERP产品的开发平台支持性和自身的发展逻辑。大厂ERP（包括国外的SAP）,都是从财务模块开始的，然后供应链，然后生产制造，然后商业智能。这就决定了每个模块是松耦合的，演化过程中搞了各种接口方式，从硬写数据库，到采用xml交换数据，再到COM组件接口，API，乃至于提出整体开发平台，用开发平台重写业务单据。这些资料，基本上在网上都能找到，如果参加大厂组织的几次开发培训，更容易上手了。

「散居猎人」发表看法

2024-02-07

数据结构和离散数学。

没学这两门课之前，以为编程序就是一句一句堆一句一句试，达到目的就完了呗。

学了这两门课之后，写程序之前先琢磨怎么描述原问题，有了模型和算法的概念，可以更快更准确地写程序了。

再后来有了自动控制和软件工程知识，逐渐建立起了业务逻辑和模块化流程化思想，可以系统地解决较大工程问题了。

面向对象方法和可视化技术，编程成为乐趣，爱好变成事业。

三次编程技术飞跃，再加上熟悉业务流程和抽象业务模型，编程就是自然而然的事情了。

「胖子随感」发表看法

2024-02-11

最开始的时候是基础的编程的算法，后来发现是一个工作的流程，最后发现是解决问题的方法。无论程序员在什么行业，最终最值钱的还是能够替企业解决问题，只有有本事把问题解决的人才是创造最大价值的人才。所以对于初级程序员或者刚入门的人来说，不要怕错，要多干事儿，因为但凡干事就可能出错，但是你不干事的话，你的本事永远不会长进????，每个大拿都是从小兵成长起来的。

「大智视野」发表看法

2024-02-05

在我的程序员生涯中，我认为有几个概念或技术使我感觉自我提升突飞猛进：

数据结构和算法：学习并掌握一些常见的数据结构（如链表、树、堆等）和算法（如排序、搜索、图论等），可以帮助我们解决许多实际问题，提高程序的效率和性能。设计模式：学习并掌握一些常见的设计模式（如单例、工厂、观察者等），可以帮助我们解决软件设计中常见的问题，提高代码的可重用性和可扩展性。版本控制系统：学习并掌握版本控制系统（如 Git）的使用，可以帮助我们在开发过程中管理代码、保存历史版本、合并代码分支等，大大提高开发效率。开发工具和流程：学习并掌握一些常用的开发工具（如编辑器、调试器、测试工具等）和流程（如代码规范、自动化测试、持续集成等），可以帮助我们提高开发效率和质量。新技术和领域：不断学习新技术和领域，可以帮助我们保持学习动力，提高对新事物的适应能力，并为自己的职业生涯开辟新的发展方向。例如，在我的程序员生涯中，我接触了许多新的编程语言、框架、工具，这些都给我带来了新的挑战和机会。

总的来说，作为一名程序员，我认为最重要的是不断学习和提升自己，不断掌握新的概念和技术，并努力将这些知识应用到实际的开发中，才能使自己在这条道路上取得更大的进步。

「一粒厘米」发表看法

2024-02-13

从事芯片固件开发将近三年的时间，编程主用C/C++语言，偶尔做应用层开发

从最开始的一无所知，到现在上手开发，中间过程说容易不算容易，但也并非难如上青天。

特注：楼主是一个感性的偏文艺的男生，当年也是投稿的小编一枚哦

单论编程，个人有以下几个原则性的认知和改变：

1) 一定要学会模块化的编程，代码一定要遵循高内聚，低耦合的原则

这个理论我至今奉若经典，对于编程小白来说，刚开始能有这样的信念，能让你的编程之路顺利很多。

毕竟这是多少前人的经验总结

2）好的代码不一定极度简洁，好的代码更不是一味炫技

我想大多数程序员刚开始时，一定特别崇尚各种奇淫巧技，笔者当年也不例外。C指针不知道劝退了多少程序猿，但是C的灵魂就是指针，一个简单的指针能被编程者玩出各种花样。

好的代码应该是自己能看懂，也让别人能看懂。

这里推荐一本书日本前桥和弥写的《征服C指针》，对指针的讲解简单透彻，值得一看

3）做一个有原则的程序员，对自己的代码负责。低级错误千万别犯哦

「象骑士」发表看法

2024-02-09

看十遍不如做一遍

新手时比较纠结，很多问题都完全靠想，不懂得去尝试写代码或者抄代码运行验证一下，看过很多开源代码，却只是停留在阅读的层面，不会去修改里面的代码，尝试自己增加功能，这种被动式的吸收知识是效率特别低的方法，要尽量化被动为主动，多主动实践。

编程时一门技能，只有在实践动手的过程中才能学到东西。如果一个功能需求，你有点思路，但不太确定这样可行不，尝试自己去撸一遍，写的过程中你会发现一些问题，再调整修改，这样的效率往往比较高。阅读源代码的时候，不要完全靠看，想办法把系统运行起来，增加日志，通过调试工具来进行观察，只要这样，才能真正理解整个系统。

CRM大法特别好用

Copy Run Modify打法在程序员学习进阶过程中非常重要。找一些比自己能力范围稍微高一点点的开源项目或源代码，先复制，然后将系统运行起来，把代码读懂后，再根据自己的需要跟想法去进行修改增加，这样的学习跟工作效率比较高效。学习书本或教程上的代码时，也可以通过类似的方法，先将例子代码复制后运行起来，多在一些关键地方尝试进行改动，逐步增加自己的想法，这样的方式是在倒逼自己尽快把例子代码理解好，当自己能够熟练改动并完成自己的需求时，就说明自己能够比较好地理解例子代码。

CRM大法不论是在学习还是干活都很好用，新人可以多尝试一下。

用好搜索引擎

在程序员生涯过程中，我们会遇到各种各样的技术难题，不管我们是新手还是老手，都会遇到各种各样的问题。很多技术问题不会只有你一个人碰到，网络上会有很多答案跟资源，一定好学会好好利用网络上的资源，比如牛逼程序员的blog、github、官方文档、stackoverflow社区、优质社群等。学会高效利用搜索引擎非常重要，很多东西跟资源只要你学习下搜索技巧再加上耐心，会发现很多宝藏资源。google、百度都有一些稍微高级一点的搜索技巧，作为程序员，如果不好好学习利用一下这些技巧，实在是说不过去。

在当程序员的道路上，明白这三个道理花了不少时间，后来这三个道理让我受益很多，希望有缘人能看到。希望进一步交流的可通过评论和私信交流。

「gaohongfei159538015 」发表看法

2024-02-04

第1个就是逻辑覆盖。就是if嵌套。所谓的业务逻辑，就是if分支，精通if也就完成程序主体的业务逻辑表达了。

第2个就是实体表达，不过是字符串的层层封装，所有的对象都是数据封装，布尔类型数值型及复合型如object、map型本质也是字符型，都是K、 V对，都要给实体字符串名称。

第3个就是玩转递归，很多看似不可能完成的程序任务，都是通过递归设计完成的，递归的优化就是动态规划算法，可以避免冗余计算，了解这些程序算法也就基本到头了。

第4个就是实体映射ER关系，万物互联的关系不过是主外键映射的关系，SQL用一致的表达把不同的主键汇聚会在一起形成中间表，程序语言里使用关联封装好的大实体对象映射分散的小实体对象，抽象也是一样的，类和类之间也是通过主外键映射，有了这些概念，也就会把现实世界中该抽像的抽象，该映射的映射，该分类的分类，该关联的关联，该分层的分层，这样也就有了模块化的思维和模式设计思维。

第5个是程序的高内聚低耦合，就不展开说了。

「飞翔的城」发表看法

2024-02-04

应该是面向对象的思维。

最早接触时为多态、继承这些技术巧思而惊叹。

后面在应用中越来越喜欢这种思维对问题、实现的分解能力。

再后来由面向对象进一步走向面向组件又帮我解决了工程化最大的问题：可靠重用和开发组织。

我现在有一个有效迭代的组件体系，任何项目需求都能被快速分解为成熟的组件体系组装和少量新开发技术细节。

回头看，现在的解决方案诞生的源头就是当年的面向对象思维。

感谢汤姆.斯旺当年一本面向对象设计的书为我打开了这扇窗。

「IT人张飞洪」发表看法

2024-02-05

抱歉了各位，列书单和介绍的计划可能要鸽了… 一方面由于很多书都找不到了；另外就是很多我当时读的书，现在都有更好的替代技术或讲的更好的书；最后的原因就是懒… 一次把所有东西写出来太累了。

在我目前10年的程序员道路上，让我感到自己质变了的，有大彻大悟的感觉的，是：一本书，和2个概念/技术/领域/...吧。分别对应我所认为的程序员能力对应的三个关键方面。

1书2概念

一本书：Designing Data-Intensive Applications，对应程序员3能力中的工具箱深度广度两个概念-1：多范式编程和最小表达力原则(least expressiveness principle), 对应程序员3能力中的程序语言理解深度和表达抽象能力两个概念-2：领域驱动设计(Domain Driven Design)，对应程序员3能力中的方法论，编程大道(programming in the big)，和构架能力

关于程序员3能力：

1. 工具箱广度深度，或者说在技术选型上控制系统复杂度的能力，广度：懂多少数据库/数据处理框架/AWS几个重要的Service了解多少/著名的开源软件框架工具了解程度。2. 程序语言理解深度和表达抽象能力，这是在实现上控制复杂度的能力，懂不懂得最小表达力原则？懂得几种编程范式？它们之间怎么根据具体情况作出取舍？是否知道怎样才能把code写成诗？怎么样才能在重重困难中，坚守高聚合，低耦合？怎样组织程序，才能使得让程序正向流动产生期待效果之外，程序能否根据效果／结果，倒推并很容易的倒推出这样的一种结果是由什么原因，那个组件造成的(这是系统怎么才能很容易进化的关键，也是“做出来就是好的”程序员最难克服的一点。3. 方法论，编程大道(programming in the big)，和构架能力，这是在时间跨度的整体上控制复杂度的能力，辨别什么是对的，应该做什么的能力；在时间跨度上，在信息不完整的情况下，现在怎么构架，才能使得当将来信息完整了，我们能很轻松的根据将来的正确信息，把系统调整成最好最正确的状态，什么决定应该现在做，什么决定可以和怎么样才能留给将来做，并且在这个过程中，保证能够支持业务正常运转。在整体上，怎么把需求获取/设计/coding/测试/安全/部署/运行监测/报警/性能/系统回馈分析/数据统计/报表…等等在全局把握，安排的妥妥当当相互支持而不是相互抵触，相互使绊子。这里包含的知识包括，到底是waterfall， TDD，BDD，还是type driven，怎么执行Agile，什么是devOps，continuous delivery。到底应该是技术决定业务，还是业务决定技术？。给一个100人的团队和超复杂／抽象的需求（比如需求就是让公司业务翻一倍，怎么翻一倍这个抽象问题要怎么分解成n个大问题，这n个大问题怎么分解成m个中问题。。。。），怎么把抽象问题落到实处，怎么能把大的问题分解成哪怕是比较弱的程序员也可以解决的小问题，然后还要证明这是根据现在的信息，可以做出的最好的决定。2017年，你看了啥很好的计算机的博客/书/视频？这个回答中关于DDD和Clean Architecture的介绍讨论了一些这方面的问题您可以看下。

可以看到，这3个能力有一个相同的关键点，控制复杂度；控制复杂度的能力，是区分程序员能力的关键之一。

书籍类型：

关于一书：Designing Data-Intensive Applications：由于我的主要工作是利用云技术，做后端的大数据模型，或者高性能，高弹性，高可用性的service，所以数据处理，和云技术是我工具箱里最重要的一部分工具。我之前比较深入的（内部怎么工作的深度，每个系统至少读过一本书，有一些看过源代码）学过Oracle, HBase, Cassandra, Redshift, Hadoop, Spark Kafka, Storm, Zookeeper...Amazon自己的DynamoDB, Kinesis, SQS／SNS, AWS Lambda, Step Function, SimpleWorkflow, EMR... 但是我的学习是像没头苍蝇一样的，是盲目的，哪个技术火，就学哪个，总觉得这些东西之间模模糊糊的是有联系的，感觉是有一些东西是可以总结起来的。。。脑子里或者说工具箱里里的东西很多，但是却非常乱，概念实现经常记混，我经常在想：如果能总结归类，用更科学的方法去记住所有我学过的技术，那就好了。。。然后我就遇到了这本书，我读了三遍，然后感觉一切都理顺了… 如果我先读了这本书，才去学上边这些东西，那么我花费的时间将是原来的3分之一到5分之一左右。这本书在广度和一定程度的深度（如果对进一步深度有要求，可以读完此书的reference）上，概括和总结了数据系统，分布式或非分布式环境下面临的本质问题，和解决方案的分类，看完这本，我开始理解了“为什么”这么多的分布式系统要这么设计。而这本书上千的引用论文，给我指明了一条系统学习理论的明路。关于多范式编程和最小表达力原则(least expressiveness principle)：学了好多语言，设计模式，AOP，范型，反射，DCI。。。不知什么时候起，我已经忘记了我为什么要学习他们了，我的程序开始变成一个程序员的行为艺术，简直可谓花式编程。怎么样能用别人都不懂的花式技术秀翻全组，变成了我觉得可以体现我的学识的关键。。。（在这里要跟接手和维护我花式行为艺术的同学深深的道歉。。。）直到我了解到了多范式编程(Multi-Paradigm Programming)和最小表达力原则(least expressiveness principle), 我才中混沌中惊醒，回归初心，简化程序，用尽可能简单的程序来解决尽可能复杂的问题，才是我们发明和学习了这么多技术的最终目的啊！关于领域驱动设计(Domain Driven Design)：从具体的大处来说，它让我明白了“为什么要有程序员”，这个话题很大很抽象，下边的引用有一些详述。从小的来说，它让我懂得了怎么样用系统的方法来设计系统，实现系统，从而让VP，Director，各级开发经理, 产品经理，客户，和我们组配合的机器学习科学家，统计学家，经济学家，他们脑子里的系统，和我们程序员的code的组织，系统的组件设计实现，能够有一个清晰的对应，且这个清晰的对应，如何在无数的需求改变，无数的技术升级中，在长期的时间跨度上，如何能够坚守住，如何持续保证概念模型(concept model)和实现模型(implementation model)的一致，并且是清晰一致。那么，一个小的脑子里的模型改动，必然只会引起一个系统的小的改动。做到这点，是在长远的时间角度，在考虑了未知的未来，考虑了明天的你，团队，客户，都会收到新的未知的信息的情况下(而不是根据一个时间点的需求)保持一个健康，可业务拓展，有竞争力的，能够成为组部门公司之脊梁的系统的关键！用比喻义来说：如果说Designing Data-Intensive Applications是逍遥子百年功力，是莽牯朱蛤，是张无忌吃的昆仑山蟠桃，给你无穷的内力，那么这些方法论则是北冥神功，九阳神功，易筋经，教你如何驾驭这力量，而不是自爆而亡。

为什么传统行业不断被颠覆？为什么人工持续被计算机代替？程序员，拿着大杀器，以更科学更效率的新方法，解决了更多更大更新的问题，这当然需要程序员非常了解你手中这个大杀器；然而首先，你要明白，自己的价值，在于你是一个解决问题的人。

DDD的精神

私信和某位朋友聊了一会儿DDD，自己也想了很多，贴一些在这里：

再多说点DDD吧，请千万不要看网上鱼龙混杂的资料，很多博主自己还没明白就写各种怎么做EventSourcing，怎么做CQRS的文章，说这是DDD构架，DDD就必须得怎么怎么样，这些都反而是违反DDD的精神的，想了解DDD，请千万去读一本关于DDD的书，而我强烈推荐推荐Patterns, Principles, and Practices of Domain-Driven Design 而不是Evans的原版。

一个DDD 实践者经常使用的重要的practise，就是跟PM和客户讨价还价, 学会拒绝和剪裁，合理的push back，也是我面试Sr. SDE时候会考察的软技能之一

因为复杂的技术实现是有代价的，要看换来的业务价值是什么，如果核心逻辑要求一个技术实现，关系到项目的成败，那就要不惜代价的去选择完备的实现方案。而当一个超复杂的技术实现只是为了一个可有可无的业务功能，那就要强势说服客户PM砍掉这个功能。因为支持这个功能造成系统的复杂度，可能会给拓展核心业务造成困难。

这里推荐一下Worse is better这篇文章，论述了为什么简单大于一切。

简单要大于正确性，因为现在的正确未必是未来的正确，砍掉意义不大的正确性，保持核心的简单性，是让核心能够轻装上阵，更好演化的关键。简单大于一致性，这个很多例子了，大家从事务的强一致行转为prefer 最重一致性就是在这点上trade off的最好例子简单大于功能完备性，这个上边我也解释过了。不需要非核心的功能完备性而牺牲核心或者系统的整体简单性。

那么怎么在简单，业务正确性，一致性，完备性里，做合理的trade-off（因为完全不要正确性，一致性和完备性也不行呀）就需要对业务有深入的了解认识。程序员的本质还是解决问题的人，只是恰巧用计算机来解决问题而已，好的程序员是简化问题和解决问题的高手，他能够在业务/技术/人员/文化/复杂度/等等多角度做剪裁，来衡量各种得失，而不是把自己逼死累死在复杂的技术实现上，用灵活的手段来让自己的组和公司获得成功。

跳出技术思维的束缚，从全局来思考问题，我想，这就是DDD的精神吧。

尾

我是一个数学系，全自学转行计算机的程序员(因为真的喜欢这行，直到现在也是很经常看书或论文到夜里1点)，现在在Amazon西雅图的一个负责后端黑魔法，做智能优化决策的部门里担任tech leader，最近正在写一篇我这10年里如何自学的文章，主要会讲：

我看过的书的列表和书评，推荐的阅读顺序(我觉得这个对自学真的太重要了，在没有必要的铺垫知识的情况下，去读很深入的书，效率非常非常低），那些年我踩过的那些坑。。。对于有争议的技术的我的看法，和一些我强烈建议不要去学的（真的浪费了我很多生命），在被淘汰的路上的，而还有很多人在吹的东西。

自学的路是孤独的，走去了弯路是痛苦的，丢失了方向是迷茫的，看不懂书对自己的智商是质疑的，这里边的苦，我很明白。所以希望自己的这条路径可以当作大家的一个参考，提供一点点帮助。

「程序员柳大侠」发表看法

2024-02-12

没有说掌握了某一个技术就能让你感觉突飞猛进的，有的只是你不断的学习学习再学习，慢慢积累到了一个点，或许是哪个不起眼的东西甚至可能跟技术完全无关的东西，就像是压死骆驼的最后一根稻草，突然你想明白了，醍醐灌顶，思路打开了，以往的懵懂的内容一下子，哦...是这么回事啊，你消化了你积累的一些东西，前提在于你学了足够多的东西。

这也是为什么很多前辈说不要走捷径，只有不断努力学习才能成功。什么十万小时定律，说的也是一个事。不积跬步，何以至千里。

还有一个是你需要掌握多方面的技术，比如你开发java，如果你只会java，不懂计算机原理、不懂计算机网络、不懂算法、数学，那你肯定不如懂这些的人学的好、学的块，我也是一名程序员，至少在我身上我是这样的感觉，学的广度是很有可能打开新世界的大门的。

「linux学区」发表看法

2024-02-10

程序员分很多种，有前端，后端，PC端，移动端，还有嵌入式。

前端，PC端和移动端主要是界面的开发，对于界面，能够理解消息机制，MVC设计模式，tcp,udp,http,websocket及音视频相关(rtsp，rtp，rtcp，rtmp，hls，webrtc)协议就已经很厉害了，可以说各种就界面的功能都能够开发出来，这些技术有一定代码的积累，开发的时候就可以搬运一下，会比较轻松。

后端，要掌握tcp协议族，音视频相关协议，线程进程及其通信、同步，负载均衡，分布式高并发，高可用，集群等技术，数据库分库分表技术。这些掌握后，有一定的项目经验，薪资就不会低于3万了。

嵌入式，各种总线(I2C,I2S,SPI,CAN,RS232,485)等等，驱动相关的，应该都要了解吧