这几天出门没时间回复，明天都回一下，抱歉(*´∀`)

>>No.63729936
经典的图论的可达性问题。

在代码实践中，我们需要先定义四种箱子的类型，即翻译成“被检测到为下一个时的状态”。
例如：
栅栏：如果是下一个则停止移动。
冰面：如果是下一个，则需要滑行直至遇到箱子/栅栏/边界。

而后建立模型，进行连通性检测。（深度优先广度优先都可以）
这样就解决了问题1。

而后是问题2最优策略。
这个就和图的形状有关了，每种策略适合的情景不一样。

肥哥这里是答疑串，具体算法实现我就不举例了，串首是我写错了(*´д`)

>>No.63744820
流程我在用gitlab，方便部署和加流程。
开发个人使用idea比较多，因为我经常得做多语言环境的代码分析，不运行情况下作为文本阅读器还是不错的。

家里服务器比较大可以用vm vsphere做虚拟化管理，不多的话docker或者k8s这种的也很方便。

这种和开发场景有关，并不通用。
我工作里面还经常用vi和vim改代码，不具有参考性(*´д`)

>>No.63756747
你得先搞清楚计算机网络的理念你晓得伐（范志毅音）

还是不泛讲了，计网这样聊名词太多也不好听懂。|-` )
聊一下在计网中需要重点关注的东西，方便你学习。
PS：这些是我认为重要的东西，欢迎肥哥补充。

>不要轻视计算机网络的发展史，认真听认真看
计算机网络是由小到大推广开的，小规模的网络在生产实践中也有使用场景，了解计算机网络的历史，才能知道计算机网络是如何“搭建与探索”的。

>网络的结构决定了它的特性
如何实现“万物互联”，网络的连通访问，信息的传输。
在学习时可以思考一下网络的整体结构，与信息传送时是以什么形式发送的，有整体观念会便于后续的细节理解。

>协议是网络的具体实现
学习计算机网络，最后还是会落到协议上，那么协议具体是处于哪个部分，是用于处理哪些问题，在有了整体概念之后就很好解决了( ´∀`)
协议大多数时候是为了认证与效率这两件事存在的，同类型的不同协议也是在这种地方做了差异化，按需学习即可。
有能力的话推荐深度分析一两种协议的实现，难度不高，但是有助于学习理解。
（可以不分析偏向与目的，看看参数与交换包情况与认证情况之类的，这就看学习深度需求了。）

po之前工作需求做过一些域内的票据协议的深入分析，还蛮有趣的(〃∀〃)

>>No.63757005
肥哥，跨方向的岗位指点不可信——

不过我可以给你一些我自己的选择分析思路参考，希望肥哥能够找到适合自己的方向。

通常我会将现有岗位分为四种类型，以其主要代表的工作属性进行划分，再深度就是工作内容了，完全是喜好领域。
分为销售，管理，工程，科研。
po做过工程，科研，管理，这三类岗位。
PS：虽然都不长，但是都接触与实践过。

本来想挨个说说特性，但是肥哥一眼名字也就知道了。
它们就好像在一条线上，左边是与人接触，右边是与项目接触，肥哥可以先根据自己的性格偏向，选择属舒适的岗位类别，而后再确认这类岗位通常有哪些可选内容，最终进行选择。

po是那种性子散漫的人，所以最终还是没安分下去主动辞职了，让一个不喜欢工作的人推荐工作，很困难(*´д`)

