【原】小软件开发心得（一）——需求、开发

前一阵做了一个小软件“豆瓣电台桌面版”，到现在已经基本告一段落。其实做这个小软件，一方面是研习研习自己最薄弱的Winform开发，顺便掌握了一点Windows API编程的基本知识，更主要的，是体验了一把独立开发软件的过程：从需求，到开发，到测试，到推广等等一系列的过程，倒是小有收获。

这是我第一次独立开发一个桌面小软件，身兼设计、开发、文档、测试、推广、客服数职，体会不可谓不深，但也不能说这些心得就是对的，在这里抛砖引玉，还望有更多经验的童鞋讨论指教。

需求篇

和开发商业软件不同，开发小软件的第一个客户，也是最重要的客户肯定是开发者自己。我猜绝大多数开发小软件的童鞋都会有这样的一段心路历程：

“我擦，XXX怎么用着这么别扭” \ “我勒个去，XXX怎么连这个功能都没有”

-》

Google \ Baidu 一番

-》

下载一个或者几个看上去很美好的似乎可以满足我们的小小愿望的软件

-》

各种不给力

-》

一怒之下，打开IDE或者记事本，踏上了开发小软件之路

这个过程中我们可能还加入了几个论坛，看了几个博客，下载了几分源码，最好别丢掉它们，它们会是很宝贵的资源。

既然需求是自己提的，一切都好说。这时如果有前人的代码借鉴更是容易，有时只要改动几行代码就可以了；即使是没有代码，既然能动手写，至少说明心中有数，一般也不会太困难，一个周末基本就搞定了。

如果就此打住，可能只是诞生了一个小工具，一段小代码，没有推广的必要，也就没有接下来的麻烦了，但这时候，可能心中一点点小小的完美主义会跟你说“你不能做的更好么？”然后你开始会想之前看到的AAA、BBB、CCC软件，它们的XXX、YYY、ZZZ功能看上去都不错，为什么我不把它们也添加到自己的软件里面呢？这样你之前的一点小小的自我满足欲开始向更大的野心膨胀了。

开发篇

语言+平台

开发小软件，当然是越快越好，如果再有点野心，越方便扩展越好。.Net虽然基本还是个Windows Only的框架，但开发效率实在是高，而且本人也最熟，所以豁上放弃Linux和苹果的用户，也毅然选择了.Net和C#。

不过用.Net开发桌面应用程序也有好几个选择，一个是Winform，一个是WPF，还有一个是可脱离浏览器的Silverlight。

• Winform：各种库各种控件很丰富，开发较快，而且可以直接调用系统各方面资源，再一个性能比较好，占得资源比较少；但一些在WPF和Silverlilght下很容易实现的效果在Winform下就会很困难，更别说动画了，而且布局方面也很麻烦。
• WPF：大部分的Winform控件都可以直接放到WPF里面，也可以直接调用系统各方面资源，动画、特效什么的都很容易实现，流式布局或者表格布局也很方便；最大的问题是性能较差，占用资源大概是Winform的两倍左右。
• Silverlight(Out of Browser)：布局方便，动画、特效也很多；但控件比WPF的弱，不能直接调用系统资源。
• 最后考虑到我的软件需要调用系统资源，同时也要考虑性能（一个小小的电台软件占用物理内存六、七十兆还是有点夸张），选择了Winform。

Hack! Hack!

既然是茶余饭后的小软件，除了必要的良好架构之外，最好是在现有的轮子上增增补补，而不是完全重新做一个轮子。但轮子毕竟是别人做的，各种不顺手，这时候就该发挥我们的才智，用各种小聪明进行各种Hack了。

比如“豆瓣电台桌面版”，就是直接用WebBrowser控件包了一个网页中的原本的那个豆瓣电台的flash。这样不用考虑从获取播放数据到播放乃至展现上的各种功能各种问题了。但由于这层Flash的封装，导致很多东西无法直接被我的代码控制，于是就得另辟蹊径。

比如“豆瓣电台”的Flash上有几个按钮，分别对应几种操作。为了能用快捷键实现同样的操作，就需要调用Windows的API，模拟发送点击按钮的消息。而在实践中我又发现当程序最小化时，模拟发送的消息不起作用，应该是最小化时窗口异化了，不恩那个再根据正常大小的坐标发送消息，为了解决这个问题，我又重新实现了窗口最小化的表现，把窗口以正常状态挪到了屏幕外侧而不是真正的最小化。

