共计 2556 个字符，预计需要花费 7 分钟才能阅读完成。
一、背景
写这篇文章的想法来源于最近的工作：对 Worktile 客户端降级重构和解决现有沉积的 bugs，这对于我来说是个难题，因为这是一个几年前的老我的项目了，性能和逻辑尽管不是很多，但其中存在着一些历史起因，目前负责该项目标共事曾经到职，留下的文档和材料比比皆是，能够说代码是惟一文档了；第二，我的项目是用 Electron 写的，我本身对 electron 的相熟水平也只是停留在入门阶段，那么要实现此工作天然破费学习老本。在面对上述问题的过程中遇到很多艰难，踩了很多坑，目前我的项目曾经实现，针对下面的艰难谈谈在这“无助”的状况下是如何克服和解决的，我把我的过程回升一个层面总结为本文的主题：作为程序员，你遇到问题时会如何去解决？领有解决问题能力的人，是稀缺的。
二、渠道 / 伎俩
1. Baidu or Google
遇到疑难杂症，百度和谷歌是必不可少的解决伎俩之一，置信这也是大家最罕用最下意识的方法，“面向百度 / 谷歌编程”，“CV 工程师”，“CRDU”，这些标签可不是白来的😂，但不要感觉这很低级，百度 / 谷歌的确是十分高效的解决伎俩，很多时候谷歌 5 分钟的事，却要在一些技术群里听“大佬”吹逼两小时，只能说 google yyds！
2. 官网 / 社区
当百度和谷歌解决不了的时候，那么咱们须要其余伎俩：找官网、找社区。
2.1 翻阅官网文档
对于翻文档是很多小伙伴不愿做的事件，尤其是遇到非中文的文档更是令人烦恼(庆幸的是 Electron 反对多语言)，但官网文档的确是信任度是最高的，效率也还不错，遇到困惑的时候就多翻翻文档，每次仔细阅读总能发现之前疏忽了的细节，往往这些细节能帮忙你解决问题。
2.2 我的项目托管平台提 issue
支流托管我的项目的平台有 github、gitee 等，它们都会有一个性能叫 issue，这是专门为开发者提 bug 和提问题设立的。
我降级了 Electron 最新版本后，许多性能不可用了，这必然在我的项目中是零容忍的，而且这应该属于偏细节的问题了，过后是比拟难解决，每个问题都要花上几天工夫，很是焦虑，这种场景下，到 github 提 issue 是我少有的方法之一(因为之前谷歌和文档搞的我简直殚精竭虑了)，还好官网比拟沉闷，而且对问题是切中时弊，激情而快捷的帮忙我解决了，那段时间我每天下班的第一件事就是要看我的邮箱是否收到了官网的回复。
2.3 官网社区
一些出名的开源技术都会有社区，社区通常都有沟通形式，其中有的沉闷有的否，但在机关用尽的状况，这也不失为一种路径。
开始经常在 github 提 issue，但因为官网是其余国家的，时区不同，所以我大多数都是第一天提问题，第二天早晨能力收到答案，有时官网忙，抽不出精力的时候，甚至好几天都得不到回复，再遇到周末根本须要等上 4 5 天，这对于我来说切实伤不起啊，但官网仿佛理解了我的窘境，在一次沟通中给出了另一个渠道：社区。社区页面提供了一些解决问题的形式：1. 退出 Discord server 2. Electron fiddle(提供最小 testcase demo 的工具) 3. Stack Overflow， 人不知; 鬼不觉又多了一些心愿，起初在解决问题的过程中 Discord 成为了十分重要的沟通工具，Discord 中有 Electron 独自的服务器，可能实时的沟通，这大大节约了我解决问题的工夫。
Discord
Electron fiddle
3. 问答社区
3.1 Stack Overflow
在等官网回复的过程中我也没有闲着，其中也上一些问答社区提问题，抱着侥幸心理，心愿能失去他人的帮忙，我找的第一个问答社区就是 stack overflow，因为我很屡次在这个平台找到答案，而且技术栈十分的 丰盛 ， 问答品质很高 ， 回复效率也是同样，首推，除此之外当然还有其余优良的问答社区和博客平台，就不一一列举了。
3.2 技术论坛
对于技术论坛，最好找最靠近问题的技术栈论坛，靠的越近越容易取得答案，而且要沉闷，很多社区一个帖子寂静良久，等他人答复了黄花菜也凉了。
4. 征询专业人士
如果上述还没有解决问题，那么找四周共事、敌人和技术群等大佬们帮忙也是一种方法，长于利于身边的资源，但须要留神的是：
- 不要遇到问题就问，一个是不要依赖他人，另一个是老麻烦他人欠的是人情，也不是所有人都毫无保留、乐于帮忙解答的。
- 要留神问人的态度和形式，肯定要问的有品质，你认真思考过这个问题，不要问一些网上到处的都是，这样有可能会让人感觉到不尊重。
- 认真演绎你的问题的形容，让他人可能了解，有时候线上不如先下交换那么不便，所以须要简短精确形容你的问题。
5. 查问书籍
在江郎才尽的时候，看看书兴许真的能帮你解决问题，在抉择书方面，尽可能看新出版的书，尤其是技术框架类，它始终在变，版本不统一遇到的问题和答案并不一定实用，总的来说，看书解决问题并不是很举荐，认为比拟耗时也不不便，并不是所有公司都容许你上班时间看书，看书作为学习和常识积攒还是十分不错的，书比拟零碎，纸质的货色对排汇的成果也很好。
我在解决 Electron 时也看了相干的书——《Electron 开发实战》，看这本书时，并不齐全是为了解决问题，其中百分之 60 是本身趣味 + 学习常识，但这本书的确帮忙了我很多，有意思的是在书中看到一个新个性，我会忍不住的去我的项目中找是否用了此个性，如果没有用那是否能够使用此个性做一些事件，这样人不知; 鬼不觉多看了代码，大家都晓得硬看代码是很难看上来的，同样的我在看代码的过程中看到了不懂的内容，又去翻书看看书里是否有解说，没想到人不知; 鬼不觉的把这个我的项目做了大半。
三、结语
综合以上的形式，给出一些舒适提醒：
- 学会演绎问题，不知哪位名人说过：问对了问题，就解决了问题的多半(残缺的不记得了😂)，很多人同样都在应用搜索引擎却有的找不出答案。
- 要把握一些罕用英文词汇和领有一个好的翻译软件，它可能晋升你看文档的效率，同时也不便跟老外交换。
- 给官网提问题要尽可能提供残缺的信息，最好有一个可运行且小的 testcase demo。
- 到一个问答社区提问题要留神标准，Stack Overflow 的代码格式化(第一次提问题的时候，搞了好几个小时)
- 问人要考究艺术(具体看文中 ” 征询专业人士 ” 章节)
问问题的艺术，最初给大家推几篇相干：
🌟 技术问答社区中答复的艺术？
🌟 如何向老师提出好的问题？
