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