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