个人最近的一些编程技巧

最近编程的量比较大，积累了一些经验，一直以来，我的编程都受广大互联网网友的支持，故非常乐意分享一些个人的经验，希望大家少走弯路。

大概总结几点：总体规划、局部技术速通技巧、改装代码和查bug技巧。

总体规划

先在知乎或者CSDN上面问一下类似的项目需要什么，学习路径是什么，少走弯路。

一个程序或者什么项目的总体规划，重要，但是也是需要很多随机应变的，比如说项目要使用网上资源微调大模型，需要爬虫，这个时候，项目的技术核心是大模型的微调，像数据集的处理和爬虫，这些都是配套技术，更多的是需要能够执行功能，不太需要优化，也完全不需要自己去掌握，这些项目的辅助技术，就需要速通。

速通不仅仅可以有效削减工期，更重要的是让我们心情不那么烦躁，也不那么容易虎头蛇尾或者直接把项目水掉，特别是对于本科生来说。

核心技术也是这样的，能用别人的包，就用别人的包，互联网上，但凡是给你用的包，那都是有必要给别人直接用的包，换言之，包就是别人知道哪些比较难，你可能写起来很恼火，然后分享给你的，工欲善其事必先利其器，使用包也会显著改善我们在项目中的心理状态。为什么心理状态非常重要呢，想必程序猿遇到bug的体验不少，这应该无需我在此多言。

还有一个点，那就是项目的大小评估，这也是比较重要的，有的项目比你想象的要大得多，到时候会有一种“作业越做越多”的感觉，但是有的又没那么大，把项目估计得过大，很容易劝退，毕竟生活还是要理性的。

但是非常扯淡的是，评估项目大小只有在项目快完工的时候才知道。但是根据我自己（本科生）的经验，如果是我们自己开的项目，实现起来其实也不是那么困难，大多数时候你评估起来项目很难，都是因为你没见识过现代教育和工业体系的成熟和高效，前人和高手都给你铺过路了的，你只需要找到这些路子就行了，所以不要放弃，可以搁置，也可以暂停，但是不要放弃，这也是我的一条经验。

局部技术速通

速通是非常重要的，或者说，不要恋战，我们都是想出成果和把自己的设想落地的，在一些看似身体力行但未知的，需要我们去学习的技术面前，把脸拉下来，速通，这还是很重要的，心理和工期情况都会改善的。

速通大概有两种方式，一个是使用商业产品，这个比较推荐，拿经费换头发，没什么不好。但是为了让更多的人走上免费之路，大家可以在网上多搜索免费的应用，很多付费的应用都对应着免费的应用，大家多去搜索一下，或者直接搜索“免费在线文档翻译”这种，然后就会有一篇知乎或者B站链接，给你仙人指路。

如果囊中羞涩，那就需要“借鉴”了。借鉴的问题会比较多，常见的问题会有，看到一大堆示例和教程但是不知道从哪里开始，很多教程文档堆在屏幕上，但是很多都是你用不起或者不对口的。

网上有很多教程，我常去的是博客园、CSDN、知乎和B站大学，人工智能写示例代码也算，这些很难比较优先级，但是你需要的那个教程在互联网的哪个角落，很难说，这个就只能自求多福了，我真的没办法，可以平时多积德行善。（doge）

改装代码和查bug技巧

不管是核心技术，还是辅助技术，都可以速通，如果比较急于出成果或者项目落地，那么核心技术也是建议速通，知识是学不完的，强者可以“技多不压身”，但是我们不是强者，所以接下来我总结一下改装代码和查bug的一些技巧。

需要速通的，还是能抄就抄，只需要理清每一段代码输入什么，输出什么，就可以了。借鉴的代码中间会有很多复杂的处理过程，但是我们不需要理解，因为理解代码很麻烦，数学原理直接在B站大学那里找，这样有的时候学得更好。

为此，以Python为例，多使用print()函数，看看输入的是什么，有的时候程序的bug就是这么可以看出来，还有就是type()函数，直接看看输入的格式是个什么，还有len()函数，有的数据量有点大，那么可以用print(input[0])这种代码看一下输入和输出，以及变量的大小和类型，看不懂的输出和报错积极地去互联网上查，网上很多文档来帮助你的。

还有一个就是bug定位，这是非常头疼的事情，大家不必相信自己的脑子和眼睛，因为不靠谱或者有时限。

先把程序分成几节来检测。在C里面可以用“等待程序员响应”的方法，让程序员“在回路中”，就是程序按照功能划分，间隔一个等待函数，常用等待键盘，要是能成功执行这个等待程序员响应的程序，说明前面执行过的程序都是可以执行的，要是某个等待程序没有得到执行，那么bug很可能就在前面哪个地方，然后再结合print()或者cout()函数，上面的技巧可以用在这里，把程序中间执行的各种信息print出来，看自己改装的代码和别人的原码中间哪一步输入输出搞错了。在Python里面，如果你使用的是朱派特的笔记本Jupyter Notebook，那么它自动就把这些都给你分开了，会更加方便地定位。接下来就是常规地去互联网上查报错的解决方案或者报错的函数它真正的用法。

这些技巧非常简单，但是使用频率会非常高，至少我的经历是这样的。没人写程序不写bug，反正我是平均一句代码要反复执行四到十次。至于这个流程图，个人认为不必要，前提是你写代码的习惯比较好，主函数里面的各种细节都用函数封装，整理好写在其它地方。

自己写的那部分程序，其实难点不在于程序本身，只要数学上可以实现，那么程序就没问题，只需要把自己的数学模型搞好，程序算法搞好，这比较关键。