看书对学技术的重要性；前端er工作中应该怎么提升自己；怎样才算是在写有“技术含量”的代码｜极客观点

等登凳灯~~各位社区的开发者们，大家周末愉快！

不知不觉，SegmentFault 思否社区全新的版块 #极客观点  已经上线三周啦~

极客观点 聚焦于技术方向、程序员职业发展、个人成长等主题，致力于发起有价值的讨论，输出有价值的观点。

在本栏目中，我们将为大家推荐在 #极客观点 版块被热烈讨论的话题，甄选出有趣的观点为你呈现。期待我们一起成长和进步呀 🥰🥰

今日关键词：#看书的重要性 #提升自己 #“有技术含量”的代码

看书对学技术的重要性

话题发起人：沐沐

遇到问题可以各种百度、google，看书的意义在哪里？

有趣的观点：

在互联网上寻找问题的答案确实很快，但看书也一样很有必要。只不过得看我们在看的是什么书，有很多优秀的书籍，书中的内容在网上，或者说在篇幅较短的一篇博文中是无法讲解透彻的。书籍能够更加系统、深层次地帮助我们理解一项技术。长时间看优质技术书籍的人会对一些技术理解的更透彻，自然解决问题的能力就越强。解决问题是一种被动的行为，而看书是一种主动的行为，前者能快速提高自己的开发水平，而后者则是使自己走得更远更宽的基石，二者结合可相得益彰。

—— —— 社区用户：BeerBrar啤酒熊

有趣的观点：

以我多年的经验来说，看书对于学技术来说效率太低了。

首先，你要知道，你学技术的目的是什么。如果是准备考研考博搞学术研究写论文之类的，那么也许你看书还有点用，把系统知识搞扎实点，每个概念都搞懂以备考试，这可能确实有点用。但如果你只是想学一门手艺，只是想搞定一个问题，那么看书无疑是所有方法里效率最低的一个。比如你用js编程的时候遇到一个问题：在a字符串中查找b字符串，你为了这个问题去看一本书？你想掌握这个技能的话，不如多写5000行程序，经常用到这个函数，以后你不用百度也能背出来，这就够了。

其次，工程和科学不一样，工程不需要那么严谨，需要的是速度和时间，你的老板没工夫等你去研究透一本书再来帮他解决问题，他要的就是一个答案：行不行？快点，不行就换人。就这么简单。他又不是你爹妈，等你慢慢成长，你怎么成长是你的事，但对老板来说，目前眼下马上就能解决问题的人才是公司最需要的人，所以看书对公司来说是不可接受的。

所谓系统地学习知识，人类的知识都是在盲人摸象中增长的，以前没有那么多专家，有的都是博学家，杂学家，学的很杂，是后来才有了大学，才有了专业，是教育和考试的需要才搞出了所谓系统知识这种概念，这个概念并不是自然就有的，而是人为制造的，只不过你在这样的教育体系中被灌输了十多年，给你造成一种错觉以为知识是必须靠系统学习才能掌握的，其实人世间能够通过看书学习的知识连十分之一都不到，社会实践这个大课堂才是你补足另外需要的十分之九的知识的地方。

中国古人也并不强调死读书读成书呆子，红楼梦里有一幅对联写的好：世事洞明皆学问，人情练达即文章。在认为死读四书五经才是学问的当时，都已经有很多人看透了：学问在哪里？不在经书里，而在于对于世间万物运转本质的洞察，这些洞察从哪里来？从反复实践中来。

毛主席的《实践论》最后说道：

通过实践而发现真理，又通过实践而证实真理和发展真理。从感性认识而能动地发展到理性认识，又从理性认识而能动地指导革命实践，改造主观世界和客观世界。实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。这就是辩证唯物论的全部认识论，这就是辩证唯物论的知行统一观。
实践不但是检验真理的唯一标准，并且是发现真理的唯一手段，任何脱离了实践而试图直接获得真理的手段都注定只能是妄想。

—— —— 社区用户：张京

我是前端，工作都是做一些业务，那应该怎么提升自己呢？

话题发起人：子栖

工作基本都是一些业务，难点基本不是在于技术，而是理解需求，自己也学了一些东西，比如jest，比如rollup，也看了微前端，但是工作中基本用不到，然后不怎么用，其实也无法深入。
此外，自己也想加入一些开源的项目，但是很多开源项目都是迭代更新了很久，自己也没有找到好的切入点

有趣的观点：

确实是这样的，大部分的开发都是围绕着业务来的，大多数人都是由业务来驱动学习，并不是由内驱动的。所以在面对没有业务需求的技术时会感觉到没办法落地，也没办法深入学习。感觉流于表面。

