学习新技术遇到麻烦应该怎么思考

从加入软件领域, 每年都要学很多东西, 这些东西甚至都属于不同领域的. 在许许多多的新技术或者新的知识面前, 有很多坑要爬. 要换作以前, 我对自身持有一些怀疑, 总觉得有些问题需要一些"高级"的工程师去完成, 经过这么长时间的历练, 一次次独立完成需求或者bug. 变得不再把困难当回事. 艰难的bug, 复杂需求, 长工期的需求, 没以前那么敬畏了.
这种感受最近越来越明显, 记录一些最近遇到的问题, 做一个描述和分析总结

最近遇到springboot图片(文件)上传的麻烦

1. 图片上传功能, 后端始终提示"Required MultipartFile parameter ‘file’ is not present" error"
2. 解决了上述问题, 用postman测试成功后, flutter客户端上传文件还是没成功, 后来多个方面猜测和尝试, 最后在查找到的一个网页里解决了

我为什么会遇到这2个麻烦

为什么会遇到图片上传springboot的问题

• 我没有写过springboot的文件上传, 第一次写, 网上的代码很多不能用, 很可能因为我用的springboot的某些框架的版本不一样, 导致我的复制粘贴没有避开这些问题
• 同样的报错, 我百度上解决方法千篇一律, 看20个网页也就5种解决方式. 在搜索的过程中, 逐渐放开思路, 换一种思路才碰到自己近似满意的答案, 再结合多个google出来的页面, 挑选出能解决问题的方式
• 在解决这个问题中, 因为我对springboot的网络日志文件不清楚, 导致了我专门添加了一些"springboot的全局日志配置"之类的代码, 期望获取足够的日志信息去分析问题. 最后却没达到期望

为什么会遇到flutter上传文件的问题

1. 我以前用的是flutter dio 2.x版本, 现在升级到flutter dio 3.x版本, 图片上传这边的API修改了
2. 当我从网上寻找资料的时候发现dio 3.x的资料条目数还不够百度搜出来的一页那么多, 有的写的自身有问题
3. 通过自己尝试阅读dio的接口代码没有找到解决问题的方式, 倒是和网上的例子代码对比得出结果
4. 在解决这个问题的时候发现了另外一个问题, 怀疑他们可能有关联, 就先去解决另外的问题了

工作中什么最重要

在任意一个公司或者项目里, 都会要求效率, 甚至还有一些会要求不可能达到的目标. 不懂技术的人负责项目就是大坑的存在, 程序员本身经验和表达能力也会导致自己被工期坑到

• 搞定需求
• 解决bug
• 保证程序健壮, 尽量避免隐藏bug/大量bug/严重bug
• 保证工程的结构清晰, 重复代码少

总结: 就上述遇到的图片文件上传的问题, 在遇到不懂的技术点和功能点怎么能快速解决呢?

1. 找一个例子代码, 对比代码差异, 有时候会因为开发环境和框架版本的问题导致同样的代码别人的就是能运行, 这样就得对比环境的差异, 实在不行从0开始把该功能拆出来写一个demo, 单独调试和理解.
2. 不断的根据报错进行网络的搜寻, 百度+google, 如果百度解决不了果断google吧, 珍惜生命, 快速过滤无效的网页, 和不一样的问题描述.
3. 以上2种的任意一种一般都能解决问题, 如果还没有解决, 可能是程序员缺乏块状技术知识, 如果对某一块的知识是一知半解, 在筛选信息, 分析问题的时候会比较困难. 这时候需要系统的学习某一个领域的知识, 甚至抛开项目去"从入门到熟练"某种技术, 然后再回过头来理解以前遇到的问题, 可能会有新思路
4. 发散思维, 避免被自己的思维禁锢, 在排除问题的时候每一个思考点都是可能的bug点, 一旦遗漏就可能导致错过. 如果思维比较紧张, 尽可能做一些放松的行为, 比如看看别的东西或者起来活动一下, 避免持续半个小时停留在一个陷阱里.
5. 一个软件工程要确保容易被调试, 这样程序出了问题定位就容易一些, 常见的log和层次分明的架构是减少陷入"自己挖的坑"的必要条件

大概总结这么多, 有新的感悟再进行重排版和补充吧