工作来的第一次总结

在这毕业后的一年中，我负责管控公司生产使用的白平衡及其ADC程式，但这毕竟不是一个专门从事软体开发的企业，专门从事软体开发的企业可以利用版本控制系统（VSS等其他的版本控制工具）进行管控，由于专业的差异，和对版本控制系统了解的限制，公司内部很少人对版本控制策略有所了解，只是采用手工的管控，这既浪费了人力，又增加了不少的出错风险。特别是针对现在负责程式开发和负责程式发布的不在同一个部门，这其中又增加了部门之间沟通的资源浪费。但似乎我的想法得不到BOSS的认同，毕竟这是一个制造工厂，注重对于产能、品质的提高，提出的案子必须能获得实际效益。在他们看来，引入程式版本控制系统，还不如让一个人在专门负责手工管控这些程式的版本，毕竟一个系统的引入，还需要专员来维护，这其中的消耗，也是不能不考虑的。有一点我想应该是根据目前的工作需求，还不至于达到一定要导入的地步。

 

   工作一年一来，做了几个不大不小的案子，由于专业的差异以及兴趣的不同，和我同一个部门的大部分毕业于电气、电子等专业，因此有些案子，我只能一人承担，这段时间以后，我发现了自己有一些很不好的习惯：

  1.工作不擅于做笔记，往往发现了问题，或者疑问的时候，就上网查查资料，等到找到了问题的解决办法的时候，很少做一个总结。过一段时间，往回想想最近的学习收获的时候，才真正体会到好记性不如烂笔头的道理，更何况我的记性并不好。

2.工作缺乏交流，刚来这家公司的时候，就我一个人懂C＃，前辈门都习惯于C++和DELPHI的开发。但我坚持要使用C#，在往后的一段时间内，他们也慢慢认识到了使用.NET平台的诸多好处，当然包括.NET的易学易用，多种开发语言的兼容性。在这过程中，出现了问题我只能通过网络寻求帮助，只能自己研究（当然不是所有的），我还没有体会到真正的团队合作。

3.完成一个项目，缺乏规划，总是一有思路就开始写代码，整天就是沉浸在代码的编写和调试里，而并没有一个整体的开发框架，对于程序的架构，并没有很好地事先构思，只是急于把功能实现，当功能实现后，回头看看自己写的代码，结构往往很混乱。我想这并不是一个好的程序员会有的习惯。当然，我从来没有认为我写的程序有多好，总存在不如意的地方。