在这毕业后的一年中,我负责管控公司生产使用的白平衡及其ADC程式,但这毕竟不是一个专门从事软体开发的企业,专门从事软体开发的企业可以利用版本控制系统(VSS等其他的版本控制工具)进行管控,由于专业的差异,和对版本控制系统了解的限制,公司内部很少人对版本控制策略有所了解,只是采用手工的管控,这既浪费了人力,又增加了不少的出错风险。特别是针对现在负责程式开发和负责程式发布的不在同一个部门,这其中又增加了部门之间沟通的资源浪费。但似乎我的想法得不到BOSS的认同,毕竟这是一个制造工厂,注重对于产能、品质的提高,提出的案子必须能获得实际效益。在他们看来,引入程式版本控制系统,还不如让一个人在专门负责手工管控这些程式的版本,毕竟一个系统的引入,还需要专员来维护,这其中的消耗,也是不能不考虑的。有一点我想应该是根据目前的工作需求,还不至于达到一定要导入的地步。
工作一年一来,做了几个不大不小的案子,由于专业的差异以及兴趣的不同,和我同一个部门的大部分毕业于电气、电子等专业,因此有些案子,我只能一人承担,这段时间以后,我发现了自己有一些很不好的习惯:
1.工作不擅于做笔记,往往发现了问题,或者疑问的时候,就上网查查资料,等到找到了问题的解决办法的时候,很少做一个总结。过一段时间,往回想想最近的学习收获的时候,才真正体会到好记性不如烂笔头的道理,更何况我的记性并不好。
2.工作缺乏交流,刚来这家公司的时候,就我一个人懂C#,前辈门都习惯于C++和DELPHI的开发。但我坚持要使用C#,在往后的一段时间内,他们也慢慢认识到了使用.NET平台的诸多好处,当然包括.NET的易学易用,多种开发语言的兼容性。在这过程中,出现了问题我只能通过网络寻求帮助,只能自己研究(当然不是所有的),我还没有体会到真正的团队合作。
3.完成一个项目,缺乏规划,总是一有思路就开始写代码,整天就是沉浸在代码的编写和调试里,而并没有一个整体的开发框架,对于程序的架构,并没有很好地事先构思,只是急于把功能实现,当功能实现后,回头看看自己写的代码,结构往往很混乱。我想这并不是一个好的程序员会有的习惯。当然,我从来没有认为我写的程序有多好,总存在不如意的地方。