今天讨论的主题是关於开发的过程中，问题要怎麽去思考和解决的小技巧，这些内容对於刚开始学习程序或者是新鲜人，可以有一些启发和建议。

备注 : 下述的内容不预设程序语言

为什麽问题会发生?

这时候如果有个资深的同事可以询问，并且参照他们的经验法则就知道怎麽排除这个问题，那如果没有人可以问的话该怎麽办呢，下述的内容会从问题点如何察觉、下完关键字後怎麽判断不同类型的答案对我有没有用。

网路上有哪几类的答案?

开发过程中总是会遇到程序错误的状况，而当下会看到错误的提示讯息，第一件事情会先看是哪一行出错了，接着到指定的行数检视。在现今网路发达的发展下，想要要做什麽事情就可以透过关键字搜寻，所以当知道程序的错误讯息之後，就是把这一些讯息看看搜寻之後的结果，依照搜寻之後的结果我大概可以分为几个观点，来了解找到的资讯要怎麽要解决问题。

复制贴上型答案

对於开发者而言Stack Overflow算是一个职场上的好夥伴，常常搜寻完的结果有许多的资源都是来自这个平台，网友除了会回答问题的解决方式外，也会提供sample code给询问者参考和测试。通常这个情境比较是在处理基础的功能(例如数值怎麽转换、怎麽传值之类的)，突然想不到这个语言的基础用法时，就可以透过这样的方式解决问题。

但虽然有一些答案复制贴上就可以执行，但也是需要了解为什麽程序码会这样写，以及这些代码有引用到哪一些观念，或者是这个答案有没有更好的写法，以此让自己在下一次再遇到类似的问题时，有更多的想法去寻找解法。

概念式的答案

上点提到的比较是大众式的问题，所以通常都会有程序码可以参考，但如果今天开发错误讯息找出来的结果都没有具体的程序码该怎麽办，有几点的搜寻方法可以给各位参考一下。

拆解错误的讯息

在一长串的错误讯息也代表这在描述一件事情，因此可以把不同的名词或者是动词搭配开发的程序码查询，看看基本的用法和意思是什麽。以过去的经验这时候如果整个框架或者是功能是自己写的话，通常看完名词的一些解释後，也会有一点思绪去推测是不是其他的地方功能写错的关系，导致连锁错误发生的情况。

如果上述提到的方法还是没有思绪的话，同样也是保留关键字和开发程序码，接着再加上你要做这件事情的叙述，例如要做xxx判断加上使用这个错误讯息名词，显示的结果可以看看有网友问的问题，在他描述的情况是否就是你开发时遇到的情况。

影片教学式答案

除了程序码的参考答案之外，越来越多的开发者会上传一些技术的教学影片，然後下面的梗图会看到影片教学有许多的印度人教你写程序(误)。这些资源如果是做类似的功能可以参考他们开发的过程，然而影片的好处就是知道一个功能从无到有的过程，但同样的还是要留意内容的程序码是否有其他的写法，只有手把手做过很快就又会忘记了。

至於要去哪里看教学影片，愿意付费的话可以去udemy选择相关的课程，但如果只是单纯想看其他人怎麽开发，那可以去Youtube下关键字也是有蛮多的结果可以查看，不过我会另外留意影片的留言，如果有人留言影片内容有许多的错误，基本上就不太会继续看下去(因为自己也还没搞懂功能xD)。

自己问问题

上述的资源搜寻了一轮还是没有答案怎麽办，最後的手段就是自己去社群提问，询问的管道除了Stack Overflow之外，也可以看开发的语言或者是框架有没有自己的论坛，或者是透过IT邦帮忙的技术问答也可以。

Google-Fu

刚刚说明了不同种类的答案之外，要如何快速找到想要的资源也是一门学问，以下的资源提供搜寻时的实用功能，以及当问题时需要怎麽拆解问题点的根源，逐步的找到最适合的答案。至於要下什麽关键字的技巧，进步最快的方法就是自己输入关键字，这个意思是说先通过自己脑中的想法去找答案，真的找不到的时候再请教同事，透过这样的方式可以更加知道下一次再遇到这个问题的时候，更快速的找到想要的结果。

备注 : 如果今天遇到的是现有的系统流程或者是资料流的问题，建议可以直接询问同事是否有规格书或者是相关的附件参考。

参考资源

凡走过必留下痕迹

除了知道怎麽下关键字搜寻资源外，除错我觉得是非常重要的一件事情，因为好的除错技巧可以增加开发的效率，减少因为Debug卡太久拖延开发时程的状况发生。个人刚开始开发程序的时候，很多时间看到错误的问题如果网路搜寻一轮找不到适合的问题时，会偏向是透过自己的想法去测去改写程序码，但很多时候测试的次数一多的时候就会花不少的时间。

把结果印出来

除错起手式就是把输出的结果显示在画面上，以Javascitpt为例使用console.log('讯息',变数)就可以检查输出的结果，另外今天是用C#开发的话可以使用Console.WriteLine()把结果印出来，透过这样的方式可以减少自己猜测和通灵的时间，掌握输出的结果去延伸思考问题解决的方法。

console.log参考来源
Console.WriteLine参考来源

断点下起来!

如同上述的标题提到的凡走过必留下痕迹，因此除了看到错误讯息之外，使用开发工具的侦错模式透过下断点的方式，检视错误的那行引用的类别或者是宣告的变数，显示的结果跟开发预期的结果是否有一样。

然後逐步把执行的过程每一个用到的Function下断点检视，确保这个错误讯息是执行的流程发生问题，还是单纯自己的疏忽发生的问题(大概有8成都是这个原因)，以过去的除错经验多次下来建议先从最小单位确认(意思指的是先确认变数的型态、引用的方法是否正确)，然後再拉大范围检查function间的执行情况。

Visial Studio Code Debugger
Visual Studio Debugger

额外补充

在第十天有提到Why Learning to Code is So Damn Hard的文章，如果现在正在下图的这两个阶段迷茫太久的话，在这次的系列文章从过去的实战经验内容，也许能够给正在阅读的你们，能够知道什麽情况下用哪种工具或是框架比较适合。另外确定了开发的框架後，今天的内容算是引导透过搜寻引擎，找到符合的答案或者是要怎麽找的建议後，就会有更多的信心和动力完成设定的目标。