总的来说,我从事编程工作已有大约8年的时间,在我看来,我越来越依赖开放源代码库和代码片段(该死的GitHub!)来“完成工作”。我知道我可以及时编写自己的实现,但我希望专注于总体设计。
这是正常情况(非公司环境)吗?如果我的“编程”仅是将不同的库粘合在一起,那会出什么问题?
我知道“不要重新发明轮子”,但是当您不再发明一个轮子时会发生什么呢?
总的来说,我从事编程工作已有大约8年的时间,在我看来,我越来越依赖开放源代码库和代码片段(该死的GitHub!)来“完成工作”。我知道我可以及时编写自己的实现,但我希望专注于总体设计。
这是正常情况(非公司环境)吗?如果我的“编程”仅是将不同的库粘合在一起,那会出什么问题?
我知道“不要重新发明轮子”,但是当您不再发明一个轮子时会发生什么呢?
Answers:
使用库而不是重新发明轮子:太好了!这就是每个人都应该这样做的方式。您没有报酬去做已经做的事情。
使用代码段:只要您了解复制粘贴的内容,并且只要花时间使所有内容保持一致(而不是使用不同样式和方法的拼凑而成),则没有任何问题。
好的程序员编写好的代码;优秀的程序员窃取了出色的代码。
Good artists copy, Great artists steal
。
实际上,编码是最低级别的编程。您可以获得的抽象层次越高,您的程序员越好。与自行编写所有内容相比,选择正确的库(不一定是开放源代码的库),将它们正确连接在一起并维护结构很困难,但效率更高,而且省时省钱。
我喜欢写自己的库。我也喜欢按时完成我的项目。我认为随着时间的流逝,大多数优秀的程序员都会积累有用和可重复使用的位的集合。我不了解您,但是每次使用五年前编写的库时,我都会感觉很好。
有绝对没有错误使用经过测试和喜爱随着时间的推移库代码。您知道它是如何工作的,可以依靠它的复杂性并可以快速实现它。
话虽如此,我假设您了解库中的代码。我假设,如果有足够的时间,您可以实现类似质量的东西。
我知道一些非常优秀的C程序员可以实现标准C库,其中一些仅仅是作为学习/提高技巧的。我在业余时间获得的最大乐趣是使用HelenOS中的C库。
因此,只要您继续好奇并学习,使用库代码就没有错。不用说,除非您使用它是为了理解它的工作方式,否则不要使用您不理解的代码。
在这个问题上,我会比其他人做得更好:我什至不认为库的“客户端”开发人员不需要“理解”该库中的代码。
我是一个(相对于某些)相对较新的iPhone开发人员。我每天都会使用很多无法依靠自己生成的库,而这些库的代码已经让我望而却步。丝毫没有关系:
1)我完全了解这些库的接口(我是ASIHTTPRequest忍者!)
2)我选择的是通用的,用途广泛的库,因此我可以确定它们已经被彻底研究并解决了问题(例如:ASIHTTP,Stig Brautaset的JSON库,Facebook的obj-c库等。)
3)失败#2,这很简单,我可以选择通过它进行查找和修复/自定义需要查找/修复/自定义的任何内容。
我敢打赌,#2将成为其中有争议的部分。事实是,我依靠的是开放源码社区,这是一个肯定比我更有经验并且很可能更聪明的开发人员社区。但这就是开源的全部重点。所以,你去了。
我想警告使用库。作为Perl R(以及Java中的Java)中科学图书馆的经常用户,我经常不得不闯入一个图书馆以避免繁琐的管理费用。使用库很不错,但是越来越多的库本身依赖于其他库,这会调用使用标准库的第三个库来完成一项相当普通的任务。并且过程的每个步骤都需要对输入和输出进行一些检查。这些检查中有很多是完全多余的,但它们仍然对应用程序造成负担。当用于循环中时,可能会开始很重。
紧接着,您不能确保库始终保持向后兼容,或者不包含错误。实际上,所有库都包含一些bug,这就是代码的本质。因此,您对库的依赖程度越高,您在代码中输入的潜在错误就越多。而那些错误,如果不再次侵入库中就无法轻松解决。
使用库是一个非常明智的决定,但是当且仅当您非常了解库及其行为时。
我知道,思维伤害和计算机便宜,但仍然如此。不思考会伤害更多人。
代码重用是一个非常好的主意。它减少了冗余并提高了可维护性。
标题表明您正在将代码用作库,但问题文字表明您可能正在将源代码复制到新项目中。我会尽量使用其他开发人员的代码作为库。
如果代码不正确或以某种方式损坏或基于与您的应用程序不太匹配的模型,则会出现问题。在这种情况下,与尝试了解为什么以给定方式编写代码相比,从头开始擦除或部分或全部代码可能更简单。不过,请保留其他代码以供参考;您可能会遇到不确定如何解决的问题。其他开发人员可能也遇到了相同的问题,值得一看的是他们如何解决它。
合法地重用代码几乎没有缺点,也有两个很大的缺点:
否。程序员应该使用已经存在的库。无需重新发明轮子。如果您有更好的方法,则可以这样做,否则它在编写相同代码时的实际作用是什么。唯一的事情是您应该知道代码是什么(并且仅在重要时)。
除了其他答案中的原因外,不使用代码(只要它很适合您的问题)也可能被认为是不道德的,因为:
请记住,这两者都很难事先确定。
另外,请参阅“ 此处未发明”,通常称为anit模式。
为了完成目的,请允许使用反参数:http ://web.archive.org/web/20150326134617/https: //michaelochurch.wordpress.com/2015/03/25/never-invent-here-the-even-worse此处未发明的兄弟姐妹/
我称之为“从不在这里发明”(NeIH)的心态。以这种心态,外部资产被高估并且通常被隐式信任,从而使工程师花费更多的时间来适应现成资产的怪癖,而花费更少的时间来构建自己的资产。
总有一个平衡点。
除非绝对必要,否则我不使用库。依赖关系限制了可移植性和寿命。我从事软件开发已有34年,并且希望我的程序中至少有1个可以持续3年以上而不会被侵蚀(更改)破坏。
COM(组件对象模型),是17年前的答案,从理论上讲很棒,在实践中实际上不是可疑的,可重用的组件,我只会使用非常基本的组件,而且必须使用。
API和SDK使用不多。如果我分解一下我实际从库中使用的代码行数,花在使它们工作与编写代码上所花费的时间,我认为这是一种洗礼。我完全放弃使用SDK,这是非常麻烦的。
框架:Zend,Silverlight,WCF,.NET,分层系统,是的,它们可以加快初始开发的速度,但是当我达到极限时,花时间修复这些漏洞,就是不值得的。他们几岁了,他们不受侵蚀吗?
我仅使用我的库就使用过JavaScript和HTML。我仅使用最常见的语句类型精简了JavaScript。我希望在十年内我能写些能持久的东西。