我所说的精致是强调"小"而"精",面对复杂的问题进行拆分成很小的模块,然后每一个小的模块都做的极致.
单一职责和短函数
提到编程,高级程序员不得不提的设计思想,设计原则,设计模式和编程规范.
其中以面向对象为思想的设计原则有SOLID.其中S表示的就是 Single Responsibilty Principle(单一职责原则).
编程的工作当中,经常会遇到庞大的类,一个类可能有几百行,上千行的代码.请注意,这可能违反了单一职责原则.
单一职责原则强调的是一个类只为同一类actor负责.不能为不同的actor负责.这里的actor是指需求方.
举一个例子: employee 对象有三个方法,分别是保存(技术部需要),计算工资(财务部需要),计算工时(人力资源部需要)
class Employee {
public int save() {}
public int caculateSalary() {
int hours = reportHours()
...//
}
public int reportHours(){...}
}
同时计算工资还调用了计算工时的函数.然后计算工资.
有一天,人力资源部决定计算工时可以正常填报,工作了12小时,可以填报12小时,但是工资只算8小时,结果程序员只改了reportHours.上线后,人力资源的工时报表是正确的,但是给员工一天发了12个小时的工资,造成了工时的损失.
你问程序员为什么写到一个类里面,程序员说,因为都用到了Employee类的数据.
正确的解决方法就是根据不同的actor提供不同的服务类.
interface PayCaculator {
public int caculatorSalary(Employee employee)
}
interface HoursReporter {
public int reportHours(Employee employee);
}
interface EmployeeMapper() {
public int save(Employee employee);
}
单一职责原则,本质就是对类和模块进行拆分,粒度拆分的越细,直到单一职责,代码会变得更加容易维护.
除了过长的类,还有过长的函数,日常工作中我经常看到很多超长的函数,翻了好几页都看不到底,于是不得不上下翻动回顾前面写的是什么意思.后来我学习了设计原则之后,对函数的长度要求是IDEA超过一屏,因为超过一屏就需要上下滚动.
直到看了郑晔<10x程序员工作法>,郑晔对自己的函数长度要求是不超过10行,而我注意到IDEA的一屏是50行.由此可知郑晔对函数的精致程度要求有多高了.
高手和普通人的差距就在于粒度的差距,高手追求的粒度更细,每一个粒度和精细度都会做到极致,最终整体都会看起来很精致.
分而治之
人类的大脑不擅长处理复杂的问题,因此面对一些复杂问题的时候,往往会觉得手足无措,没有思路,最终引起长时间的焦虑.
其实既然人类不擅长处理复杂困难问题,那么我们就可以将问题简单化处理,一个很好的简单化方法就是任务拆分,分而治之.
拆到什么程度呢?把任务拆到不能再拆的粒度为止.
赚钱,本身是一个复杂的问题,我们束手无策,并且很焦虑.但是我们是能知道目前有哪些行业哪些工作是赚钱的.
我们要做的就是树立一个目标,然后对目标进行拆解,拆的越细粒度,越精细化越好.
评估好每一步,如果这一步不好做,继续进行拆分.直到不能拆分,然后用心攻克每一步.
下图就是一个郑晔老师关于登陆功能的任务拆分.
94f217310da9fe77e6739f3b15702cab.jpg
反思我在工作当中,往往没有这么小粒度的任务拆分,甚至没有拆分的步骤,就直接开始写代码,结果造成的工作效率低下,并且思路不清晰,代码需要反复修改.
任务拆分的越细粒度,问题往往会变得更加简单,复杂问题也迎刃而解.
不进行任务的超细粒度拆分是思维的粗糙和懒惰,会造成效率的低下.让自己的思维变得更加精致,可以大大的提升工作效率.提升你的成就.
精致不会穷
奇葩说有一个很有趣的辩题,年纪轻轻精致穷有错吗?
外表的精致不是今天讨论的内容.思维的精致则一定不会让我们穷.
多做1%同样也是精致的表现.
如果我们对目标拆分了很多步,并且每一步多做1%.
每一步都比别人多做1%.
1.001^365=37.78.
这么精致的你一定不会穷把.
网友评论