type
status
date
slug
summary
tags
category
icon
password
1.1 开班发言——程序员的四种境界
首先开篇就是一句：
授人以鱼不如授人以渔。
这点我非常赞同，计算机更是如此，技术迭代更新那么快，我们要抓的是技术本质，是思想！
今天有springboot，明天就可以有summerboot
今天有Java，明天就能有Gama
对于不变的东西，学透学明白来，学会举一反三，这比什么都重要（本书前半部分讲的编程范式就是这样的东西）
接着谈到了“程序员的四个境界”：
本班的宗旨是：学会不如会学，会学不如会用，会用不如被用。对于一个软件开发者来说，这意味着四个阶段： 1.学会（知其所然）——掌握一些具体编程知识的初级程序员 2.会学（知所以然）——能快速而深刻地理解技术并举一反三的程序员 3.会用（人为我用）——能将所学灵活运用到实际编程设计之中的高级程序员 4.被用（我为人用）——能设计出广为人用的应用程序（application）、库（library）、工具包（toolkit）、框架（framework）等的系统分析师和架构师
如果分为这四层，那我觉得我可能只能在第1.5层（学会和会学之间）
对于技术，在学习使用后，我会努力去了解背后的技术本质和业务场景，但是对于技术本质原理、应用场景的深刻提取，我现在也只能言之一二，“深刻理解”更是不敢说，所以我只敢说我在第1.5层
这是一个“知其所然”到“知其所以然”、从“人为我用”到“我为人用”的历程
台湾的侯捷大佬说过类似的话，“知其然而不知其所以然，是不明智的”，也是最低级的
作者在本班中所贯穿的理念是：
知识之上是思想，思想之上是精神。
我尚且还做不到精神层面，但我会努力把知识上升到思想层面，并在这方面积极做足努力
一个优秀的程序员，除了要：（这两个是最基本的，并且我也一直在努力）
- 迅速掌握知识
- 善于领悟思想
还必须：
- 具备务实与研究精神
- 独立与合作精神
- 批判与自省精神
这三点中，我觉得我最差的就是合作，什么东西都宁可一个人做了，因为“怕麻烦”
我不是内向的人，但是在有写代码合作项目时候，在需要我来划分模块时候，我往往希望一个人做完算了，一个人扛下所有挺好的，最多三个人，一个前端，一个后端（我），一个文档/原型，差不多了！
但我觉得我得正视这个问题，真的是怕麻烦吗？
是否是我在模块划分层面的不足？开发经验还是太少？组织架构与模块化的意识上欠缺了什么？
emm....今年暑期要去厂子实习了，希望能改善一下自己的这方面欠缺吧...
还有在最后，就是希望自己能跟本章提到的“传统学习”对着淦！
封闭——系统完备的终极式知识 单向——师教生学的单向式传输知识 被动——师命生从的被动式接受知识 静态——只注重知识的现状，忽略知识的起源、历程和未来趋势
我将努力做到：
- 构建开放包容的知识体系
- 眼睛不能只放在后端
- 更不能只关注技术
- 明白技术只是必要条件，而非充分
- 兴趣与热情驱动的主动学习
- 与同行积极交流
- 保持写博客的习惯
- 写什么都好，重要的是总结、复盘
- 总结、订正、debug的时候，才是我们真正在进步的时候
- 关注技术演变过程和发展历史
- 为什么有这门技术
- 它解决了什么问题
- 为什么这个技术比前面更好
终身学习，向死而生！
1.2 首轮提问——什么语言好？
看到标题我就生出了跟作者一样的想法：
这个问题很典型，很实在，也很初级。
许多刚入坑的人都有这个疑问。
似乎是在寻求一种学了可以一劳永逸的语言？
这个想法显然与高速迭代的技术市场背道而驰，讨论起来也没什么意义，对于这个问题，我一直秉承着的观点就是：没有最好的，只有最合适的。
不同的业务场景和需求，有不同语言可以施展身手的地方。
别的领域，也一样适用。
大家各有各的强项，如果A语言是最强的，那BCD存在的意义又是什么呢？自然没有BCD的市场了。
1.3 语言选择——合适的就是好的
哈哈哈我刚刚说什么来的，作者马上标题就讲了，英雄所见略同啊哈哈哈（请允许我尬吹一下
摘录一段书中的话：
评判语言优劣，如同争论兵器高下，倘若撇开使用的主体和对象，皆为空泛之谈 高级语言好比长兵器，威力强大却难免滞重，长于大型应用，可谓“一寸长，一寸强”；低级语言好比短兵器，轻便灵活却难免风险，长于底层应用，可谓“一寸短，一寸险”
他说了我很想说，但总结不出来的话，我觉得写的非常好。
好的语言，就是适合编程者和解决对象的语言
【fit】才是最关键的！！！
1.4 初识范式
追求【得意忘形】，是你我的目标：
得形而忘意，无异舍本逐末；得意而忘形，方能游刃有余。
心法，内功，重要吗？很重要。
学技术，一定要抓住抽象的根学。抓住根了，才能举一反三。
我们谈“面向抽象编程”，不是空谈的！
到底什么是编程范式？按照作者的说法：
如果说每个编程者都在创造虚拟世界，那么编程范式就是他们置身其中自觉不自觉采用的世界观和方法论。
你我，都是虚拟世界的创造者！都在创建着自己的黑客帝国！（只不过帝国有大小、优劣之分
当你编程之时，便进入到自己创造的世界之中。这是你的世界，只有注入你的想象力、创造力和激情，它才有勃勃生机。你编写的岂止是代码，分明还有乐曲；你敲击的岂止是键盘，分明还有琴键；你运行的岂止是程序，分明还有世界。当优美的旋律奏起，整个世界都随之翩然起舞，一种莫可名状的满足是否会充溢你的全身？
哈哈哈，这脑洗的，我喜欢，很艺术！
我们说的OOP（Object-Oriented Programming）是范式吗？是，也是最流行的编程范式。中文翻译成“面向对象编程”，作者认为不好，应该翻译成“对象导向编程”会更好：（港台翻译成“物件导向”）
我们知道，编程是为了解决问题，而解决问题可以有多种视角和思路，其中普适且行之有效的模式被归结为范式。由于着眼点和思维方式的不同，相应的范式自然各有侧重和倾向，因此一些范式常用 ‘oriented’来描述。换言之，每种范式都引导人们带着某种的倾向去分析问题、解决问题，这不就是‘导向’吗？而‘面向’ 的宾语往往是预先确定的目标，如面向世界、面向未来、面向用户、面向问题等等。此外，‘面向’强调静态结果，而‘导向’强调动态趋势，显然后者更生动，也更符合编程的特质。
所以这也是为什么很多人推荐读计算机国外的著作，要读原著，尽量别读翻译，就是这样了（比如Socket翻译成套接字，实在一言难尽啊...）
编程范式是抽象的，必须通过具体的编程语言来体现。它代表的世界观往往体现在语言的核心概念中，代表的方法论往往体现在语言的表达机制中。一种范式可以在不同的语言中实现，一种语言也可以同时支持多种范式。任何语言在设计时都会倾向某些范式、同时回避某些范式，由此形成了不同的语法特征和语言风格。
众语言布道者之间所争论的，无非就是其语法特征、语言风格了
换句话说，大家都有不同的“世界观”，何必互相强求呢？这可和做技术所需的包容心态背道而驰啊！
就比如说，实际开发中很少会用SICP中所用的LISP语言，那你能说LISP没用吗？当然不能！它的思想内核非常伟大，学习编程范式万万不可错过的一本书——《SICP》！
1.5 开发技术
许多应聘者喜欢在简历中言必称精通某某语言、某某技术云云，大多不必面试即知其大言炎炎——倘若真的精通，他当应聘更高的职位。任何概念和技术都不是孤立的，如果不能在纵向的时间和横向的联系中找准坐标，便似那群摸象的盲人，各执一端却又自以为是。
作者言之极是。
为什么作者谈论编程范式，而不谈论框架、设计模式和架构呢？
首先我们要知道它们是什么：
框架就是一组协同工作的类，它们为特定类型的软件构筑了一个可重用的设计。与库和工具包不同之处在于前者侧重设计重用而后两者侧重代码重用。
一个足够复杂的应用软件开发，为确保快速有效，通常采取的方式是：
在宏观管理上选取一些框架以控制整体的结构和流程；在微观实现上利用库和工具包来解决具体的细节问题。框架的意义在于使设计者在特定领域的整体设计上不必重新发明轮子；库和工具包的意义在于使开发者摆脱底层编码，专注特定问题和业务逻辑。
他们不都是提供一套API，那他们之间的区别到底在哪呢？最大的差别就是：
库和工具包是为程序员带来自由的，框架是为程序员带来约束的。具体地说，库和工具包是为程序员提供武器装备的，框架则利用控制反转（IoC）机制实现对各模块的统一调度从而剥夺了程序员对全局的掌控权，使他们成为手执编程武器、随时听候调遣的士兵。
那约束一定是坏事吗？我看不一定：
- 它让开发更加规范化、工程化、标准化
- 它为没有方向的开发者指明道路
凡事辨证来看，现实世界和计算机世界不一样，不是只有0和1。
如果说框架和工具包/库是具体的产品，那设计模式和架构就是抽象的思想了：
设计模式是软件的战术思想，架构是软件的战略决策
设计模式是针对某些经常出现的问题而提出的行之有效的设计解决方案，它侧重思想重用，因此比框架更抽象、更普适，但多限于【局部】解决方案，没有框架的【整体性】。
至于架构，一般指一个软件系统的最高层次的整体结构和规划，一个架构可能包含多个框架，而一个框架可能包含多个设计模式。
另外，作者在知识学习上也有如下观点：
知识的学习有几种方式：一种靠记忆，一种靠练习，一种靠培养。
孰能生巧嘛，《刻意练习》和所谓脑科学想说的，无非就是这个了。
所以呀，学习编程范式其实就是在培养我们编程语言的语感了。
从小学到大学，甚至博士毕业，除了英语类专业的学生外，大多数人英语练了一二十年，水平如何？不客气但很客观地说：一个字，烂；两个字，很烂；三个字，相当烂！口语甚至连一个英语国家的三岁小孩都不如。原因只有一个，那就是国内的英语教学方式严重失策。教学总是围绕单词、词组、句型、语法转，缺乏对语感的重视和培养，导致学生只会‘中式英语’。
同样道理，一个惯用C语言编程的人也许很快就能写一些C++程序，但如果他只注重C++的语法而不注重培养OOP的语感，那么写出的程序一定是C式C++。与其如此，倒不如直接用C呢。
范式关乎语感，需要慢慢的培养和渗透，不可能一蹴而就。
现在我们能做的也只是撒下一些种子，慢慢的会生根发芽，直至长成大树。那些设计模式、框架甚至架构等等看似神秘高深的东西，都会自然而然地在这棵大树上结出果实。
- Author:王帅真
- URL:https://blog.qizong007.top/article/4f60aedb-e103-409d-9fae-6097a5876cae
- Copyright:All articles in this blog, except for special statements, adopt BY-NC-SA agreement. Please indicate the source!
