一个简简单单的安灯系统，居然话费了如此久的时间-大概两个月，让我十分汗颜，也十分的羞愧。然而，事情已经发生，人生没有ctrl-Z，所以总结经验教训是最主要的。
1：需求不明确。用户的需求提的比较模糊，那么作为软件设计及实施人员，应该深入的思考，并就用户提出的初步需求和方案进行分析，并针对性的提出问题或者建议，并得出双方都认可的一致性的结论。
2：解决方式不全面。同样的需求，可以有多种的解决方式。如果用户提出的解决方案，实施比较复杂并且效果不理想，那么我们应该与用户进行积极的沟通，站在技术与需求的角度，提出方案。
3：没有详细设计边动手编码。这是很大的错误。造成的后果是，如果系统架构存在问题，需要修改，那么整个程序就需要进行比较大的改动，而且修改时的逻辑问题将会更加复杂。所以一定要考虑的十分周详，十分详细了，甚至细小到参数的设计再动手编码，编码之前最好有纸上的逻辑图。
4：关于系统架构，要多考虑，要与经验丰富的人一起进行讨论，完成架构设计。比如，数据库的设计，要考虑到扩展的问题。
5：最好可以找人一起考虑下逻辑的问题。
6：遇到bug，进行调试时，要注意调试的方案必须有针对性。要多学习工具的利用，这次就学到了很多比如assist 和 输出窗口。
7：经验。这一点是硬伤，所以更要注重经验的积累。
另外为了让后人学习我这个前车之鉴，来给大家简单介绍下 遇到的比较难搞的几个问题:
1:winform界面混乱的问题。我开始使用自定义的控件，对控件使用location 进行界面的定位，会时不时产生控件混乱的问题，不是两个控件重叠，就是有大空白。我的父窗口大小是不变的。所以很困扰。改进的办法就是不使用自定义控件，使用原生控件，同样使用location定位，混乱问题得到很大改善，虽然没有彻底解决，但是使用应该是没有问题了。真实的控件移动问题，还不太清楚。
2：socket通信问题。发送端是java，使用的是write（string）。接收端是c#，使用socket底层的read（buffer）时，会产生接受不完整的问题，而且会在data之前接收到一定的包头信息，对接收到的buffer要进行预处理才能得到需要的数据。改进办法是，使用while进行循环读取，直到读取的长度等于预设长度。
3：控件移动。由于socket监听是不在主线程中的，所以sockt引发的事件都是在从线程中的，而控件的创建是在主线程中，所以存在跨线程调用控件的问题。解决办法可以是invoke，这个估计大家都知道。还有一种办法是使用同步上下文，也可以很好的解决这个问题。而且感觉需要invoke比较多时，建议使用synchronizationcontext。一劳永逸。还有一种办法就是winform中的backgroundworker，也十分的好用。
转载于:https://www.cnblogs.com/AntiLosT-T/archive/2012/09/10/2678640.html
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/201499.html原文链接：https://javaforall.net
