为什么新手程序员似乎回避图书馆？
我注意到很多新问题可以通过库来解决。 当build议一个图书馆时，他们通常会回应“我不想使用X图书馆”这是学习曲线吗？ 要么 ？ 只是好奇！
很多新程序员仍然在低度抽象的工作中学习交易。 这是每个人都必须经历的事情。 可以这么说，需要一段时间才能“向上移动”。
一旦程序员意识到他们大部分时间都是像别人那样解决相同的问题，而目标是实现“商业价值”，那么他们才能真正体会到好的图书馆所带来的价值。
当你还在学习一种新语言的来龙去脉的时候，也不得不学习如何使用第三方库，看起来工作太多了。 此外，图书馆往往被logging在案 – 或者至less有一些文件对新的（呃）程序员来说是完全不透明的。
所以，在试图解决问题X时，说“用图书馆”听起来很像“解决问题然后问题x”。
（而且，他们的教授们告诉他们不要，虽然我的C ++本科生没有学过STL，但我还是设法得到了，男孩，是否做了我的面条。）
有些人遇到问题时，会想“我知道，我会用图书馆”。现在他们有两个问题。
认真的说 – 对于一个新手来说，这是一个合理的方式，已经被新的语言，编程环境，范式，击键等所淹没，以对使用库的build议作出反应。 如果你有一个解决scheme，但它不工作，有很多潜在的错误来源; 通过他们sorting是一个挑战。 添加到他们可能看起来不合理。
“使用图书馆”是指find图书馆，下载它，将其安装在您的项目中，并调用必要的function。 不难，如果你习惯了（而且没有公司政策，而且你有理由相信供应商，而且库本身具有最小的依赖关系等等）。 但是，如果对你来说这些都是新鲜的，那么当你提出一个编程问题并获得一个系统configuration的答案时，它可能看起来是无益的（即使事实上并非如此）。
几乎总是因为他们的教授告诉他们他们不能。
有时只是因为他们想自己学习，但我会说这很less见。
这是学习曲线。
使用库可能是学习程序员可以做的最糟糕的事情之一。 他们不是学习如何编写代码，而是学习如何使用其他人实现的特定API。 我并不是说每个程序员都必须了解他们使用的每一件事情，但知道计算机细节（数字逻辑，组装操作码等）的程序员通常比已经开始的人有优势像Java Swing之类的东西，只是扔在一起的图书馆。
在生产中，这当然是另外一回事了。 但我认为最好的教育方式是至less“一劳永逸”。 从头开始编写我自己的Web应用程序框架，确实提高了我的编程能力和抽象能力。 如果有人雇用我来构build他们的应用程序，并不意味着我会使用这个框架，但我知道“巨人”框架使用的背后的优点，缺点和原因，它可以帮助我select一个特定的框架对于特定的情况。
我记得几个图书馆之所以回避，是因为我想看看是否可以创build自己的algorithm。 我不想放弃，让别人为我做这些工作，而是想从我的错误中学习。 一旦我拿出一个解决scheme，我很高兴，我看着图书馆。
所以对我来说，只是想看看我能不能做到。
我总是有这样的冲动去做，但是有时我会看到我自己的局限性。 就在最近下载了一个库来创buildPDF文档，但这是我记得的唯一时间。
至less对我来说，（试图）自己做事，是我学习的方式。
我的印象是，许多新手程序员如果要使用别人的图书馆，就不会认为自己的工作。
我不认为这是一件坏事。 使用库是伟大的; 它节省了时间，精力和错误等等。然而，在这个过程中你学到的东西很less，对于新的程序员来说，学习是目标。 为了回答这个问题，我认为他们往往会因为不习惯使用它们，或许他们不知道它们存在而偏袒图书馆。
对于许多文档记载不佳的图书馆来说，这些图书馆可能松散地实施，或者使用的语言不能很好地控制遏制和知名度，所以猜测图书馆应该如何使用是相当困难的。
在使用了一段时间之后，你已经习惯了这些怪癖或者阅读其他源代码，它们教会了你正确的方式。 但在此之前，使用一个糟糕的拼凑/devise的图书馆可能会非常令人不快。 （甚至是一个devise良好的，没有非常好的logging）。
如果您没有图书馆的源代码，那是另一个问题 – 您无法控制程序的运行。 现在这种情况更为罕见，但在购买图书馆的情况下仍然会发生。
大部分要点（对我来说主要的是学习曲线），但我认为另外一点是起作用的：
因为学习一个库比自己编写相同的function更令人兴奋。
更多的图书馆=可计费的小时数。
我认为需要投入大量的时间来理解图书馆的目的 – 是的，学习曲线，但更多的是，新手程序员可能不知道他们需要什么，直到他们有更多的经验。
因为它很有趣。
因为作为开发人员成熟的一部分正在学习快速识别可以由图书馆或现有解决scheme解决并需要个人关注的问题。
当你试图学习如何做事情时，任何时候通过调用AwesomeClass.doAwesomeStuff（）来“神奇地”完成某件事情，你最终会放弃一部分控制权。 当你是“新人”，不知道你给的是什么，或者为什么会让人不安。 这是我第一次学习时对Rails的主要打击。 所以很多事情只是“工作”，我不知道为什么没有通过大量的Rails源（我通常没有时间做）。
至less，这是我的承担。
同样的原因，更有经验的开发人员 –
因为学习如何使用一个图书馆来编写它的一部分通常是很难的，所以你需要你自己。 至less你可以理解它是如何工作的，当它没有达到你所期望的。
一位经验丰富的开发人员只有在了解如何使用库的经验，更有可能考虑它。 缺乏经验的开发人员还有一件事要学习
我是程序员，而不是心理学家！ 🙂
对我来说很久很久以前，但那是因为我想学习和体验。 我不想用我不明白的东西，所以如果我不认为我理解了这个图书馆，并且可以自己编程，我就尽量不使用它。 也可能有一些恐惧， 编程给你一种控制的感觉，使用库就像是放弃了这个控制。
从一个noob的答复 – “我不知道如何使用图书馆，甚至如何访问它们或如何工作”
图书馆往往会学习一些API，这是范例。 它可以很快变得复杂，我可以很容易地理解，初学者会喜欢更舒适的地方。 根据我的经验，我发现大多数库和框架似乎在抽象一些繁琐的例程方面做了很大的工作，但是当我需要扩展这个function，或者以一种无意的方式使用它时，它可能是less数。
我认为这是“练习完美”的东西之一。
那么，新手的目的可能比解决scheme更能解决问题。 也许他们真正想要做的是弄清楚如何解决这个问题。 我的意思是，如果他们仍然处于学习阶段，那么很可能他们不想要简单的答案。
我认为教授们希望他们坚持基础。 当我gradle于本科gradle时，我知道C ++，Java和其他一些语言，但对于公司中使用的图书馆和框架毫无头绪。 这就像你知道java ..是..你可以写一个servlet ..没有。
对于速度恶魔来说，他们很less使用第三方库，而新的程序员通常都希望尽可能地缩短他们的代码速度。 我认为，如果他们不能控制他们的代码，他们不能得到他们正在寻找的性能。 至less这就是为什么我第一次开始编程的时候避免了图书馆。
我记得编写我的第一个DAL，并避免在networking上的所有其他免费的图书馆，因为我想我的代码以最快的速度执行。 后来，我发现通常它不是代码实际上就是数据库。
一些开源库是有问题的，或者不如其他开源库。
在我看来，另一个因素是额外的库增加了复杂性。 程序越来越难以理解，越来越复杂时越来越难保持和缓慢。 我认为特别是新程序员回避图书馆的原因是添加库代码比增加自己的代码增加了更多的复杂性 – 仅仅是因为理解图书馆的工作方式仍然没有把握。 所以这似乎是一个技巧和心理问题。
我认为更多的基本问题可以被视为使用现有图书馆的一种遏制因素。
- 作为“新手程序员”的一部分是缺乏对图书馆的接触。 如果你不知道他们存在，你怎么知道使用它们？
- 可用的选项数量。 假设我真的有兴趣了解更多关于MVC的知识，但是如果我必须在cakephp和smarty以及zend之间进行select，那么您可以很快看到这些齿轮的工作方式，以便在不花费时间进行实验的情况下发现一种实现目标的方法。 看看Freshmeat或SourceForge，以更好地了解可用的图书馆的艰巨select。
- 可疑的支持与图书馆粗略/过时的文档相结合。 我想使用这个可能不再有用或者将来可能会被遗弃的工具吗？ 一个项目很可能会发展，对于一个图书馆的项目也是如此。 它的用处是否会持续到我的项目的一生，还是会被要求重新做这个工作？
使用库需要你理解库的相对复杂的devise，这是新程序员可能没有掌握的东西，因为他们所写的都是简单/程序/单一目的的代码。 例如，对于一个有经验的程序员来说，像模板方法这样的标准devise模式，观察者和命令看起来相当明显，但对于新手来说，它们看起来像是魔法和/或不必要的复杂性。 对于我来说，转折点是当我有足够的能力去devise模式并编写一些基本的可重用代码时。
现在已经很长时间了，但是我大学gradle时，对图书馆一无所知。 这是在大型机和微型计算机的日子。 我们学院有一个VAX，pipe理人员对学生进行黑客攻击，所以不让我们看图书馆的手册。 所以，当我第一次上大学的时候，我甚至没有想到图书馆可用。
我相信新手不想使用新库的原因有很多。 但是如果你有足够的时间，那么这不是一个好的机会，向他们展示使用这个库的好处是什么？ 和我一起工作的人，我通常会提供一个为什么比他们的方法更好的例子。 它帮助他们学习和成长为程序员。
Noobs会在不知情的情况下使用Lib ，但是当它们必须导入/添加一个文档相当less的文档时，就会有一种对未知的恐惧 。 这主要发生在编译的langs上！
在解释的（或编译的IRT）中，主要是当有一个控制台时，这种恐惧几乎是不存在的 ; 因为您可以要求并查看是否失败，请调用方法并查看返回结果。
控制台是勇敢的工具！
