现在的位置: 首页 > 综合 > 正文

电子商务网站的可持续发展

2013年05月13日 ⁄ 综合 ⁄ 共 4785字 ⁄ 字号 评论关闭

    来源:  http://www.javaeye.com/topic/152136

    2007年终于过去了,从焦油坑里爬出来幸存的人们,互相握手庆幸,喜极而泣,纷纷在博客上写工作总结与来年展望,而我终于厌倦了期权的精神鸦片,难得的坐下来,远离自己负责的网站,想一想来年的布局。

     在国家大力宣扬环保,可持续发展的时候,从企业,从网站,就我个人,都要讲一个可持续发展,一夜暴富的思想只会浪费精力,没有方向,而只有平时注重积累,厚积薄发,终会有从量变到质变,扭转局面的时候。 

    我们发力在向前奔跑的时候,也要适时的停下来,倒掉鞋子里的沙子,让自己的步伐更轻快。 

   我所经历过电子商务网站都面临的下面的问题,如何让自己步子慢下来,解决这些问题,持续发展,是一个从管理和技术层面上,都比较有挑战、让人兴奋的问题:

1.膨胀

    公司业务向好,代码越加越多,原来一个人写一个类时,只是完成一两个单一的功能,随着需求的变化,一个核心类的代码,不知不觉膨胀到一两千行,有的Action代码,也会超过1000行。接手的人,一般不敢动,也不愿意动接手的代码,也就是说,他不会去重构以前的代码,一般就是线性的随着需求的增加,代码也不断的增加,同时在开发时,总是八股文开发,很机械、迂腐的套用一些重型的、所谓的J2EE设计模式,如Factory, DTO, Proxy等等,代码量和代码复杂度最终是线性增加。

    则代码复杂度和行数的膨胀,会是负面循环,反过来影响你面对需求变化时态度。

    举一个例子,从用户角度来讲,订单上增加一个字段的小需求,应当是很简单的一件事,但是对开发人员来说,增加一个字段,则要确认所有与订单相关的页面(相关的界面可能有十几个)都要修改、重新布局,这个工作量可不小,而且容易漏改。这不是一个容易避免的事情,不仅是页面,类也要修改。很多人写的关联查询,结果放在DTO类而不是Map,扔到页面上的话,则DTO类也要修改。

    一般的性能问题,总是由开发人员的代码造成的,而不是由架构的Scalability瓶颈所造成的,累积的代码,就像电器上日积日厚的灰尘一样危险,随时会短路。以前的僵尸代码,会在数据量和访问量慢慢增长到某一个临界值的时候,突然复活,搞得你灰头土脸。 如果你只会批评开发人员不小心,那种永远也解决不了问题,让谁写,都不能保证不会踩上地雷。领导不出BUG,只是因为他们不写程序。


3. 铁打的营盘,流水的兵
     第一个人下棋,下到中途,离开了,第二人接手,接着下,以后可能会有第三个人,接手的人,怎么下怎么不顺,这时总想重新下一盘,但没有选择,只能一边问候着前人的老妈,一边继续走。最后,我们再把这盘棋复盘来看,做成一个棋谱,会有什么的感觉?

    这一般不是两个人能力差异的问题,是一个心理的问题,每个人都不愿意看别人的代码,都觉得别人的代码写的烂,不愿意花点时间,来review同事或者前人代码,他们认为这是考古学家的事情。这样的结果,如果不了解别人的代码,就无从重构,在此基础上增加功能或修改,只能说是乱上加乱。  

   要包容别人的代码,现在不是找出是谁造成的,而是要从自己接手这一刻,开始改进。

  打江山的人,所基于的环境,是非常恶劣的,是非常不容易的,从无到有的创建一个网站的老员工,一个人做三个人的活,是非常值得尊敬的,接手别人,再怎么说,也是站在别人的肩膀上考虑问题。其实让你先下,让第二人再接手,他也会这么有同样的思维,我们需要的是宽容,宽容与谅解应当是自上而下的,而不是自下而上,不然就变成,项目经理说:我体谅你们,可领导不体谅我啊。


