一个小菜的项目感想

记得刚来这公司的时候,心比天高,对公司的现有项目很多都看不上眼:无架构,无技术,无需求,无注释,无文档的五无产品,编码凌乱,性能低下,每个人各自为政,对于修改别人写的代码的最好方式不是修改,而是重写,不是借助现有架构重写,而是彻头彻尾的从UI层写到存储过程:html,css,js,c#,sql...。觉得自己一定不能成为这样的coder,一定要改变这一切。于是等啊等,终于公司给了一个项目的模块,让我单独页责。于是我很努力的去做,却发现我做的越深就做的越累,但工期又近在眼前,于是就慢慢忽视一些细节而先去把功能完成,又发现原先的设计有问题,原先写的一些小模块无法适应业务的变化,但是我之前所写的很多另外一些小模块完全是依赖于它的,修改又太费力,于是就copy了一份,然后对其某些部份重新写了一遍。忽然又发现我所做的界面所展示的数据比需求少一个,于是又从界面改到了DB。忽然又发现某些代码执行的结果有问题,但是单独拿出来执行又没有问题了,找了半天才发现一些是第三方控件本身有问题,一些则是与原有的系统有冲突。没有办法,只有想另外一个曲线救国的方法了......终于,我把它做完了。累啊,没等我好好休息一下,测试的反馈下来了,某某某地方有BUG,需要修改。没办法,只能照办,但是当我重新打开这个项目的时候,却发现己经找不到当时所思考的方式了。对于一个值的修改起码有三个地方以上,我如何去确定到底是哪一个起作用,当我修改了一个地方后,如何又能确定不会对系统的期它地方有影响。最省力的方式就是重新写一遍。等等,如果一段代码写成了这样,不就很象本文开头所提到的五无产品吗:无架构,无技术,无需求,无注释,无文档。原来一个立志不要写成那样代码的我,在不知不觉中将代码写成了那样......

我很沮丧,就象一个想考100分的学生只考了60分,而明明他有机会考100分的。其实,每个人都不希望把代码写成那样,都希望写出逻辑严密,结构合理,条理清晰,通俗易读,可复用性可扩展性好的代码,但往往结果却不是人所想象的那样。有一个好的愿望是好的,但更重要的是如何去实现这个愿望。我花了一早上的时间去思考这个问题,现总结如下:

 

1.在项目中所出现的问题:

a.变量字段风格不一致:比如outley,有的地方写:outlay,有的地方写outley,比如createTime,有写成create_time,比如beginEmp,有写成beginemp。其实不是故意写成这样的,这样写也并没有错,只是在项目的开始阶段没有统一风格,这带来的问题是在后续的工作中会花大量的精力来辩认变量字段的具体含意。

b.数据库设计不完善:在开始阶段只是按照最基本的方式将业务数据编入数据表,做了一半才发现当我要进行数据统计的时候需要若干个记录状态的字段,而数据库并没有将其设计进去。于是结果就是在表中加了若干个字段,然后对先前写的一步一步的排查,相当烦燥。还有一个问题是有张主表将历史记录与当前记录混在一张表中,于是每次取数据运算的时候都会先写段大几10行的代码将当前数据取出,很不好!

c.做事无规化:有个需求是客户会输入一些信息。于是我就想当然的写了一个界面,结果发现不是这样,于是就改,又不是这样,就又改。这其实是很打击士气的。既然要改这么多次,为何当初不好好规化一下呢?

d.与旧有系统的集成:这其实不应该全算在我头上,但我确实也没有考虑进去。旧有的JS纯手写,我的JS运用了jquery,在某些地方纯手写的JS不会引发jquery所写JS的某些效果,很头痛......

 

2.以上讲了这么多,其实可以归结为一句话:我做事的方式有问题!我是典型的想到哪做到哪,做着做着发现写的东东有问题于是就回过头来改,又发现有问题,就又改。改着改着代码就一团糟了。总结了一下,应该用以下方式来解决,其中大部份是老生常谈,就不多讲了:

a.明确需求,就是你要彻底理解需求

b.理解/优化数据库设计,起码你所涉及到了表与字段要相当的熟

c.界面Demo。这步很重要,不要慌张的去做,而是先画个Demo出来,起码是界面的架构,要知道UI是最费大脑了~~~html,css,js......

d.构思代码。成竹在胸,才能下笔如有神。

e.统一风格,代码规范。

f.制定时间表,每天按时按量完成。这个按量很重要,不要一味追求进度而超量完成。还有一点很重要:不要随意将一个模块的时间超过两个星期,人会疲的。

 

3.以上是大体的做事方式,俗话说光说不练假把式,任何项目还是靠具体的技术支撑的,以下就是我所总结出web的技术与工具组合:

数据库设计:powerdesigner/visio

Demo实面:  axure/visio

前台:以jqeury为核心,jquery控件

前后台交互:以json为核心

后台:将json字符串直接序列化成实体对象,然后再进行操作

DBOR框架与dbHelper配合。

 

4.具体编程经验:

a.对于数据库设计,如果一张表既存当前记录又存历史记录,当遇到大计算量的时候是每烦人的,比较好的方式是分为两张表,一张存历史,一张存当前,当然,具体问题具体分析。

b.对于JSHTML的分离,并不是完全分离分佳。因为JSHTML元素的访问一般是通过ID的,这样会造成页面上nID,对编码带来困惑,我所喜欢的方式是对于静态的HTML,可以分离,对于动态生成的HTML,就要具体对待了。

c.一般我们会把所有JS存在一起,所有CSS存在一起,但是对于一套完整的JS控件,这并不适用。JS控件有其自己的体系有点分开存会带来困惑或者不可预知的后果,所以不要将JS控件体系内的内容分开。

 

5.下一步研究方向:虽然不一定搞一辈子WEB开发,但是现在搞的就是WEB,搞一门就要精一门。

a.当前最重要的是继续丰富我的jquery控件,让前端开发的速度更快些更可靠些。

b.然后解决一个软件架构的问题。我们现在用的最多的就是三层架构:ui+bl+db,结果我现在把它搞的本质上只有两层了,因为bl基本就是一个二传手。优点就不说了。对于小项目还可以,但是如果是个大项目,假设有10张表,100取法,那我是不是就要写100个存储过程,100db层的调动方法,100bl二传手,UI上再写100个赋值方法呢?

c.引入or框架,具体就是nHibernate

d.引入单元测试

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值