怎么把看的书转化为能用的知识？
感觉很吃力。举个例子：
UDP通讯这东西应该属于大学必学的内容吧？
按理说写一个UDP通讯十拿九稳。
结果写出的通讯组件，卡了3 4 天，无法通讯接收广播报文。
最后发现是最基础的端口号没有指定。
就这种无法描述的不是个问题的抽象问题，把我困住了。
就感觉书本知识是书本知识，实际运用的根本不是一回事。
脑子缺了一门。
该怎么避免或者减少这种情况？ 笨办法是抄书，抄一遍从生理（客观）到心理（主观）都能加深知识掌握（信心），特别像你这样看书多，一目十行还能记下的，那不是人，是神仙，普通人看得越多忘得越多 实践总是要在失败中积累经验
—— 来自 鹅球 v3.2.91 多实践呗，还能咋 工程经验当然也是知识的一部分，唯手熟尔 脱离生产的学习，很难说有实际效果 书本来就是入门用的。要提高效率要么靠老师，要么靠社群交流。 这种问题多实践就行，多看接口的文档、例子，善用工具也有帮助，但是这些也是在实践中进步的。 本帖最后由 chachi 于 2024-12-25 14:57 编辑
那是你看书不仔细吧
tcp/ip协议里端口不可能不讲的
udp这种简单协议，包头就包含了原端口目的端口信息
另外三四天才找到问题，说明你解决问题的能力太弱了
综上：
1. 学习能力弱，看书不仔细，囫囵吞枣
2. 动手能力差，遇到问题发现问题点太慢，收集资料能力也弱
能力强的，
要么学习能力强，把书看懂看深入，结合实际立即就能上手
要么动手能力强，能找相关别人的例子转变成自己的东西
看起来你一样都不占
多实践,带着问题读书 很简单，你能对着另一个人把书的内容有逻辑地复述一遍，就算成了，甚至还传递了信息。 ai 写代码，你打个断点过一遍，不就会了。遇到看不懂的让ai解释，打断点再来一遍。 业务逻辑踩过才知道坑
不可避免
你要的是如何高效的总结和避免再次犯错。 你自己都已经给出答案了，实践一遍
—— 来自 S1Fun ...............你自己都说了.....当然其实古人也说过了：绝知此事要躬行啊 读书的四种收获：体验故事，认知事物，增长技巧，获得能力。你说的是后两者，都是要反复练习的 纸上得来终觉浅，绝知此事要躬行。
虽然实践和书本确实有差距，但你这端口没弄就去搞 UDP 感觉书本的知识也没掌握好啊 像编程这种工具书都是具体实践的抽象总结 . 读书确实能指导实践 但是不代表读了书就一定能实践成功 熟知目录，然后实践中缺啥找啥 别光看书啊，多看看前人看书的总结归纳，都帮你标记重点了。看多了你就也会看书里的重点了
学习下大牛们的思路 学校是懂一切理论，就是东西跑不起来，
实践是啥理论都不懂，就是东西跑得起来，
我们这里结合了一下，就是
啥理论都不懂，东西也跑不起来 编程就得多写，自然就记得了 中间再过一层，你拿学到的知识去看别人做的东西，等于换个角度再学一遍。实在不行还能问AI啊。 就标题回答，我觉得不需要太刻意，看过的知识对现实的影响都是潜移默化的
—— 来自 鹅球 v3.3.92 UDP没指定端口号，还卡了3，4天。
真的离谱。哪怕不看书，不懂什么是UDP，看着范例编程，也不会需要3，4天才能解决。 Baccano 发表于 2024-12-25 17:57
UDP没指定端口号，还卡了3，4天。
真的离谱。哪怕不看书，不懂什么是UDP，看着范例编程，也不会需要3，4天 ...
关键是我记得我指定。
所以就一直在编译器版本。
硬件和utf-8编码模式那里打转。 Baccano 发表于 2024-12-25 17:57
UDP没指定端口号，还卡了3，4天。
真的离谱。哪怕不看书，不懂什么是UDP，看着范例编程，也不会需要3，4天 ...
而且最诡异的是这个组件，在编译器的调试模式下是能够正常收发信息的。
在打包成为独立程序之后。
就失败了。
先能想起来再说别的 所以在理工科领域里面，知识和工艺是分开的两个层面
—— 来自 鹅球 v3.3.95-alpha 做个项目，遇到的困难再去现场翻书学，书也说不清楚就掏包华子问董哥 失败就是优化器，用来更新你的梯度的，不可避免 这种代码不是应该抄现成的 然后去读代码再理解吗
理解了后 直接记录下来 以后要用 直接把类和函数 抄过来改改
页:
[1]