好popo，请教一下学习编程语言的正确方式是什么（最终目的是掌握对应编程语言在专一应用场景下的基本常见操作），我现在的学习方式还是基于C的那一套，变量&格式→I/O→条件&循环→递归→核心特性（例如C中的指针）→文件操作→库函数→算法
但是发现这样的路径对于C++或者Python什么的不太适用，到核心特性那里基本上就学懵了，找不到什么是核心特性，特性太多了，各种定义、方法和操作符目不暇接(;´Д`)
也尝试过跟runoob一类的教程网站走，但最后总是针对一个功能一脸懵地去问AI，AI总能拿出一堆我没听说过的方法，然后进入用新方法解释旧方法，问题越来越多的循环。
也尝试借助各种网课构建框架，但是总是讲不到我想听的点上，最后发现学了一堆没什么用的，无法应用于工程中——所以求po指点迷津，如果以专一的工程应用作为目的，到底应该怎么学这些高级语言？或者我该回去补习大计基？|-` )
举个例子，我想面向win基于Python实现一个状态显示窗体，然而学了一堆元组、字典操作之后发现，这些跟能直接解决问题的tkinter库没什么直接联系( ´_ゝ`)

>>No.63770573
好popo听到了你的呼唤并予以回复，po门。
首先可以参考一下我前面写的这个回复中对于“面向过程”与“面向对象”的区别定义>>No.63714490
肥哥的思维还是局限在面向过程的范围中，所以当你需要搭建一个东西的时候，会首先想到需要怎样从零去搭建这样一个产品。
但是在面向对象的思维中，你的第一反应应当是我需要这样一个东西。
来举个例子，就用你说的窗口框体举例。（我没写过只是随便举例思想，实现与拆解不一定准确。）

>首先，你需要一个框体，那么我们创建一个框体类。
框体类里面需要什么东西呢？
我们要装进去十个小框框。
先定义一个小框类，然后放到框体类里面。（PS：这里可能就需要你的数组能力，因为数组让这十个框互相有了联系，而不是十个独立的框。）
那么这个框体类现在的内容就是十个小框。

>接下来我又想要小框有功能了
这样就需要对小框类进行具体的功能实现。
可以选择抽象小框的共性：比如他们都是小框。
而后对每个不一样的小框进行具体的实现，塞进去具体的功能。（PS：这里就需要你拥有字典，调用等等多方面的能力了，具体的最小逻辑的实现就是“面向过程”的，这也是为什么这些语言比面向过程语言高级，因为他们更好理解，逻辑层级更高。）

>小框都实现完成了，我需要大框
假设我们只需要一个大框，那现在对这个大框类进行调用与实现。
一个大框加十个小框框的场景我们就解决了。

要理解所谓的“高级”，并不是语言更高级了，而是你的思维角度更高了。
你不需要考虑底层实现，要考虑项目需求。（PS:这里的意思不是说不去实现，而是实现相对低级，不是一开始要考虑的。）
举个不恰当的例子：高级语言就像画图纸，是一个确定项目需求与拆分需求的过程，低级语言是实际板砖实现的人。
当了解了这一点再去学习所谓的特性等技术时，思考角度便从“这个特性有什么用”变成了“我在什么时候需要用到这个特性”，也就是你的思维更加高级了。
别人写好的库只是写好了过程等待你去调用。
这就是我理解的“面向对象的思维”，但是很多地方都没有讲清楚，我也不确定我是否讲清楚了，肥哥觉得不清楚还可以追问，我再尽量明晰一下。

编程语言只是实现功能的工具，而不是功能本身，特性亦然。
（PS：以上提到的的高级与低级无歧视意味，只是进行类别区分。）
(*´∀`)

