事实证明，代码与文字不可得兼。在悠悠闲闲地写产品文档时，写一点文字也是很正常的事情。但真正开始写起代码来时，即使有写文字的想法，也绝对不会在敲了几百行代码后，还会有摆弄键盘的想法了。
我是一个极其没有时间概念的人，写完系统分析后，我在悠闲中度过了几周的时间，每周只是在周末写一点程序，但也只是适可而止，我还要看看电视、听听音乐、玩玩游戏……
到五月的最后一个周末时，我才开始紧张起来，当时我对在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送来了《敏捷软件开发》，呵呵，终于可以放松一下了。
本文地址：http://com.8s8s.com/it/it36598.htm