在2023年12月末的时候,我开始跟随老师做一个项目,是从零开始的。这是我的第一个项目,一开始的时候需求少,功能少,工作量也小,我对类的管理毫不在意,经常是想到什么名字用什么名字,但是后来,我遇到了各种问题,也看了一些前辈的文章,心态慢慢发生了改变
因为第一点 :从数据库到业务到返回给前端的json数据的格式,全都是我制定的,很多东西我也能记得,所以起的乱七八糟,也不影响我codin
第二点:前期代码都是一次过的,所以写完我就不管了,当时确实能处理。
第一次转变就发生在,之前写好的一个功能里面,需要临时加一个小小的需求,于是我就去维护之前的代码,这个时候我才发现我之前乱起名的坏处:我自己都不记得这个方法,这个类是干什么的了,也不记得这个变量代表什么含义,所以维护几个需要改动的方法时,我确把整个功能的代码又复习了一遍才能获取到有用的上下文来确定待改动的方法哪里需要改动。于是乎,在后面的项目中,我尽量的做到见名知义。
但是这只是一些稍稍的转变,我对命名这门学问,了解的很少,更不知道它就是计算机科学仅有的两个难题之一...
时间来到由于项目代码日渐庞大,需要一名专门的前端同学进行对接的时候,这个时候,项目再一次暴露出命名不够规范的问题,但是并不是上一次不能见名知义的问题了,而是参数单位的问题。当时的前后端传数据的时候,涉及到对时间进行操纵,但是很多地方又没有指明单位,不知道是seconds,millseconds,还是minute,搞的前端同学天天来问我,我被弄烦了,开始思考这个现象,才发现,这原来是我的问题。于是我将ParseTime()方法改成了ParseSeconds(),将showTime方法改成了showTimePatternString()方法,同时通过一个常量pattern进行字符串格式的控制
最后一次改变来自于我的老师给我看的一段视频,在b站上:《代码美学,在代码中命名》,其中提到了一个观点,命名不好搞,不是词汇量的问题,是代码结构的问题,接着他使用了了一个用设计模式改造代码的例子,将整个代码变得易于理解了许多,当时我便觉得,真是醍醐灌顶,原来真是语言观决定世界观丫0.0
以上就是我发生心态转变的整个立场,希望对大家有帮助,我自己记录之后也便于我对温习~