简述
对于一个已经确定的需求, 实际上, 逻辑上已经没有多少自由了(当然还是有的), 我们所享有的自由, 大致只有以下几项了
编程语言留给程序员的自由:
- 函数的体量和位置
- 模块/类/函数/变量的命名
- 表达逻辑的方式
程序员可以使用这些自由做什么? 表达思想, 编程语言提供的规则, 可以让人从数学的角度解决需求, 但是, 如何优雅的解决需求, 关键在于使用好这些属于我们的自由
示例
函数名和变量名的自由
获取用户的last_name
- 简单的逻辑表达
def a(b):
c = b.split('.')[-1]
return c
- 加上业务含义
def get_last_name(full_name):
last_name = full_name.split('.')
return last_name
- 因为函数名中有"last_name", 所以, 不需要在函数体内再声明一个变量去表达业务含义
def get_last_name(full_name):
return full_name.split('.')
- 因为这是一个"工具类"函数, 所以可以加上type hint
def get_last_name(full_name: str) -> str:
return full_name.split('.')
ps: type hint 的好处:
-
形参(full_name)的对象方法可以被只能提示
-
使用函数的时候会提示函数接受什么类型的参数
-
使用函数时, 函数返回值的对象方法也可以被提示
现在, 越来越多的人开始崇尚"clean code", 但是, 我们要明白"clean code"的核心思想, 就是要在编写代码的时候考虑到需要阅读代码的人的感受,
实际上, 编写代码的时候, 你手中掌握的所有自由, 都是你增强表达能力的助力, 如何运用好这些自由, 就是"clean code"的核心思想,
函数的位置和体量
同样是一个数据处理函数, 位于不同的位置, 给予使用者的含义就不同, 这一点, 在"类和方法的关系"上表现的尤为明显, 面向对象的语言, 提供了类
的概念, 类可以为我们提供代码复用策略, 类下的方法可以被继承(复用全量), 继承+覆写(局部改写后复用了其余的部分), 多继承(合并两部分的代码)等, 抛开这些不说,
类名和方法名之间本身就存在"父子关系", 我们会在使用某个类的时候, 猜测正在使用的类下具有什么方法, 也会在调整业务逻辑的时候, 猜想到要修改的逻辑位于什么位置
这些都是类名, 方法名所具有的对于表达业务逻辑的助力, 模块与模块下所归属的函数名也是同理
比如, 你熟悉了django rest 的 MVS 设计模式的话, 就很容易知道下面的场景到哪里去修改逻辑
- 将平均分取近似值,保留两位小数(S)
- 给予前端的json数据中增加平均分字段(这一定是一个聚合函数的返回值, 对吧?)(V)
- 从现在开始, 要存储所有教师的生日进数据库(M)
这些清楚的业务表述, 使得编写代码和使用代码的人之间能够达成共识, 创造出健康成长的代码
逻辑的表达方式
关于逻辑的表达方式, 实际上在需求确定之后, 留给我们的自由并不多, 下面是一个示例
class StudentView(APIView):
def get(self, request):
pass