程序员要多读一些专业之外的书

程序员要多读一些专业之外的书_第1张图片
图片发自App


作为程序员,你可能经常看一些编程类的书,这样很好,可以提升自己的专业知识。不过,抽空看一些其他领域的书籍或涉猎一些专业之外的知识,或许能获得不一样的思维方式。      


前段时间,我读了丹尼尔·卡尼曼的《思考快与慢》,心理学方面的书。他认为,人的大脑有快与慢两种思维方式。一种是无意识的“系统1”,不需要深入的思考,它能依赖人的记忆、经验等迅速做出反应;一种是有意识的“系统2”,它通过调动注意力来分析和解决问题。

人们往往喜欢并习惯于第一种方式,因为它不需要我们投入精力去思考,并能快速的做出反应。

程序员要多读一些专业之外的书_第2张图片
图片发自App


举个例子,对于一个开了十几年车的老司机来说,在熟悉的路上开车回家,在路上走个神,偶然醒过来,发现到家了。这就是在“系统1”的思维方式下完成的开车,它是凭借记忆、经验完成的,不需要过多的思考。

但如果是开在非常生僻的路上,他会时刻考虑路该怎么走,会不会走岔路,全程下来,很疲劳。这就是在利用“系统2”,它虽然耗费脑力,但往往能得出正确的结论。     


后来,我在写程序的UT测试用例时,看了看之前写的测试用例,读起来很吃力,每个case都很耗费脑力,读完一篇就感觉筋疲力尽了。

于是我开始思考,能不能把测试用例描述的更简单、直接,不需要过多思考就可以表述出需要测试的内容。于是想到了这两种思维方式,意识到应该使用“系统1”的思维方式来描述测试用例,让它更直观,更好理解。

比如:把描述“输入的字符长度达到50后,文本框将不可以再输入值,且只能输入0~9的数字”改为“最大输入字符:50,输入格式:数字”;

把描述“部门经理招聘编辑窗体关闭”改为“当前窗体关闭”等等。每一个信息点都需要耗费脑力去思考,所以一定要减少信息点,描述测试问题,不是越清楚越细致就越好,而是能直观的表达需要测试的功能点。

用这种方式,我很快的完成了测试用例的编写,领导看后很满意,还将它作了范本。        


做软件界面的设计也可以借鉴这种思考模式,不知道大家有没有注意到,现在的软件,特别是手机软件,界面中很少有冗长的文字,取而代之的是一些有意义的图标、图片,这样用户使用过程中,感觉很轻松,不仅外观漂亮,使用起来也更简单,不需要太多思考(利用“系统1”就能完成)。大大提高了用户体验。      

程序员要多读一些专业之外的书_第3张图片
图片发自App


同样的道理,我们在写代码时,是不是也可以借鉴这种思维方式,考虑怎样使自己的代码有更好的可读性、艺术感,怎样更有效率的完成代码,且便于维护…       所以说,多读一些专业之外的书,在专业领域往往也能颇有收获。

不仅如此,还可以拓宽自己的知识面,丰富自己的生活,也改变一下别人眼中,程序员的呆板形象。  

 

广读书,读好书,让自己的思考既有深度又有广度。

程序员要多读一些专业之外的书_第4张图片
图片发自App

你可能感兴趣的:(程序员要多读一些专业之外的书)