2024年Python 函数库 APIs 编写指南_python中apis(1)，2024最新大厂Python面试集合

一、Python所有方向的学习路线

Python所有方向路线就是把Python常用的技术点做整理，形成各个领域的知识点汇总，它的用处就在于，你可以按照上面的知识点去找对应的学习资源，保证自己学得较为全面。

二、学习软件

工欲善其事必先利其器。学习Python常用的开发软件都在这里了，给大家节省了很多时间。

三、入门学习视频

我们在看视频学习的时候，不能光动眼动脑不动手，比较科学的学习方法是在理解之后运用它们，这时候练手项目就很适合了。

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

简洁性

在 README 文件中写入简单的客户端代码。

例如：Pendulum 的 README 文件就是以简单的用户代码开始的。

减少冗余的代码：数一数从第一行开始到你真正调用 API 函数的行数。

例如：与 Request 库相比，进行 HTTP 请求时 urllib2 库就很多的冗余代码。

使用案例

例如：这个网页展示的内容：https://python-social-auth-docs.readthedocs.io/en/latest/use_cases.html

在实践中逐步完善：实用且明智的缺省值设置

- 具有缺省设置，并根据最常用的使用情况来设置缺省值。

• 设置参数位置，将最常用的参数放在前面，将相似的放在一起。例如：JavaScript 的 history.pushState 函数的默认参数顺序是：state, title,  URL。然而很多用户仅仅想要将 URL 添加进历史值中，但是实际的情况却迫使他们不得不设置 state 与 title 参数的值。

不要将源代码片段复制粘贴进你的 API 中。

避免麻烦的输入：

• 检查是否存在参数名歧义的情况。例如在 Scrapy 1.2 中，send 方法有一个 to 参数，接收的是字符串列表。如果用户传入一个字符串，这个方法就会遍历这个字符串，并将每个字符当做一个邮箱地址并发送邮件。在 Scrapy 1.3 中则修改了这个 Bug，修改后即可以接收字符串，也可以接收字符串列表。

• 检测是否只是为了调用 API 就实例化某些东西的情况。如果存在，可以考虑接收封装值。例如：对于一个仅接受类文件对象的函数，如果用户想要调用它，就不得不使用StringIO  模块。

• 检查是否可以使用内置类型来替换自定义类型。或者两者都支持使用。

坚持最小惊讶原则（ Principle of least astonishment）：如果一个函数特征很让人吃惊，或许就应该考虑重新设计它了。

• 程序默认的行为是用户所期望的吗？

• 程序默认的行为是否符合用户对于程序性能、副作用，安全性，可靠性，安全性以及限制条件的要求？

要做到抽象

• 让用户不需要关心问题是怎么解决的，而是关心要解决什么问题。例如：为了完成一个简单的工作，项目开发人员不必过于在意任务序列、消息破坏，序列化等操作，他们只需要使用@aap.task  这样一个装饰器即可。API 关注的是任务的定义而不是完成任务的过程。

• 检查 API 中是否包含了不应该有的东西，牢记，要小心所谓的“抽象漏洞定理”（ The Law of Leaky Abstractions）。例如：RPC（remote procedure call）就是一个很好的反面教材，因为它将远程资源当做了本地资源进行抽象处理，但实际上远程资源的处理不同于本地资源。

像点 Python 的样子

• 努力向常见的 Python 习俗靠近，使你的 API 调用看起来就跟 Python 内置的 API 一样。例如在 Python2 中，ConfigParser.get 接受一个 section 参数和一个 option 参数。但是这个并不符合 Python 习俗，在 Python 的字典（dict）对象的 get 方法中，我们接受的是 key 参数 和一个缺省参数。在 Python3 中，这个问题得以修复，此函数的参数输入就类似字典那样了。

一致性

命名问题：你 API 中的命名是否和 Python 的习俗保持了一致性？我们命名应该与 PEP8 中所给出一致。PEP8 是 Python 官方的代码风格指南。为了保持命名与代码风格的一致性，建议使用 flake8 来规范你的 API 代码。

命名问题：API 中的命名是否一致？

• 术语的顺序：string_encodeVSdecode_string

• 缩写问题：activate_prevVSfetch_previous以及bin2hex  VSstrtolower

• 是否带有下划线：gettypeVSget_class

• 单复数问题：values_list  VSvalue_list

• 正负问题：button.enabled == TrueVSbutton.disabled == True

空值问题：在空值意义的定义是否一致？目前的是最好的选择吗？

• 决定下面哪个代表了空值：None、False、[]、‘’、0

• 小心一些出人意料的值：bool(datetime.time(0)) == False在Python3.5以前是这样

参数问题：在参数的顺序上是否具有一致性？例如：datetime.datetime(year, month, day, minute, second, microsecond)vsdatetime.timedelta(days, seconds, microseconds, milliseconds, minutes, hours, weeks)

行为问题：在相似或者不同的行为上是否具有一致性？行为的不对称应该反应在格式的不对称上。例如，numbers.sort() VSsort(numbers)

灵活性

减小整体的不连续性

• 检查所有的类的功能是否单一职责？如果不是，就应该把那些类拆解开来。例如，一个从缓存中获取数据的类应该将其连接缓存服务器的步骤交给另一个类做。

• 检查函数的名称中是否包含了and 或者是否包含多个操作。如果确实如此，应该将这个函数拆成多个不同的函数。但是，如果这个函数经常被调用，那么可以保留一个结合了众多函数的函数。例如：print_formatted 函数可以被拆解为两个函数：print和formated

• 检查是否存在用户复制粘贴代码以改变函数功能的行为。应该提供代码重构，回调功能。

• 检查在函数内部是否使用了属性值，如果有可以使用 get_something 方法代替。例如在 Djando 的 REST 框架中， CursorPagination 这个类仅仅支持一个固定大小的属性值：page_size，其原因就是这个类没有get_page_size 这个方法。这个问题再后来就通过上述方法解决了，即添加了 get_page_size 方法。

• 尽量避免隐藏可能有用的参数。例如我们的 API 中调用了另一个低级的 API 但是却没有展示这个低级 API 的参数情况

• 返回用户可能需要的一切信息

• 用户调用 API 时，要处理用户可能需要所有情况

• 在进行 API 测试的时候要测试每一个mock.pathch。虽然在程序运行的时候有一些东西不容易修改，但我们可以通过设置参数来修改某些东西。例如，Python 的内置函数 sched.scheduler接受两个参数timefunc 和delayfunc。而我们没必要对 time.monotonic和time.sleep 两个函数进行 mock 测试，用户会根据自己的需求进行相应的改变。

建立抽象

• 按照底层实现的结构，去封装我们的函数成员与对象。例如 Beautiful Soup 就为多个分析器设计了同样的 API 结构。

感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的：

①　2000多本Python电子书（主流和经典的书籍应该都有了）

②　Python标准库资料（最全中文版）

③　项目源码（四五十个有趣且经典的练手项目及源码）

④　Python基础入门、爬虫、web开发、大数据分析方面的视频（适合小白学习）

⑤ Python学习路线图（告别不入流的学习）

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！