最近一个项目的问题小结
时间:2010-04-04 来源:icymoon
很久不写用户态程序了,最近从头写了一堆Perl脚本。。。突然又有了点程序员的感慨。也因为一些私事确实影响到了心态和工作状态,加之项目本身的一些问题,感觉从方案评估开始就做得不顺手甚至有点混乱和思维懒惰,到了编码阶段觉得总算是很简单的了但也在单元测试的时候出了个意外的bug。
项目背景:在设计方案上难,需要权衡并验证很多东西,但在编码实现上简单容易,但时间要求紧(估计交给QA前就得先给人试用了。。。-_-b),一些coding的细节要很小心才不致搞出bug,写漂亮了略有点难度,属于麻烦又简单的事情。
有些问题还是写下来吧:
0. 跟用户沟通应该充分,一些命令行参数或者UI接口形式应该提前想好并跟用户仔细地敲定下来。而不是突然想起来哪里不合适再去确认修正。
1. 在设计阶段,确定方案后,一定要关心某些细节的整体统一,接口划分,函数返回值,参数判定等,都应仔细考虑,否则会修正起来会杯具。
2. 不要盲目地写一些功能点的POC代码,可能merge起来会很麻烦,尤其是逻辑复杂的程序,这次居然在单元测试和整体联调的时候发现大bug一个,把一个接口函数重写了。
3. 合作编码时,互相review代码可以有效地降低bug率,但是每次时间紧的时候,都做不到。
4. 其它:coding太多的时候容易晕;在一个公司内部,是个语言就该有份编码规范;还是很喜欢perl地说;
应该了解系统,也应该了解上层业务架构。从网络,到系统,到应用,各有个的特色,啥时候能做到一个完善且默契的整体,就好了。
项目背景:在设计方案上难,需要权衡并验证很多东西,但在编码实现上简单容易,但时间要求紧(估计交给QA前就得先给人试用了。。。-_-b),一些coding的细节要很小心才不致搞出bug,写漂亮了略有点难度,属于麻烦又简单的事情。
有些问题还是写下来吧:
0. 跟用户沟通应该充分,一些命令行参数或者UI接口形式应该提前想好并跟用户仔细地敲定下来。而不是突然想起来哪里不合适再去确认修正。
1. 在设计阶段,确定方案后,一定要关心某些细节的整体统一,接口划分,函数返回值,参数判定等,都应仔细考虑,否则会修正起来会杯具。
2. 不要盲目地写一些功能点的POC代码,可能merge起来会很麻烦,尤其是逻辑复杂的程序,这次居然在单元测试和整体联调的时候发现大bug一个,把一个接口函数重写了。
3. 合作编码时,互相review代码可以有效地降低bug率,但是每次时间紧的时候,都做不到。
4. 其它:coding太多的时候容易晕;在一个公司内部,是个语言就该有份编码规范;还是很喜欢perl地说;
应该了解系统,也应该了解上层业务架构。从网络,到系统,到应用,各有个的特色,啥时候能做到一个完善且默契的整体,就好了。
相关阅读 更多 +
排行榜 更多 +