有时，碰到一些程序员会问：“我以前是做安卓的，现在想试着学下后端服务开发，觉得怎样？”。我一下就会卡住，不知该如何回答好。学习本是好事，但前面加个 “试着” 似乎感觉就不太好了。
好的出发点
“试一试” 的初衷本来就该是好的，它表达了一种好奇心，和尝试走出舒适区的勇气。
程序员这个职业，会带来一些习惯，我们经常性的会去尝试一些东西，然后看看它是否如我们预期般工作。比如，程序员的一项日常工作之一就是 —— 调试程序。调试，就是这样一种需要不断去试的过程。
在刚工作不久，我正在做的一个项目是一个客户端程序，程序包括一个后台任务线程去批量处理一些任务，另外还有一个 UI 界面，一个前台线程等待后台任务线程的处理结果通知，实时地在界面上去刷新重绘任务处理进度。这个程序会时不时的出现一个 bug，前台的 UI 界面不时地就死在那了，任务处理进度再也不动了。
当时，我花了很长时间一直在抓这个 bug。用的方法就是调试技术，但因为这是一个机率性出现的 bug，一步步调试反而导致从来也没出现过，但真正运行起来就总是偶然出现，让人抓狂。在这样的单步调试中，我就是怀着一种期望凑巧能碰到的心态，做了很多无用功也没能解决真正的问题。
这里真正的问题是，我不知道其实是我对于线程间通信的知识上出现了认知性盲点。我习惯性的用调试去找 bug，这就是一种 “试一试” 的技术，你的初发点（找到 bug）是好的，过程也是很艰辛的，但最终结果却是无用功。
后来，那时我正在读一本有关线程编程的书，读到某个部分时，关于这个问题的根源就突然让我恍然大悟了，这个部分正好弥补了我缺失的知识点。而我习惯性的调试方法，虽然有一个好的出发点，但最严重的问题是，我不知道我在调试什么，我没能定义清楚我调试的终点到底是怎样的。
那时的我就是一个刚进入编程领域的小白，喜欢调试，在看上去很复杂的调试界面忙忙碌碌，感觉很专业，而收获的仅仅是对调试器的熟悉程度。而且自觉不自觉的还养成了这种 “试一试” 的 “坏” 习惯。
模糊的终点
“试一试” 的 “坏” 字之所以打了引号，就在于它的出发点是好的，但如果终点是模糊的，那就 “坏” 了。
近些年来，出现过几轮的技术热。比如，刚进入移动互联网时大热但如今已经回归常温的移动开发、曾经大热现在略有降温的云计算与大数据、目前还在升温阶段的人工智能与机器学习。那么，到底为什么你会想去尝试一种新技术？难道没有被技术潮流所裹挟吗？
好些年前，移动开发还在升温阶段时，我也无可避免的被这样一种潮流所裹挟过。我开始看一些关于 iOS 开发的书，从语言到工具。尝试学习一种新技术并不是坏事，即使是被技术潮流所裹挟，但问题出在，这次尝试的终点在哪里？我是想转型成为一名移动开发工程师么？还是说我有一个想法，需要开发一个 App 来达成？亦或我仅仅是想学习了解下移动开发是怎么回事，提升下技术的广度理解与视野。
然而以上皆不是，当时的尝试完全没想清楚终点在哪？后来热度下来后，也就慢慢遗忘了，浪费了一些时间和精力罢了。如今，人工智能与机器学习又热了起来，我又开始尝试学习了解起来，但这次我把尝试的终点定义得很清楚。我不是想转型成为一名机器学习算法工程师，也不是因为它很热所以被潮流所裹挟，这次尝试的终点就是想搞清楚关于人工智能与机器学习三件事：
- 它的原理与应用
- 它的前世今生
- 它如今已抵达的边界
搞清楚这三件事，不会让我成为机器学习的专家，但会提升我对于这个热门技术的判断力。
试一试，需要有更清晰的终点。关于终点，可以从三个方面来考虑：
收获结果
定义清楚尝试这件事，到底能收获怎样具体的结果。比如，考试，尝试的结果就是要通过。
体验过程
有时候结果并不确定，比如，创业，结果未必就能成功，那么这样的尝试难道就没有意义了吗？有的，因为创业的超低成功率，所以，收获过程多于结果。
验证猜想
这个部分程序员就很熟了，编程中的调试其实最重要的目的就是验证猜想。引入一种新技术或框架，验证 API 的调用结果或运行输出是否如你所想，即使最终否决了，也获得了判断的依据与知识。
试一试，是走出舒适区的一次行动，但也不要胡乱尝试，得大致有个方向和期待。
...
回到文章开头，尝试下后端开发，这是一个好的出发点，但还没有定义清楚你这次尝试的终点。
网友评论