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

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

     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别人，当开发人员在造轮子的时候，首当其首，责任就是架构师，如果开发人员在重复，还要你架构师做什么？很多开发人员自己写，是因为没有办法，他也不想写，但是现有的代码库当中，没有，或者没有他适合用的东东。

 

不得不说，好文一篇。。。。。。

说得仍然是一如既往的好...
比较有深度.
不过呢,问题大家可能都看得到,如何解决或者实际解决的经验更为关键.

[quote="Lucas Lee"]说得仍然是一如既往的好... 比较有深度. 不过呢,问题大家可能都看得到,如何解决或者实际解决的经验更为关键.[/quote]

我每个问题的后面，都跟了一个相关的办法，如果你不同意，或者有更好的应对措施，或者你们公司有更好的best practice, 欢迎拿出来议论，我也可以学习到别人做事的方法，这样我也不白写。

基本上,如果你没有这么大的权力执行你的想法,那么总要跟上头沟通应该如何改进和实施你的想法.

这个基本上就是第一大难关.一般的公司都还处于比较初级的阶段上,所以业务,关系是第一位的,而后技术,人员,过程之类都被赋予了较低的权数.

因此这种情况下,你所提出的那些问题都是正常的,---另一方面也是难以有效改进的.

这是基本情况.

但另一方面,积极的人为的推动,还是有一定可能的范围的.我的经验是,必须结合老板们关心的因素来实施,以取得实效和信任.

比如单元测试,代码复查等有效提高代码质量和小组能力的手段,不宜机械的全盘启动,讲究什么纯粹的过程方法,而是始终从"性价比"及小组能力现状出发,逐步的改进,关键是,每一小步只要比看得到一些效果,比之前强一些就是好的,就应该执行和继续.

另外,沟通我觉得始终是关键而有效的.小组内部,与上司,与客户,与测试人员的沟通,总是应该及时而有效的进行,这一点,似乎比较容易理解和做到吧?

你提到的架构师的职责方面,我认为是不错的,但是事实上确不容易实现.因为这样的人的工作内容不容易被他的头检验到,并认可.

还有一个我的实际经验,就是你之前帖子提到的full-stack框架,是适合这里的问题的,本人也做了一个私有的full-stack框架(我以前的帖子提到过),可以比较有效的提升那些因素.---所以说,你想路子是不错的,关键还得走出来,把东西做出来才算吧.

 

说的不错，这是俺希望看到的讨论。

不过， 不要老是说别人的是想法，就你一个人是实践，怎么证明算是做出来？是不是大家都把代码都贴出来？可是我也没见过你的代码啊？ 我上篇已经把一部分代码都贴出来，结果还是这样的说辞，这一篇，实际是项目管理的讨论，不知道我怎么做，你才算满足，按你的理论，这个论坛上的几乎所有的贴子，都应当遭到批判。

 

这个论坛里高手很多，我相信每个人都有自己的私家菜，我可不敢班门农妇，抛砖引玉，把讨论引入更深入，才更重要。

 

我相信你是一个很有能力的人，但说出来更重要，大家都藏着掖着，好像一个夜壶宝贝似的，然后像我这样的一个水平不高的人写出来，你跟在后面说“这个我也有，这个大家都想得到”，你已经跟了两个贴了，很让俺自卑。

 

另外我希望求同存异，让自己的思想更多样化，授人一鱼，不好授之以渔。

老兄,不必动气.

我的本意并不是让自己显得如何如何,不过也是希望大家能深入,能实践下去.可能你已经有了很深的实践了?但是从文中看起来似乎还是想法?

想法也好,我的本意始终是:让想法更多的被实践,并无其他评论的意图.

你并不需要让我满意. 我的意见如果你觉得没有意义,直接忽略.

个人感觉程序员一些基本素质非常必要，比如开发过程中代码不断的重构和规范完整的javadoc

深刻有感而发，实战经联丰富。

如果除去项目管理的混乱不说，网站的可持续发展问题，其实就落在了架构上。
一定要有一个清晰的架构，这个架构一定是能反映这个网站的骨架，和这个项目相关的人员，都能从这个架构得到指导和思想。项目经理从中知道项目的范围，新的架构师知道怎么让这个架构持续发展，开发人员明白如何在架构范围内开发，新手也能通过了解架构知道代码为什么这么写，应该如何写。