>>No.63771247
(っ˘Д˘)ノ<po门！！！
感谢好popo的指点，真是醍醐灌顶，虽然难以理解( ;´д`)
之前只是简单了解C++和Python特点是“面向对象编程”，但是不知道其根本区别是什么，以我贫弱的理解，感觉根本上都是“执行一段代码，完成一项任务”，没什么本质不同？

>>No.63771802
只是说最本质的东西倒也没错，但是太模糊了。
python作为解释性语言，它的设计目的是使编程易于学习与使用，所以它会尽量去减少“非必要的”编程能力的输入，希望你能够学最少的东西干最多的事情。
（关于什么是解释性语言，肥哥想深入学python可以去了解一下。）
C++如其名，它想保持C语言的高可用和高效性，希望能够更加接近硬件结构，可读性之类的就不在第一位，会发现编写的难度较高，通常追求效率的地方会用C++编写。
JAVA是追求跨平台与安全性的产物，丰富的特性决定了它有更好的复用性与安全性，企业开发用的比较多，但是江湖人称“裹脚布”，用起来是又臭又长，个人觉得写着很折磨。

总来说“高级编程语言”只是一个大类，它们生存至今还是有自己独特的受众与设计目的，了解这些有助于区分语言与实际项目中进行语言选型。

（PS：实际还区分纯面向对象设计语言与部分面向对象设计语言，这个就肥哥接触到再去了解吧。）

肥哥也不要心急一开始就搞完全懂，可以尝试写两个小型的完整项目或者下载别人的项目，参考一下代码结构，思考架构设计原因与分类原因，这样就能逐渐提高理解深度了，循序渐进(=ﾟωﾟ)=

vscode安装了extension pack for java，spring boot extension pack等插件，但List(java.util.List)类不能自动导入，却可以手动导入(╬ﾟдﾟ)

以及

>>No.63790963
这种可能是检索时出现重名之类的问题，可能出现问题的地方很多，po这里也解决不了，可以直接发在相关板块问问肥哥( ;ﾟдﾟ)

我是一个对社会一无所知的计算机系学生

问下肥哥，想进互联网公司赚钱钱一般需要那些技能呢？( ﾟ∀。)7"

好popo，我本科刚毕业，还没任何工作经历，不过维护一个开源项目两年多了，获得了500star，近期遇到了很多问题，虽然说不是对“计算机”的“质疑”与“好奇”，可能更偏向于“工程”和“项目”，也想向你求教。
1. 一直以来我希望自己的代码能保持比较好的规范，让它不至于堆成屎山，但是我发现我并没有成功，以我的开源项目为例，我最开始还能对项目的每处功能了如指掌，但是随着功能越做越多，现在我发现之前很多地方有莫名其妙的耦合、不恰当的硬编码字符串，还有不好的模块组织方式。我想知道，有没有对于一个初具规模的项目，进行管理的好办法？
2. 我想通过阅读一些高水平的项目，来提升一下自己的水平，但是看了一些我常用的开源软件的源代码，感觉真的无从下手。阅读这些有必要吗？
3. 常用的一些设计架构、最佳实践这类东西，我感觉实在是太多太琐碎了。比如说我希望别人在贡献时代码格式按照一定规范，我发现得做这个开发语言常用的格式化工具的配置文件放在项目目录下；模块划分也各有个的方法；软件如何进行测试，怎样构建必要、有效的测试，我也不知道怎么做。
我越开发软件，越觉得需要顾虑的东西多，反而束手束脚了，我怕在未来这些代码成长成我不认识的怪物，有什么办法吗？

>>No.63890194
没想到这个串还会有肥哥光顾( ;´д`)

笼统的来说，你需要“能够帮公司赚钱的技能”。
这个赚钱可以是直接赚钱--销售类技能。
可以是间接赚钱--提升产品竞争力与市场占比。
可以是间接间接赚钱--提高产品质量与产品美观度。
甚至可以是省钱--降低产品风险。
通过这些肥哥可以分析一下自己擅长什么，每个方面都会有众多的技能与思路供你挑选。
>能够给公司带来大于工资的收益，那么公司就会考虑与你搭建合作关系。

同时不仅仅要从自身考虑，也得考虑自己目标是什么样的生活，哪种类型的企业更可能给你提供这样的生活。
举例:
小型企业需要能力的全面性更优秀，他们解决的问题复杂度更低，但是需要亲历亲为，同时小型企业的抗风险能力较低。

有点像是发展规划的问题，不要被专业限制了自己，你甚至可以去学不属于计算机的内容，但“所学所知皆有所用”。

上面有点鸡汤，想说些干瘪一些的。
但是写完发现没什么参考价值，便删掉了，单纯的计算机领域在现在生活中已经渗透进了方方面面，进入这个领域总可以找一份工作，要走多高多远，才最终决定了要学哪些东西，很难泛泛而谈。|∀` )

肥哥找到属于自己的适合自己的方向便是。

>>No.63893819
肥哥，本串不做内容限制，想聊什么直接说就好，po尽力回答，也是沟通与提高。( ´∀`)
首先，赞美肥哥的开源精神，po写的很多东西最后都没有选择开源，因为不能保证自己长期维护。

>项目架构管理有没有什么好办法呢？
很抱歉，这个答案是“没有”。
不同项目适合的架构不同，项目在不同的发展阶段的适合架构也不同，没有一个架构能够完全通用。
同时也不推荐在一开始想太多，过分复杂的架构也会成为项目成长的阻碍，逐步去调整架构，或者在过于臃肿时果断推翻重写是比较常用的做法。（PS:实际上在规模达到边界时，推翻重写的成本和继续维护也差不多，有许多模块可以复用，只是调整调用逻辑，对于个人开源项目，修修补补反倒不如一个干脆地2.0来的更舒服，也有易于后续更新。）
同时在新的架构设计中，肥哥可以融入更多新的思想与新的实践，适当剔除曾经用不到的代码块，这样的产品是大家都乐意见到的，我相信也是肥哥更想要的东西。