可以尝试自己写一些小玩具，比如说提到的jest来写单元测试。但是很多时候为了赶工期并不会去写测试单元，可以尝试着去解决这个矛盾。尝试的过程中你就会学习到比原本预期更多的周边知识。其实对于单独学一块内容更加能够提升自己。

如果你想参与一些开源的项目，可以先从提Issue开始，慢慢的开始发现问题并且给出解决方案，开始尝试提PR，等你的PR质量变高了、提交频率也可以，自然就有机会加入到维护团队当中了。

当然能力的提升并不是只限于技术开发的。如果你有比别人更出色需求的理解理能力和整理能力，你也可以表现出来，这也是你能力的一部分。

—— —— 社区用户：陟上晴明

有趣的观点：

首先还是明确原则：独行快、众行远，优先促进公司业务发展。

所以，比如目前缺测试，就多写测试。写测试的时候你就会发现，写起来好费劲，读起来效率也很低，然后你就可以研究下测试相关的知识，比如 e2e 测试、比如 chrome devtools 新增的操作记录工具、比如自动化测试。然后你就可以想办法优化这个过程。

或者前端打开速度有待优化，就可以研究怎么提升构建工具或者改变打包结果，然后也可以生成更高效率的页面。

总之，从公司需求出发，从真实价值出发，先做起来，不要怕累不要怕无聊。很多时候没做，或者不知道该怎么做，其实是想一下做个 Vue 出来，以后就吃喝不愁了。

—— —— 社区用户：Meathill

对于程序员来说，怎样才算是在写有“技术含量”的代码？

话题发起人：why技术

如题；对于程序员来说，怎样才算是在写有“技术含量”的代码？

有趣的观点：

“技术含量”这个词，不好界定。

这里有一个故事：初级程序员运键如飞，一天写了 1000 行代码，效率非常高；高级程序员如老僧入定，盯着屏幕半天才搞几下键盘，两天只写了不足 100 行……

看到这里，老板们都想去招初级程序员了，毕竟效率高，还不贵。但是后来呢？

后来一个月内，初级程序员写那 1000 行代码经常反复修改，增增减减已达数千行的变更；而高级程序员那不足 100 行的代码只改了两个拼写错误……

再然后，那 1000 行代码始终存在不可解决的问题，只好让高级程序员来处理一下，于是高级程序员经过 3 天的重构和修改，把 1000 行代码改成了 100 行，再没出现过问题……

故事就是故事，但在一定程度也反应了事实。高级程序员和初级程序员的差距，就在于“技术含量”，而所谓的技术含量并不仅仅表现在代码上，而是表现在对目标的理解、完整的逻辑分析和精准的代码描述和高覆盖率的容错处理上 —— 说白了就是 —— 即时是一个小任务，也仍然需要经历分析、设计、编写、测试几个阶段，而不是简单的照着字面意思一阵狂写，把代码堆出来了事。

软件开发技术，涵盖了软件专业方方面面的知识。大学里学的各种原理、语言、数据结构、算法，甚至数学和英语都能起到增强软件开发技术的作用。

当然，如果只是想说写些看起来高大上的语句，倒是也不难，只需要做到两点：

• 了解你的技术栈，尤其是语法，熟悉各种语法的用途并能在写代码时恰当选用
• 了解技术栈的函数库（类库），知道在写功能的时候有什么东西可以用，而不是自己去堆代码实现一个不稳定的新轮子。

此外，借助工具的力量，可以非常有效的提交自己的编程技巧，比如：

• 用熟你的 IDE/Editor 和技术栈工具链
• 使用 Lint 类工具，尤其是自带修复功能的
• 重构类工具，会对可以重构的提供做出提示的（虽然不一定照提示实施）
• 智能代码类工具，可以方便的看到别人是怎么考虑和处理的同类问题。

—— —— 社区用户： 边城

有趣的观点：

首先是看你的代码觉得你基础知识是掌握的牢靠的，不会犯那些低级的错误。例如一些一些数组的操作函数，你却自己去实现了一遍；类和子类调用方法时，你不知道怎么去调用，到底调用的哪个，有些语言层面提供的功能，你却不知道，等等。

在符合业务的前提下，你的设计是不是合理、清晰，逻辑的考量是否完备，模块的设计，类的设计，相关算法的设计等等。

对于逻辑性十分强的部分，你是否有足够的注释，让别人能够清晰地了解你的思路，而不是写一堆晦涩难懂，高级语法堆砌成山的代码，能用简单的方式实现的逻辑，就不用复杂，晦涩的方式去实现。

—— —— 社区用户：hero

他们的观点和讨论是否也能带给你启发呢？你又有什么有趣的观点，希望与大家分享？快扫描二维码加入我们，一起交流成长吧，等你哦 🙌🙌🙌

欢迎在评论区留下你的观点呀~