饕餮元年开发手记
一
饕餮元年是我自己开发的第一个基于Pocket PC的无线餐饮管理系统。饕餮是中国古代传说中的怪兽，喜欢吃东西，所以“饕餮”也形容暴饮暴食的人。在这里取这个名字，是希望大家有个好胃口，而不是得消化不良。
而元年则是版本号，大家看1.0、2.0、2000什么的太多了，既然名字这么中国化，索性让版本号也中国化。元年当然是第一个版本了，希望这个软件有二年、三年诞生。
到目前为止，这个软件还停留在我的脑子里。现在我在写文档。也许是受了XP的影响，我尽量不让文档过多、过烂，而且是想到什么写什么，到最后应该不会超过30页。维护30页的文档对谁来说也不是困难。另外，这些开发日记也属于文档的一部分。
最近在读测试驱动开发和重构的书，但我不打算在项目中引入我尚未完全了解并掌握的技术。如果时间宽裕，我希望在编写业务逻辑代码时能够引入单元测试，但对于一项我不完全了解的技术，是否能够帮助我，目前我仍持怀疑态度。
目前我的想法是将整个软件分为三个层次：数据库表示层、业务逻辑层和界面应用层。数据库层用Web Service连接后台SQL SERVER数据库，其他两层都在Pocket PC上实现。目前我还没有用UML等工具。可能到设计类的时候，我会用用VISIO，但我不会使用其他的UML工具。
对了，写这个程序的目的是参加六月份的微软开发大赛，能不能赶得上这个Dead-line，目前我心里没底，毕竟，我只能用晚上和周末的时间写程序。
二
昨天我已经完成了数据库的定义、业务逻辑定义和部分的界面定义工作。尽管还没有写一行代码，但我的心里已经比较有底了，至少我知道程序该写成什么样子了。
写程序和写小说有很多相似之处，在下笔前，先要考虑故事的梗概，然后推敲每一个细节，继而塑造人物形象和他们各自的上场时间，最后才是在纸上写出整个故事来。而写程序呢，首先要进行需求分析，然后确定业务逻辑，然后进入详细设计，去设计每一个类和他们各自的生存周期，真正开始编码时，这个程序其实已经呼之欲出了。
当然，我们不能忽略具体的技术细节对开发的影响。我还需要去更新我的软件架构设计，我还没有定下来，具体的业务逻辑在哪里实现，在Client上，还是在Web Service中。这是最近比较困难的事情。
其实在我刚入行的时候，所有的人都在强调着需求分析和设计的重要性，很多人都把他们当成“银弹”。可直到三年之后，我才真正能够按照自己的思路，来构建一个程序，而那些敏捷开发、XP、测试驱动开发，不知道要到什么时候才能真正用到开发实践中呢？
三
我的设计差不多要完成了。其间我陷入了对Web Service接口定义的考虑，最后我还是把逻辑实现放在了Client中，而一些类似于结构的类可以通过序列化传递给Web Service。当然这样的说法有些不准确，Web Service的接口是按照业务逻辑定义的，它可以返回序列化的对象，也可以是DataSet。
我不知道我的设计方式是不是对，但这几天走过来，没有想清楚的问题也逐渐清晰了。我先是大概的将业务逻辑划分为几个类，然后根据这些类来设计数据库；当数据库的定义差不多时，我就差不多知道我需要维护哪些数据了。下面我开始定义我的界面，但看起来其实并不成功。因为我不知道我需要多少个界面。
于是，我重新回到定义业务逻辑的过程上来，我将业务逻辑重新走了一遍，他们需要完成哪些功能，需要那些界面。等这些软件的执行路线走通后，我开始合并一些比较类似的界面。于是，我将这些界面总结成十几个对话框，好了，我的UI类也出来了。在这个过程中，我已经清楚每个界面上该有几个控件了。
我现在在定义业务逻辑类的方法，他们是这个软件中最重要的部分。而我目前缺失的环节是如何在UI类调用业务逻辑方法，然后由这些方法去调用Web Service。
我正在做这个工作，也许两天后我就可以编码了。噢，首先要把数据库建起来……
四
这个周末过得很惬意，哪里也没去，在家里呆了两天。过着吃吃睡睡的日子，顺便把代码的框架搭了起来。说实话，我这是第一次用Vs.net来开发一个Project。的确比以前用的IDE有了长足的进步（别忘了VC6可是1998年的产品了……）。
我可以把文档、代码和资源放在Solution Explorer里，管理起来十分的方便。但不知道为什么把Form放入一个文件夹后，代码就会变成黑色的。不知道是我的设置有问题，还是VS.NET的bug。
好了，说说我的程序吧，我把业务逻辑类和界面类都实现了，一切还好，我充分利用了属性这个可爱的东东，写C++有时偷懒，干脆把成员变量弄成public的。现在我有仿佛回到使用VCL的时候，十分舒服。毕竟.net的掌门人是当年Delphi的开发者。
五
事实证明，代码与文字不可得兼。在悠悠闲闲地写产品文档时，写一点文字也是很正常的事情。但真正开始写起代码来时，即使有写文字的想法，也绝对不会在敲了几百行代码后，还会有摆弄键盘的想法了。
我是一个极其没有时间概念的人，写完系统分析后，我在悠闲中度过了几周的时间，每周只是在周末写一点程序，但也只是适可而止，我还要看看电视、听听音乐、玩玩游戏……
到五月的最后一个周末时，我才开始紧张起来，当时我对在6月12日前能否完成已经不报太大的希望了，按以前的进度，三周才写了30%的功能，两周的时间不但要写完，还要完成简单的测试、发布，这些活看起来很琐碎，但实际上都是极耗费时间的。
不过事后我发现，按照功能点来估算项目进度也存在一些问题。尽管当时我只完成了30%左右的功能，但系统的架构和技术点的尝试我都已经完成了。也就是说，在我以后70%的路途上，已经不存在技术难点了。而且随着我对C#的掌握，开发进度也比以前要快了许多。所以，我认为在估计项目进度时，不应该忽略技术难点对进度的影响，还有程序员对技术的熟练程度是一个动态的过程，我们不应该把一个人的开发效率看成一个定值，熟练程度、身体状况，甚至心情对开发效率的影响都很大，甚至可以达到倍数关系。
接下来的两周炼狱之旅还算是比较顺利，由于公司里的事情也比较多，我除了压缩自己的睡眠时间外，已经没有其他时间可以利用了。但睡眠时间与工作效率是有很大关系的。大脑疲劳的情况下，逻辑思维很容易混乱，而程序员逻辑思维的混乱、噢，或者说不清晰，给软件带来的可能就是致命的缺陷。所以我十分同意XP中的观点，每周只工作40个小时，我甚至觉得程序员如果每周编程时间不应该超过30个小时，除非是最后一周。如果给大家树立一个伸手可及的目标，大家会想只是一周，一周之后我们就可以享受假期、给客户演示程序、暂时告别枯燥的编码生活了，所以大家会放下很多事情，将生产率提高到一个很高的程度。但如果一周之后完不成，程序员受到的打击是来自生理与心理两方面的。
程序开发中Deadline前的冲刺很像战争中的冲锋，如果第一次冲锋，所有的士兵都会发挥最好的状态，一鼓作气撕破对方的防线，但如果一次冲锋失败，那就会再而衰，三而竭了。所以，项目经理选择冲锋的时机很重要，有时候，一个项目的成败也许就在一念之差。
整个程序是让我比较满意的，因为我用了四周的时间进行了产品设计，很多逻辑问题都在那个时候考虑清楚了。整个架构在后来的开发过程中是坚固而且有弹性的，我相信如果再在上面添加或者修改某些功能，我们的改动会很小。逻辑代码与界面的分开最大的好处是重复的代码大量减少了，也便于理解了。唯一有些麻烦的是，由于我没有采用单元测试，为了完成一个功能，我可能要一起修改三个类——界面、逻辑、Service调用或者数据库操作。
让我不满意的是，对Web Service接口的定义并不好，由于对接口缺乏认识，我按照程序的需要定义了大量似是而非的接口，比如说，我要得到一组数据，有一个接口返回DataSet，而我需要得到其中一个数据，那么就需要另一个接口了。这是让我很不满意的一点。
另外一点是安全性，我把密码明码直接存到了数据库里，这是极其危险的做法；还有就是使用者的验证只是在登陆时起作用，而在调用Web Service的方法时，并不去验证调用者的合法性，这在无线环境下也是极其危险的，任何一个人都可以通过无线设备调用你的Web Service,获取一些数据，或者修改数据。对于安全性的考虑是下一阶段的重点。
在力所能及的范围内，我还是对一些已知的攻击方式做了防范，比如SQL注入，我用自己的方式做了防范，一旦察觉到可能的SQL注入攻击，Web Service会抛出一个异常。
说到值得夸耀的地方，我最欣赏的还是界面的风格，.net Compact Framework是不支持渐变背景色的，我用比较古老的方法实现了界面背景的渐变，但同时将对执行效率的影响降到了最低。还有多行显示的ListView控件，是我很早就想实现的，这次终于借助第三方的代码实现了。
这次开发的心得就这么多了，这次是我一个人从产品定义、设计、编码实现、数据库、测试、发布这样一路走过来的。很多地方都按自己的想法做了，效果还不错，有些地方也突现出自己的幼稚，不过咬牙一路走过来之后的幸福感却是什么都替代不了的。
无论如何，我要给自己放个心灵的假期了。刚才dearbook送来了《敏捷软件开发》，呵呵，终于可以放松一下了。