C# WPF上位机开发（从demo编写到项目开发）
【 声明：版权所有，欢迎转载，请勿用于商业用途。 联系信箱：feixiaoxing @163.com】
C# WPF编程，特别是控件部分，其实学起来特别快。只是后面多了多线程、锁、数据库、网络这部分稍微复杂一点，不过都是可以解决的。剩下来的难点，就是怎么把这些demo code转变成真正的项目代码。那么这个里面就存在一个悖论？因为我们自己没有经验，那么就需要通过项目去积累经验。但是大部分同学在面试的时候，如果没有经验的话，其实不太容易面试的上。所以就存在着一个鸡生蛋、蛋生鸡的过程。
因此，如果是真的遇到这种情况，其实可以自己主动去找一些项目，模拟一些项目，参考一些项目的。通过把这些项目做好、做完整，最终也能体现在自己的简历里面，这样会好很多。此外通过项目，自己也可以掌握一些项目的需求管理、开发方式、人机交互、软件部署等内容。
1、项目从哪里找
项目可以是别人已经做过的软件，也可以是之前别家公司开发好的上位机系统，甚至是市场上目前已经存在的上位机系统。我们参考的目的，主要是找出自身的差距，在这学习的过程当中，通过反馈的错误加强一下对wpf的理解，也让自己更深刻地去理解业务。
2、项目规模
项目本身可大可小，如果是一开始做，建议不要选择特别复杂的项目。可以是简单一点的，比如起初约定是1000行之内的项目，后期慢慢变成3000行之内的项目，慢慢逐渐增大项目的规模。
3、开发的时间
项目开发的时间不要太长，也不要太短。一般以星期来说，4个星期以内，或者1个月以内做完比较合适，后期的话可以扩大一些。因为如果项目本身比较小，那么它和demo的规模其实是一样的，失去了练习的意义。如果项目本身比较大，那么很容易让自己没有信心的，因此每次做完一个项目之后，新项目规模可以增大一点点，开发时间可以增长一点点，这样也会让自己逐步获得成就感的。如果难度太高，就会导致项目本身一直没有进展，很容易会让自己没有信心，项目估计也会烂尾下去，会失去继续学习下去的勇气。
4、先写文档，再写代码
写文档的好处很多，它可以明确项目实现哪些功能，需要花费多少时间，怎么测试，怎么部署等等。此外，针对实际编码的过程当中遇到的问题，也可以检验一下，是不是当初文档就没有确定好范围。还有，文档中的交互图、状态机也非常重要，基本上如果需求和功能没有理清楚的话，代码是不可能写好的。有些同学可能一开始不习惯写文档，但是这是一个必须要经历的过程。好记性不如烂笔头，时间长了，只有文档能够帮助我们厘清当初这个项目为什么要这么设计。
5、写代码的同时写好注释
代码部分可以看成是前面各种demo小模块的功能叠加。当然，开发的过程中也可能会遇到自己以前没有碰到的问题，这也算好事，因为相当于借此机会了解到了新的内容，自己又可以成长一些了。开发的代码，最好用git软件管理好，做好版本控制，不要每次都是拷贝、粘贴来处理。代码也要及时添加好注释，毕竟很难保证一段时间之后，自己还能记住当初代码为什么要这样写或者那样写。
写好的代码集中放到一个位置，后续就可以不停改进和优化了。改进和优化也是对自己能力的一种考验。不要代码写完了，功能写完了，就放在那里不管或者过一段时间后直接删除了。
6、适时分享自己的代码
提高自己代码的另外一个方法，就是适时将自己的代码share出去。很多时候，我们自己写的code，它的价值其实未必有我们想象的那么大。分享出去，如果别人能给自己提意见，那再好不过了，这相当于自己的代码有了一些负反馈。利用这些负反馈，去优化自己的功能，不是很好吗？当然，如果没有反馈的话，那说明对应的项目方向可能不对，功能也不对，或者性能不对，这其实也算是一种反馈。
7、试着让自己的项目商业化
如果只是开源项目，自己做一做，这也无可厚非，但是这样就无法形成一个闭环。兴趣本身可以维持一段时间，如果想要长久地做下去，还是要让自己开发的项目能够真正用起来，有一些收益，而不仅仅是一个玩具。这方面可能要多花一点时间去思考和实践，如何包装自己，如何找到潜在的客户，如何找到相关的渠道，这些都很重要。
就算一开始的时候不涉及到商业化这方面，后期时间长了肯定也会想到这方面问题的。归根到底，我们这个软件究竟为什么开发，谁会用，解决什么问题，有什么优势，怎么才能有收益，这是所有项目的落脚点和出发点。