先自我介绍一下,小编浙江大学毕业,去过华为、字节跳动等大厂,目前阿里P7
深知大多数程序员,想要提升技能,往往是自己摸索成长,但自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年最新Linux运维全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上运维知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
如果你需要这些资料,可以添加V获取:vip1024b (备注运维)
正文
进一步思考,关于编程仍有许多想法。我整理了其中的八个,并写下了这篇文章。如果这些建议中有任何一点与你产生共鸣,我会感到非常高兴
1. 编写代码简单,但编写优质代码却相当困难
编程曾经是一项极具挑战性的专业技能。在过去,普通人学习编程的最常见方式是通过教科书和书籍。然而,大多数编程教科书非常晦涩难懂,对初学者不友好。因此,许多人在体验到编程的乐趣之前就半途而废了
但如今,学习编程变得越来越容易。学习不再局限于仅仅研读书籍;现在有许多新的学习方式。观看教学视频,参与Codecademy的互动课程,甚至通过在CodeCombat上玩游戏直接学习编程 — 每个人都可以找到适合自己的学习方法
此外,编程语言变得越来越用户友好。经典语言如C和Java不再是大多数初学者的首选。许多更简单、易学的动态类型语言变得流行起来,相关工具如集成开发环境(IDE)也变得日益复杂。这些因素进一步降低了编程的学习门槛
总的来说,编程早已摆脱了神秘的面纱。它已经从只有少数人能掌握的技能转变为任何人都可以学会的普通技艺
然而,学习门槛降低和友好的编程语言并不意味着每个人都能写出良好的代码。如果你已经工作并参与了一些项目,我想问你一个问题:“你每天遇到的这些项目的代码质量如何?好的代码多还是糟糕的代码多?”
我不知道你会如何回答这个问题,但让我先分享一下我的回答
好的代码仍然很少
2013年,我转职到了一家大型互联网公司
在加入这家公司之前,我只在大约十个人的小公司工作过。因此,在各个方面我对新公司都寄予了很高的期望,尤其是对软件质量的期望。当时,我的想法可能是这样的:“这是一个支持拥有数百万用户的产品的‘大’项目。代码质量肯定比以前好了许多!”
直到在新公司工作了一周后,我才意识到我是多么错误。所谓的“大”项目的代码质量远远不符合我的期望。打开IDE,到处都是数百行的函数和神秘的数字常量;开发一个小需求感觉就像攀登珠穆朗玛峰一样艰难
后来,在更多公司工作并接触到更多软件项目后,我总结了这样的经验:无论公司或项目有多么大或令人印象深刻,实际工作中遇到好的代码仍然是不太可能的事情
什么是好代码的要素?
说到这里,什么样的代码被认为是好代码呢?在这方面,Martin Fowler的一句话经常被大家引用:
“任何傻瓜都能写出计算机能理解的代码。优秀的程序员编写人类能理解的代码。”
我认为这可以作为评价好代码的起点:好的代码必须是可读的,易读的,容易理解的。写好代码的第一原则是优先考虑人类读者
除了可读性,还有许多其他方面可以评估代码的质量:
- 合适的编程语言:当前编程语言的推荐写作风格是否被采用?语言特性和语法糖是否得当使用?
- 易于修改:代码设计是否考虑了未来的需求变化?发生更改时,代码是否容易相应修改?
- 合理的API设计:API设计是否合理且易于使用?一个好的API在简单场景中使用方便,在高级场景中根据需要可以扩展
- 避免过度设计:代码是否受到过度设计和过早优化的问题?
- ……
简而言之,好的代码不是程序员在任何水平上都能轻松获得的东西。写好代码需要在许多方面进行反复权衡和慎重设计,最终进行不断的打磨
那么,如果你想迅速掌握编码的技艺,有没有什么捷径呢?
提升编码技能的捷径
在许多层面上,我认为编程和写作非常相似。两者都使用文字和符号来表达思想,只是表达的方式略有不同
说到写作,我想问一个关于作家的问题:“你曾听说过一个作家不读书吗?你曾听说过一个作家说他从不读别人的作品,只读自己的吗?”我猜答案应该是否定的
如果你查找相关信息,你会发现许多专业作家的日常生活都围绕着阅读和写作。在开始写作之前,他们每天花费大量时间阅读各种文本
同样作为“文字工作者”,程序员往往忽略了阅读。然而,如果我们想迅速提高我们的编程技能,阅读是不可或缺的一部分。除了我们在日常工作中遇到的项目之外,我们还应该多读一些经典的软件项目,并从中学习API设计、模块架构和代码编写技巧
不仅是代码和技术文档,定期阅读一些与计算机相关的专业书籍也是推荐的,以保持阅读书籍的习惯。在这方面,我认为Jeff Atwood在15年前写的一篇名为“程Programmers Don’t Read Books – But You Should”的文章今天仍然具有相关性
提高编程技能的捷径在于“阅读 <-> 编码”之间的无尽循环
2. 编程的本质是“创造”
在程序员的日常工作中,许多事情都能带来成就感,甚至使人惊叹“编程是多么美妙”。例如,修复一个难以定位的错误,通过使用新算法提高代码性能等。但在所有这些事情中,没有哪一样能比“用自己的双手创造出某物”的感觉更棒
在编程时,创造新事物的机会随处可见。这不仅仅涉及发布新软件。编写可重用的实用函数或设计清晰的数据模型也可以被视为“创造”
作为程序员,保持对“创造”的热情至关重要,因为它可以帮助我们:
- 更高效地学习:学习新技术的最有效方式是使用它开发一个真实的项目,在创造过程中学习会取得最好的结果
- 偶然遇到一些不同寻常的事情:许多改变世界的开源软件项目最初都是作者纯粹出于兴趣创建的,比如Linus Torvalds和Linux,Guido van Rossum和Python。
尽管“创造”有很多好处,程序员有充足的机会去创造,但很多人常常缺乏“创造者”的意识。就像一个广为流传的故事说的那样:一位哲学家问一个正在砌砖的泥瓦匠,有些人知道他们正在建造一座大教堂,而其他人认为他们只是在铺砖。许多程序员“只看到砖块,而没有看到大教堂”
一旦将自己定位为创造者,对事物的看法将发生翻天覆地的变化。例如,在为API添加错误提示文本时,创造者可以摆脱“只是快速满足需求”的思维陷阱,向前迈出一步,提出更重要的问题:“我想为用户创造什么样的产品体验?什么样的错误消息会帮助我实现那个目标?”
就像任何有用的编程模式一样,“创造者思维”也可以成为你职业生涯中的巨大推动力。因此,现在试着问问自己一个问题 — “我的下一个创作会是什么呢?”
3. 为高效的试错创造环境至关重要
我曾参与开发一个设计精美、功能丰富,每天有大量用户使用的互联网产品
然而,尽管从市场的角度来看,这是一个成功的产品,但其工程质量非常糟糕。如果你打开它的后端项目并把所有目录颠倒过来,你根本找不到任何单元测试代码,更别说其他自动化测试流程了。而且,业务逻辑非常复杂。最终,项目代码之间存在着意想不到的耦合,就像牛背上无数的毛发一样。开发一个新功能很容易破坏旧的功能
因此,每次项目发布时,开发团队和产品团队都必须保持高度警惕,创造一种非常紧张的氛围。整个发布过程也非常惊心动魄,紧急回滚时有发生。在这样的环境中工作,不仅促进了技术的成长,而且无疑地考验了一个人的心理韧性
编程原本是一份有趣的工作,但是为这样的项目编程却消除了任何愉悦感。究竟是什么夺走了编程的乐趣呢?
理想的编程体验 ≈ “刷题”
LeetCode是一个著名的编程学习网站,提供许多涵盖各种难度的编程问题,其中大多数与算法有关。用户可以选择他们感兴趣的问题,直接编写代码(支持几十种编程语言),并在浏览器中执行。如果所有测试用例都通过,就被认为是一个成功的解决方案。
在 LeetCode 上解决问题就像玩游戏一样,充满挑战和乐趣。整个解决问题的过程完美地展示了理想的编程体验:
- 关注点分离:每个问题都是一个独立的实体,让开发人员能够一次完全沉浸在一个问题中
- 快速准确的反馈:开发人员可以通过自动测试快速获得代码调整反馈
- 零成本试错:编写有语法错误或逻辑问题的代码不会产生任何不良后果,从而减轻了心理负担
不过,你可能会认为我在屏幕前胡说八道
"还有什么?解决算法问题、编写小脚本,不都是一样的体验吗?"你可能会继续补充:“你知道我们公司的项目有多复杂吗?它们规模庞大,模块众多。我们每天为数百万人提供服务。我们有多套数据库和三种类型的消息队列。当然,开发工作会很麻烦!”
的确,世界各地的软件开发工作千差万别,不可能所有项目都像在 LeetCode 上解决问题那样轻松愉快。但是,这并不意味着我们不应该努力改善我们的编程环境,哪怕只是一点点
可用于改善编程体验的概念和工具包括
- 模块化思维:正确设计项目中的每个模块,降低耦合度,增强正交性
- 设计原则:在微观层面,应用经典的设计原则和模式,如 "SOLID "原则
- 自动化测试:编写标准化的单元测试,必要时使用 Mock 技术,并通过自动化测试覆盖关键业务路径
- 缩短反馈回路:改用更快的编译工具,优化单元测试性能,尽一切可能缩短从 "修改代码 "到 "获得反馈 "的等待时间
- 微服务架构:必要时,将单体系统拆分成多个具有不同职责的微服务,以分散复杂性
- …
关注编程环境,刻意营造 “代码天堂”,允许高效试错,让工作像解决问题一样轻松愉快。这是经验丰富的程序员能为团队做出的最佳贡献之一
4. 避免陷入代码完美主义的陷阱
对代码质量精益求精是好事,但也要注意不要陷入完美主义的陷阱。因为编程不是艺术创作,它不鼓励人们无限追求完美。作家可以花数年时间打磨一部杰作,但程序员如果过于专注于代码,就会出现问题
世界上没有完美的代码。大多数时候,只要你的代码能满足当前的要求,并为将来的扩展留有余地,就足够了。有几次,我看到应聘者在简历上给自己贴上了 "代码强迫症 "的标签。隔着屏幕,我能感受到他们对代码质量的重视,但在我内心深处,我希望他们把完美主义的陷阱远远抛在脑后
5. 技术固然重要,但 "人 "可能更重要
在软件开发领域,“单一责任原则”(Single Responsibility Principle,简称 SRP)是一个非常著名的设计原则。它的定义很简单,可以用一句话概括:“每个软件模块应该只有一个改变的理由”
要掌握 SRP 原则,关键是要了解 "修改的原因 "是什么。程序没有生命,无法主动改变自己。修改程序的任何原因都来自与程序相关的人,而人是修改程序的罪魁祸首
举个简单的例子。以下两类程序中,哪一类违反了 SRP 原则?
- 字典数据类,支持两种类型的操作:存储数据和检索数据;
- 一个雇员档案类,支持两类操作:更新个人信息和渲染用户档案卡图像。
在大多数人看来,第一个例子没有问题,但第二个例子却违反了 SRP 原则。要得出这个结论,似乎不需要严格的分析或证明,只需运用一点直觉即可。然而,如果我们认真分析一下,就不难发现修改第二个例子有两个不同的可疑理由:
- 经理认为数据中的 "个人电话号码 "字段不应包含非法数字,因此需要添加简单的验证逻辑
- 员工认为个人名片图片上的 "姓名 "部分太小,希望增加字体大小
“要求更改的是人。你不想把许多不同的人出于不同的原因而关心的代码混在一起,从而使这些人或你自己感到困惑”。- 单一责任原则
理解 SRP 原则的关键在于首先了解人以及他们在软件开发中扮演的角色
这里还有一个例子。微服务架构是近年来的热门话题。然而,很多人在讨论时往往只关注技术本身,却忽略了微服务架构与人之间的关系
区分微服务架构风格的关键在于,将单体系统拆分成独立的微服务后,不同模块之间的界限会变得更加清晰。与数百人的团队维护单体系统相比,许多维护独立微服务的小型组织具有更高的运营效率
如果缺乏特定的组织规模(即 “人”)作为前提,谈论微服务的各种技术优势和那些花哨的技术就会完全错位
技术当然重要。作为专业技术人员,那些华丽的架构图和巧妙的代码细节自然会吸引我们的注意力。但是,请不要忽视软件开发中的另一个重要因素–“人”。必要时,改变一下视角(从 "技术 "到 “人”),这将使你受益匪浅
6. 渴求知识是好事,但也要注意方法
现在大家都在讲 “终身学习”,而程序员是一个特别需要终身学习的职业。因为计算机技术的迭代和更新是非常快的,三年前流行的框架或编程语言,很可能一个月前就已经过时了
要想在工作中表现出色,程序员需要学习的东西很多,涉及方方面面。以我比较熟悉的后端领域为例,一名合格的后端工程师至少需要掌握以下内容:
一种或多种后端编程语言/关系数据库(如 MySQL)/常用存储组件(如 Redis)/设计模式/用户体验/软件工程/编译器原理/操作系统/网络基础知识/分布式系统/…
虽然要学的东西很多,但据我观察,大多数程序员都喜欢学习(或至少不排斥学习),因此心态不是问题。不过,有时仅有 "求知若渴 "的心态是不够的。学习时尤其要注意 “性价比”
注重学习的成本效益
下图展示了学习效果与投入之间的关系
最后的话
最近很多小伙伴找我要Linux学习资料,于是我翻箱倒柜,整理了一些优质资源,涵盖视频、电子书、PPT等共享给大家!
资料预览
给大家整理的视频资料:
给大家整理的电子书资料:
如果本文对你有帮助,欢迎点赞、收藏、转发给朋友,让我有持续创作的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注运维)
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
]
如果本文对你有帮助,欢迎点赞、收藏、转发给朋友,让我有持续创作的动力!
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
需要这份系统化的资料的朋友,可以添加V获取:vip1024b (备注运维)
[外链图片转存中…(img-EH1WrwYa-1713226868190)]
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!