4.新来的员工不是考古学家   

    新来的员工抱怨个不停,确实是很讨厌人,另一方面,从他的角度上来讲,没有选择的权力,必须在别人代码的基础上增加新的功能或修正一些BUG,你不能用你最擅长的东西,当别人的代码是JSP+Servlet,你就用这个,你必须要遵守这个规则,同时也要遵守别人的开发习惯。 

   新员工就像一个考古者,站在一段象形文字的文物面前,来想出前人的意图,确实非常的艰难。  

    所以每个公司的每个项目组,都应当向HR部门学习,制订一个良好的新员工入门索引,这个索引有什么内容,每个人根据自己的项目,自己来考虑。这样的索引目录可以重用,不用来一个要讲一遍,占用项目经理的时间。 

   一般的人,都是被动的,8个小时,怎么过,都是过,平时不会去看别人的代码,只是在自己承担一个任务时,才会去看那些相关的代码,这样就会时间太紧了,手忙脚乱的,容易出错。所以在平时,就要强制性的review代码,是必须要的,你不能信赖别人的主动性,否则的话就是自食苦果。 

5.脆弱的测试体系 

   长期膨胀,得不到改进、重构的代码,每有新功能开发,测试的代价非常、非常的高,因为非常容易犯错。

  很多的公司并没有一个良好的自动化回归测试体系,所带来的人工成本就是非常高,测试人员所做的工作,就是民工扛水泥包,又脏又累,测试覆盖的效率又差。 

   频繁ReOpen的BUG,会牵累process当中每个环节的人,配置管理员,测试人员,开发人员,TeamLeader,也会影响到考核。带来的众多的参与其中的人,随着运转,打标签,提交测试,打回,修改、再打标签、再提交测试(此时所有开发人员的BUG都要改完才能提交),测试人员重新测试(原来已经测试通过的功能,还要再测试一遍),重复N次。    

   其实我们自己从开发,到测试部门,都可以不要对立,坐下面交流,来去考虑如何改进。测试部门可以指导开发树立测试的意识、思想、技巧,开发人员必须要承担测试,不仅要写单元测试,也要做功能测试,也要会自动化测试,这些除了可回归的单元测试,很艰难,不容易做,但可以一步步的改进,其它的比如自动化的界面测试,其实是很容易的,花个两天时间,把成员关在会议室里,搞Win runner界面测试,编写可重用的测试脚本,定制有效的、覆盖关键路径的、可重用的数据源,还是能收到成效的,这样当需求变化时,那些没有变化的功能,其脚本也不变,都可以在短时间内回归的测试一遍,而不要把成本直接转嫁到测试部门。 

  关键是要不要走出第一步。 不知道为什么领导总是愿意相信冶百病的偏方,相信永动机,相信不会犯错,项目不会延期、百战百胜的神人。 不要再花钱找一些天桥说书、卖大力丸的QA了。其实没有一个人可以驱动一个庞大的团队,还是要靠团队中的核心都行动起来。

5.缺乏从宏观层面技术标准的概念统一和定义

     随着业务的发展,有很多的合作型的项目,子系统越来越多,同时要外接的系统越来越多, 做为一个分销的平台,可能要和外接的B2B系统对接,即要给别人在公网上发布接口,又要从第三方的系统获取产品数据源,这种系统与系统之间的数据交换,缺乏统一的标准,各种各样的技术都可能有,又有不同的项目组负责,各自为政,这不是他们的问题,他们不是CTO,不是架构师。   

     从全局的基础上,对系统的服务基础设施建立一套共同的抽象规范,从架构师的层面,进行控制。

     主要有:

     1.服务的分类(支付网关、消息网关、中央工作流引擎、中心缓存服务、外部数据源对接服务、B2B订单预订接口服务等),以及各类服务的设计原则和建议

     2.服务的技术标准定义与约束,耦合关系和原则的设计规范等

     3.服务调用的接口详细定义与约束,如此服务所支持的并发数的限制、超时调用的限制等。   

     4.统一技术标准和约束(如统一使用spring, ibatis, struts2, jquery等),不滥用,注重有效积累, 减小对后来的人增加维护难度,但确定下来的技术,新来的人都要强制先学习,从心理上接受这些技术,先期消化这些技术曲线,避免临阵磨枪,好事变成坏事。     

