又拖了一个多学期,这下应该是真的能交付了
最近去实习,算是真正长了见识,学到了很多自己闷头做学不来的东西,回来再看这个项目颇有感触。几个人凑在一起,七手八脚的往git上面提交,做出来的一定不是规范的项目。当然自己试试错并不是坏事,不然也对比不出来一些问题。
1、最大的问题是过度依赖winform自带控件
当软件做到一定规模,想要记录一些信息时,就发现根本没有地方加。想用AOP结果发现控件代码根本改不了,于是包括后面的一些像记录用户是否有修改操作这种功能,都做成了leave事件里面做判断然后处理,乱到不行。如果一开始就写好自己的TextBox控件不论是加什么功能都有商量的余地,不至于做成现在这样。
2、版本控制杂乱无章
所有人都用一个master分支,导致master分支几次莫名其妙出错,但好在项目分工明确,且人数也不多,一直也没出什么大岔子。但一个管理master分支的人员绝对是必要的。
3、乱用trycatch
乱用trycatch的一个问题就是养成了现在遇到访问空对象就想写trycatch,但这种写法就跟拉屎不冲厕所一样恶心后面的人,更何况下一个人八成还是自己。之后要摒弃这种习惯,在写的时候就应该考虑周全如果一个方法失败了该怎么办,遇到空对象怎么办,文件读写错误怎么处理。像读写数据文件这种没办法避免的trycatch要在catch里面做好回滚。
4、不够OOP
封装只是public成员变量/函数套了个壳子,继承一个没有,多态就更不用说了,这个项目完全是按照面向过程来写的,这个问题其实也是跟第一个问题有很大关系的,如果当初对OOP有多一点认识,项目结构一定好很多,不过这一经历也让我深刻明白了OOP的意义,为什么要有对象和继承关系?OOP真正的作用就是解耦、重用,使得代码拥有高度的扩展性,我想这就是面向对象相对面向过程最根本的优势所在。继承和多态是密不可分的,封装也只是一种做法,所谓三大特性最终还是为设计模式而服务,设计模式才是OOP真正的精髓所在。
说会项目本身,规模说起来也不小,并不能当作写成这样的借口。还是自己的经验不足,要多学多看。想想给所有控件写个虚基类,做个factory方法,写个Fatal Error处理,不是美滋滋?
差不多就是这些了,想起来再往上加,过两天写写实习项目代码的体会。