感觉科研陷入了一种在纯空想的状态，明明软件工程是为了解决软件开发过程中的各种问题，但实际上大部分从事软工领域的科研人员并没有足够的开发相关经验，甚至缺乏相当的写代码的经历，这些人（包括我自己）是如何能够找到所谓的痛点，发现新的问题和场景呢？简单地通过到开源社区里面浏览开发人员的各种互动产生的各种 discussion 与 artifacts，再加以自己浅薄的了解与分析，我们就能够真正认识到在开发过程中尚存在什么需要解决的重要问题吗？
为什么需要去寻找这些新的问题场景？从个人感受来说，发文章的工作无非是两种方向：
- 寻找并定义新的问题场景。自己定义的新问题只要没有人做过，并且能够把这个问题的重要性讲好，基本上没什么问题。解决好了，是可以是开山之作，即使没能很好解决，也可以说是先把问题抛出了引发大家注意。
- 对已有问题的更优新方法。通过对已经存在并有人研究过的方法进行继续研究，试图创造出性能更好，开销更小的方法。
通常来说，第二种方向往往需要有着更高的技术积累要求，因而可能更难，需要的时间周期也更长。所以像是硕士等短周期科研工作者（如我）往往会更倾向于第一种方向。于是乎最近在寻找新的工作方向的我就在一直想新的问题，不断地在重复以下流程
- 在 GitHub 上面浏览一定数量 issues 并选择记录
- 根据这些记录归纳总结可能可以做的问题
- 把这些问题拿去讨论，然后逐个被告知已经有人做过或者很难做出来
- 然后重新回到步骤 1
想起大四刚接触科研的时候就有过一个疑惑：
好奇做 empirical study 的人是如何在没有某一个领域，某一个方面的专业知识，却能够对此做出深入而专业的分析。像 empirical study on bug，一般来说，做的人也并不是就研究这个方向的，就如 bugs in machine learning，研究人员也不是做 machine learning 的，但也还是能做出看上去还挺专业的分析，虽然涉及到的 machine Learning 的概念其实比较少。就像我现在做 llvm toolchain bug，我一没有接触过 llvm，工具链也不知道是啥，由我来做的分析真的可信/有价值吗？当前阅读 bug report 都有点吃力。 如何解决？想到两个点。一个是合作，每个人精通一方面的知识，通过合作获取意见，轮流充当 expert/data collecter/analyzer 的角色。另外一个是快速学习入门，但这个其实比较虚，不过其实做分析需要的水平其实也不是很高？
我们研究软件质量，会选择某些特定类型的软件来进行研究考察，但事实上我们并没有在这一类型或这一领域中有着深厚的专业知识，所以我们该如何对其做出深入而专业的分析，又或者说，为什么这类工作不交给领域相关的开发人员来负责其质量。也许是我们这也有着通用的，可以补上领域知识缺失的屠龙方法吧（当然可能合作更为关键）。
所以到头来好像也没想出个什么结果，越想反而越加劝退自己了