我们如何让程序员在编写自己的函数之前查找现有的函数？
为什么这么多人仍在标准库中编写蹩脚版本的东西？ 不是针对 PHP 开发人员，而是大家可以阅读 PHP SPL
Why are so many people still writing crappy versions of things in standard libraries? Not to go after PHP developers, but guys go read the PHP SPL
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
同行评审可以帮助发现这种情况。 如果您有另一个开发人员查看代码，并且他们不断找到标准库方法的实现，那么它应该无法通过审查，除非有充分的理由重新发明轮子。
Peer review can help catch that kind of thing. If you have another developer looking at the code, and they continually find implementations of standard library methods, it should fail the review unless there's a good reason for reinventing the wheel.
年轻、雄心勃勃的程序员喜欢自己解决每一个问题。 他们不需要臭图书馆。 年长、懒惰的程序员宁愿寻找现有的解决方案来解决手头的问题。
所以我的建议是：下次你雇用程序员时，选择在接待区睡着的老家伙。
大部分只是开玩笑。 答案是同行评审和教育。
Young, ambitious programmers like to solve every problem on their own. They don't need no stinkin' libraries. Older, lazy programmers would rather search for existing solutions to the problem at hand.
So my advice: the next time you hire a programmer, choose the old guy who falls asleep in the reception area.
Just kidding, mostly. Peer review and education is the answer.
更好的搜索技术。和特定领域的熟悉程度
开发人员如何检查他们不知道名称的函数？ 或者也许没有一个确切的内置函数来完成他们想要的事情，但他们可以使用一些东西来节省大量代码。 您需要能够为当前的问题找到正确的术语，然后您就知道要搜索什么。 最好通过阅读特定于您的问题领域的主题来实现这一点。 摆脱对特定资源的编码，花一些时间在您正在编码的领域......无论是零售、医疗、保险等。
Better search techniques. and Domain Specific Familiarity
How does a developer check for a function they dont know the name of? Or perhaps there isnt an EXACT built in function to do what they want, but something they can use to save a lot of code. You need to be able to find the right terminology for the problem at hand, and from there you know what to search for. This is best achived by reading topics specific to your problem domain. Get away from coding specific resources and spend sometime in the field which you are coding for... wether it be retail, medical, insurance, etc.
总结：假设是所有 FUBAR 之母
我从不熟悉框架概念的同事那里看到了很多这样的内容（天哪，他们抱怨“两种语言合二为一”），即：老 C++人们突然面临着 C# 开始从头开始重新创建哈希表...
显然，从这个角度来看，这种现象的很大一部分并没有摆脱旧的思维方式和习惯。 如果你到了一个新的环境，你需要学习新的规则。 解决从外部看这个问题的唯一方法是提供培训，无论是一段时间的结对编程还是更正式的培训。
对你的工具不熟悉会招致他人的蔑视。
Summary: Assumption is the mother of all FUBARs
I see this a lot from colleagues who are unfamiliar with the concept of frameworks (god how they complain about "two languages in one"), to wit: old C++ guys suddenly confronted with C# diving in head first to recreate hashtables from scratch...
Clearly a big part of this phenomenon from that angle is not stepping out of old mindsets and habits. If you're in a new environment you need to learn the new rules. The only way to deal with that from the outside looking in is to provide training, whether that's pair-programming for a while or something more formal.
Lack of familiarity with your tools breeds the contempt of others.
一个简单的编码风格文档可能会有所帮助，提醒开发人员有可用的库（可能列出一些首选库）并且他们应该熟悉它们。
有时候，你只需要提醒人们。
同行评审会有所帮助。
A simple coding style document might help by reminding the devs that there are libraries available (maybe list some preferred) and that they should be familiar with them.
Sometimes, you just have to remind people.
A peer review would help.
当且仅当您确切地知道自己在寻找什么时，PHP 才有详细的文档记录。 例如，您可以打开 Arrays 和 数组函数 部分，了解可以对数组执行哪些操作。 你猜怎么着，甚至没有提到 SPL。
PHP is well documented if and only if, you know exactly what you're looking for. For example, you'd open Arrays and Array functions sections to see what you can do with arrays. And guess what, there is not even mention of SPL.
在真正开始编写代码之前，您还应该鼓励进行研究。 我通常通过思考解决问题的方法来解决问题，然后尝试在标准库或任何其他库中找到可以帮助我解决问题的任何内容。 我想说，在某些情况下，一小时的研究可能抵得上几天的编码。
如果人们没有这样做，那么让某人询问他们解决问题的一般方法以及他们正在考虑使用哪些库函数/类可能是个好主意。 如果他们遗漏了一些明显的东西，请向他们建议。
You should also encourage research before actually setting out on writing code. I usually approach problems by thinking about a way to do it, then I try to find anything in the standard library or any other libraries that will help me out. I'd say that an hour of research in some cases can be worth days of coding.
If people aren't doing this, it may be a good idea to have someone ask them questions about their general approach to the problem and what library functions/classes they are thinking about using. If they're missing something obvious, suggest it to them.
我很快想到了两个原因。 首先，标准 PHP 库并不为人所知，并且文档也很差。 php.net 网站被广泛认为是该语言的最佳资产，但许多较新的内置类（例如 SPL、反射 API、DomDocument 等）只不过是没有大量上下文的方法列表。
但更重要的是，在（未发布的）5.3 之前的任何 PHP 版本中，似乎都没有默认提供完整的 SPL。 就采用而言，这是一个杀手。 通常，编写 PHP 代码的人无法控制将哪些内容编译到 PHP 二进制文件中。 这是由他们的网络主机和/或运营团队处理的，并且网络主机和/或运营团队与开发人员有不同的目标，并且不会安装附带的每个可选扩展。 这也意味着 Drupal、Joomla、Wordpress 等项目不能依赖到处安装的 SPL，因此它们不会使用它。
PHP“胜过”perl 的部分原因是一次安装即可满足您所需的一切。 可选扩展在成为基本安装的一部分之前从未被广泛采用。
Two reasons pop to mind quickly. First, the Standard PHP Library isn't WELL known, and suffers from poor documentation. The php.net website is widely considered the language's best asset, but a lot of the newer built in classes (such as the SPL, reflection API, DomDocument, etc.) are little more than a list of methods without a lot of context.
More importantly though, it looks like the full SPL never shipped by default with any version of PHP prior to the (unreleased) 5.3. This is a killer as far as adoption goes. Usually people writing PHP code don't have control over what gets complied into their PHP binary. That's handled by their web-host and/or operations team, and web hosts and/or operations teams have different goals than a developer and aren't going to install every optional extension that comes along. This also means projects like Drupal, Joomla, Wordpress, etc. can't rely on the SPL being installed everywhere, so they don't use it.
Part of the reason PHP "won out" over perl was a single install had everything you ever needed. Optional extensions have never become widely adopted until they became part of the base install.
很难回答的问题。 显然，同行评审会有所帮助，但适当的文档也有帮助。 您的项目是否有技术规范，您可以在其中规划要创建的类和接口？
如果是这样，团队中的其他人应该审查规范并指出可以使用现有代码的地方......
Very hard question to answer. Obviously peer review helps, but also proper documentation. Do your projects have technical specs, where you map out the classes and intefaces to be created?
If so, someone else on the team should review the specs and point out where existing code could be used...
同意培训和同行评审，但执行单元测试和代码文档应该有助于 NIH综合症:)
Agree with training and peer review, but also enforcing unit testing and code documentation should help with the NIH syndrome :)