再比如播放的数据，关于歌曲的一切信息都是由Flash接收的，除非监听网络，否则无法获得这些原始数据，而监听的话效率又太低，过滤干扰数据也不容易，于是我就用各种方法来获取这些原始数据。比如歌曲名会同时更新到Flash所在网页的标题上，我就处理浏览器的TitleChanged事件；再比如“豆瓣电台”有个标明是否喜欢当前歌曲的逻辑，这个“是否喜欢”当然是在我得不到的源数据里面，但它会在界面上表现出来——喜欢就是“红心”，不喜欢就是“灰心”，那我就获取心所在坐标的颜色，红色就是“喜欢”，灰色就是“不喜欢”。

这些Hack的方法，有些是能从网上搜到的，有些就得靠自己的经验甚至是灵机一动想出来的了，正所谓“条条大路通罗马”，如果正路走不通，找找偏门也许还能更快达到目的。

版本管理

这里说的不是代码的“Version Control”，而是软件本身的版本管理。如果软件不给别人用，自然不用考虑什么版本，编译-》覆盖就好了。但如果要发布出去，版本就是必须的了，除非你就做一锤子买卖。

版本的定义其实按照自己喜好来就好了，VS里面有一套按照编译次数来定义的规则，此外还有什么“单数内部，双数发布”之类的规矩。不过我个人喜欢用发布日期来定义版本，这样简单好记，而且让用户一看就知道需不需要更新。

比较麻烦的是怎样提示用户更新。最简单的当然是在网上发个帖子，说“我更新啦”，但这样当然不大靠谱。还有一种简单还比较靠谱的办法，就是随便找个网络空间，上传一个文件，在里面添加版本信息，最好再加上些更新介绍什么的，每次程序启动的时候读取这个文件，来提示用户更新，当然还要把用户导向你的下载页面。更高级的自然是用户不用手动下载，自动更新+自动安装+自动重启或者提示重启，这就看起来比较成熟了。小软件嘛，我觉得第二种就挺好，因为简单，而且本来程序就不大，下载也不会太麻烦。

插件扩展

一个软件，越做肯定是越复杂的，功能越来越多，操作越来越繁琐。KISS原则很好，但当你面对用户们勤劳的申诉，热情的邮件，渴望的留言时，你又怎能无动于衷，而且往往添加一个新功能并不是困难的事情。

于是当你花了一个下午把用户的需求统统满足然后更新，满心期待用户的感谢与赞美的时候，却发现人们开始抱怨“怎么这么多乱七八糟的功能？”“太臃肿了！”“我要原来那个简洁的版本！”

然后你就迷茫了，就困惑了，感慨一声“真TMD难伺候”，然后把原来的简单版本打个包，再冠之以“简洁版”发布出来。

当有人跟你留言“你好，可不可以只添加这个功能就好了呢？”你差不多该疯了。

所以用KISS原则来架构程序的主体，然后再辅以插件系统，这才是解决问题的最佳方案。而.Net的反射机制，基本是为插件系统量身定做的，足够容易，足够方便，具体可以参见园子里的相关文章http://zzk.cnblogs.com/so.aspx?w=%E6%8F%92%E4%BB%B6%E7%B3%BB%E7%BB%9F&t=，这样大家各取所需，自得其乐，而且发布新功能或者删减旧功能往往只需要单独操作一个插件就可以了。

关于界面

之所以最后说界面，是因为我对界面的领悟也不是很到位，至今“豆瓣电台桌面版”最为人所诟病的就是“图标太丑”。不过我的体会是，图标再丑也比没有图标好，而且整体风格要一致，配色越少越好，主界面越小越好，因为小软件一般不会是用户的主窗口，所以越不占地方越不扎眼越好。当然，图标如果能找专业人士设计个，要比随便在网上找个好。顺便推荐一个找图标的搜索引擎http://findicons.com/search/。

至于各种操作，尽量满足大部分人的操作习惯。那么什么是大部分人的操作习惯咧？看QQ 就好了。比如QQ是单击托盘图标显示主界面，那你就不要双击图标才显示；比如QQ能贴边隐藏，那你也最好能贴边隐藏；比如QQ把很多操作放到托盘的右键菜单上，那你也把它们放到右键菜单上好了，当然主界面上也要有，因为QQ也有。

 

这一篇就先写到这里，其实以上大多是些小问题，在我看来，更有技术含量的，其实是下一篇想写的“推广”和“测试”。