>阅读真的有必要吗？
这里得问问肥哥，“在读什么东西？”。( `д´)σ
肥哥是想学习它的架构，想学习它的实践逻辑，还是想学习它的设计思路。
每个东西在项目中的占比其实都不大，肥哥觉得无从下手，很多时候是拿到代码就直接去看了，不够有目的性，一个项目都去看，代码量是极大的，并且会深陷其中越学越乱。
肥哥不如静下来先明确一下自己的需求，再去看相应的项目，这样肥哥也能知道自己到底在对比些什么。
同时肥哥也可以看明白它们为什么是好项目，到底好在哪，相近的项目的设计差异到底在哪里，学到东西，肥哥的能力自然就提高了。

>开发逐渐束手束脚。
这个我认为肥哥可以先了解一下SDL（软件开发流程），这样可以明晰自己需要做哪些事情。
同时肥哥考虑的实在是太多了，这反倒不好，因为你不是在做一个“完美的项目”，项目有问题是正常的，需要修改更是正常的，没有人能够保证自己做的东西“永远是最佳的”，所以肥哥也不要追求事实完美，先完成眼前的工作，之后有能力与时间再做调整。
拆开这几个小点聊聊。
1.希望被人在代码贡献时按照一定的规范。
肥哥可以直接讲明自己的规范规则，单独写一个共享代码的格式文档，讲明什么样式的代码更容易被认可，并且给出一两个例子。
说明不适合融入项目或融入成本较高的代码不会采纳就好了。
2.模块划分各有各的方法。
模块化最重要的是“有统一标准”，肥哥在本项目中使用同一套划分标准，所有模块的切割逻辑统一即可，不必要追求极致。
过度模块化也是目前项目的一个“误区”，有时候内部通信效率更高，也没必要完全分块，适度才是最难的。
3.软件如何进行测试。
软件测试的方法种类太多了，本身也是一个学科，很难细细讲清。
首先肥哥在代码上线前应当做好足够的测试，同时需要留出模块的测试接口。
测试要尽量保证覆盖全面，需要考虑多种使用情况等等。
上面只是开个玩笑。
肥哥在测试时需要逐步拓展，先保证基础功能可用，而后当功能出现异常时鲁棒性是否足够，安全性是否足够等问题再逐步加入进去，实在麻烦先保证基础功能可用，剩下的之后再议。
项目在人力不足时不要太“贪婪”，先做好能做的事情，再寻求拓展。
我以前在公司开发的项目，甚至一开始完全没有预留测试功能，测试工具还是后期单独写的，这不影响它曾经是一个不错的项目，贪多嚼不烂的道理肥哥肯定都懂，只是身在居中有些迷茫。

最后提醒一下肥哥，培养一个好的“孩子”的最好方式是放手让它自由成长，太限制自己的同时也会限制项目，有错就错了再改，有问题出现问题再解决，束手束脚有违初衷。|∀` )

PS:肥哥想了解的知识实际上都有对应的书籍去讲解，并不一定只能从别人的项目于代码中学习，从前人总结的内容系统性了解也是不错的学习渠道，学习效率也会更高。
肥哥在自己做了开发工作之后再读书也会有深入的理解，是与作者交流的过程。
例如:《代码之美》，《架构之美》，《软件测试之道》等。

po解答的最后一个问题太好了。工作了一小段时间写代码总是陷入这种焦虑，对着太多需求和变更总是觉得自己做不到最优解，绞尽脑汁钻牛角尖想了半天，觉得做不好做不完，代码太丑了写不下去。实际真的着手写了也还好，不过也会有写下去了觉得代码丑的不行了直接回退版本重新开发…
有时候还是太畏手畏脚了，反而效率变低了( ;´д`)

>>No.63896355
感谢popo

才发现移到社畜串了（ ´∀`)
果然畜味太浓了( `д´)