5.被动的迎接变化,缺乏主动

   规划是很重要,但总有跟不上变化的时候,不可能有一劳永逸的架构和平台,初期业务和业务系统都是不成熟的,你在做一个系统时,可能只有两三个人的团队,所做的也只是一个初期的业务,你不可能想到,未来我的系统可能要与114合做,要与某某网站合做,当这个变化来时,你才能去做这个设计。

   例如你只知道大陆酒店的业务,当你的业务要扩展到香港、海外的时候,他们的业务规范与国内的差别非常大,新的业务有可能在推翻你前期的设计。 

   你的系统要和某某网站一个合作业务,要个某某银行合做一个信用卡联名卡业务,这些合做型的项目,对方都是强势的,你不是规则的制订方,你是接受规则的一方,你在欣喜公司的业务蒸蒸日上的同时,恭喜你!你的系统的复杂度,也在蒸蒸日上。 

   唯一的办法,就是要去主动的重构,对系统和代码的复杂度降维,轻装上阵,在一个更有利的位置,拥抱变化。当然重构不是阳春白雪,不慎会带来新的不稳定因素,只要是对代码进行变动,都会引入风险,特别是遗留代码, 你在擦拭灰尘的时候,却不小心把桌上的瓷器给打破了,这时候主人肯定不会表扬你的勤劳。不管怎么样,这是你负责的项目,你跑不了,主动一点,总比束手待毙强。 

 6.人力的焦油坑

    人月神话这本书,只是给出版业带来了繁荣,平时的我们总是一遍又一遍的从一个焦油坑出来,又掉到另一个焦油坑里去,可见看书是没有用的。 

    由于难以维护的系统,总是拖累正常配置的人力,使你感觉到人手总是他妈的紧,连正常的需求开发、BUG修正都满足不了,那有时间重构。所谓人力恶性循环,就是好不容易一个熟悉代码的人,培养起来,他也厌倦了,拍屁股走人了,再招人,就得招两个人,因为系统的复杂度又增加了,需求又增加了。     

    这样的结果很可怕,没有时间来与时俱进,没有时间做提高用户体验、有价值的、增强用户粘性的功能了,没有创造性的工作,那些有创造力的人最终会含狠而去。 

    增强人力资源的储备和技术储备,是一个有效的措施,在平时做,而不是到关口了才想起,手忙脚乱的。 

    招聘人,要招self-proactive的人,能够带来变化,能够解决问题,而不是抱怨的人,等着妈妈把饭嚼完送到嘴里的小鸟,否则就是效果相反,就造成了,加人,越加越累,因为你所加的,都不是解决问题的人,而且加人的时机也不对,平时,都没有储备,关键时候,才想起要人,太晚了。  

    考虑一下,随便招一个普通的程序员,对于周围关联人的影响和所带来的成本:
    增加一个测试人员的工作量(可能他的BUG增多),增加美工的工作量(他不会写页面,不懂JS,不懂CSS),增加项目经理的工作量,增加TeamLeader的工作量(做培训计划,讲需求,讲技术),增加DBA的工作量(因为他不懂数据库,老写一些让服务器心脏博起的SQL 代码)。  

7. 松散的组织架构

      一个网站,大的网站,几十个频道,一般的也有十几人项目组,他们在维护同一个网站,彼此之间的联系很多,共同点也很多,看起来应当统一,都是自己人,也不难统一,但是现实却是非常的艰难,却如此的松散。  

      任何东西,自下而上,所带来的必然是混乱和无序,考虑一下从组织架构上来改变,建立CTO team,从全局的范围内,自上而下的推动、控制,加强全局控制力,改变各个频道或项目组各自为政的情况。将复杂的东西控制在上层,而不是程序员中间,任由其蔓延。

     改变架构师缺位,吃白饭的现状,公司不是养着架构师,学习新技术的,满口之呼者也,酸腐的人,谁都要学习,但要去一线解决问题。

   架构师要有责任,要有技术领导能力,要去Push别人,当开发人员在造轮子的时候,首当其首,责任就是架构师,如果开发人员在重复,还要你架构师做什么?很多开发人员自己写,是因为没有办法,他也不想写,但是现有的代码库当中,没有,或者没有他适合用的东东。

 

 

抱歉!评论已关闭.