标签：获得 函数调用 问题 src 模糊 开放源代码 版本 而不是 存在
这些事儿我们都干过：比如趁妈妈不注意赶紧偷吃一块饼干；比如开车过急转弯不减速。那么，编程的时候我们也会有哪些“坏习惯”？
在学生时代，我们都知道抄袭是不对的。但在工作中，这方面的规则还很模糊。虽然有些代码块是不能盗用的——不要把专有代码拷贝到你的堆栈中，尤其是这些代码有标记版权信息。这种时候你应该编写自己的版本，老板付你薪水就是要做正事的。
但是当原始创作者想要共享代码时，问题就变得复杂了。这些共享代码也许放到了某个在线编程论坛上，也许它们是带有许可证（BSD，MIT）的开放源代码，允许使用一到三个函数。你使用这些共享代码是没有问题的，而且你上班是为了解决问题，而不是重新发明轮子。
大多数情况下，复制代码的优势非常明显，小心对待的话问题也不大。至少那些从靠谱的来源获得的代码已经被大致“检查“过了。
问题的复杂之处在于，这些共享代码是否存在一些未发现的错误，代码的用途或底层数据是否存在一些特别的假设。也许你的代码混入了空指针，而原始代码从未检查过。如果你能解决这些问题，那么就可以理解为你的老板得到了两位程序员共同努力的成果。这就是某种形式的结对编程，而且用不着什么高大上的办公桌。
在过去十年间，函数范式愈加流行。喜欢用嵌套函数调用来构建程序的人们引用了很多研究成果。这些研究表明，与旧式的变量和循环相比，函数式编程代码更安全，错误更少，而且可以随程序员的喜好任意组合在一起。粉丝们十分追捧函数式编程，还会在代码审查和拉取请求中诋毁非函数式方法。关于这种方法的优势，他们的观点其实并没有错。
但有时你需要的仅仅是一卷胶带而已。精心设计并细心计划的代码需要花费很多时间，不仅需要花费时间想象，还需要构建和之后导航的时间。这些都增加了复杂性，并且会花费很多的时间与精力。开发漂亮的函数式代码需要提前做计划，还要确保所有数据都通过正确的途径传递。有时找出并更改变量会简单得多，可能再加个注释说明一下就够了。就算要在注释中为之后的程序员致以冗长而难懂的歉意，也比重新设计整个系统，把它扳回正轨上要省事得多。
标签：获得 函数调用 问题 src 模糊 开放源代码 版本 而不是 存在
原文地址：https://www.cnblogs.com/developer2020/p/12121234.html
